Spark Logic

IRlib on STM32?

Cmustard Sun Apr 10, 2016 1:13 pm

Did anyone have some degree of success to get an infrared library working in send and recieve mode yet?

I found this nice initiative https://github.com/petoknm/STM32_NEC_Decode
but that’s only focussing on the Decode piece and not the sending part.

As IRlib has done a great job in decoupling the HW related timer things from the decoding and sending logic I thought it might be a nice project to sink my teeth in.
maybe it’s fairly easy to just focussing on the hardware specific parts in the library.

Although I’m not as seasoned as most of you guys out here on the board,
An I think it might be overly ambitious for me, but still may be worth a try.

Best regards,

Paul

Replies

mrburnette Sun Apr 10, 2016 1:25 pm

@Paul,
Victor_pv was looking into it here and GarthC stated he was using NEC here.http://www.stm32duino.com/viewtopic.php … t=20#p3896

But, I have an opinion on this (I would, would not I?) A tremendous amount of bandwidth is given up to a software IR solution, IMO. The STM32F1 has the clock cycles, but many years ago, I developed an independent uC approach based on a tiny85. I was doing some real time instrument displays for a friend that owns an Experimental plane and I simply did NOT want to interfere with my loop repetition rate by throwing in IR … this was on an AVR 2560. I wanted IR to be used to set-up the realtime clock and to enter offsets, corrections factors, etc. In today’s world, I would use Bluetooth.

Anyway,here is the dedicated t85 solution.

Ray
“Waste not your extra processor cycles today, you may need them tomorrow!”

RogerClark Sun Apr 10, 2016 9:49 pm

@paul

One thing to bear in mind is that the example code uses STM’s HAL API, but our core does not use the HAL. ( our core was originally written my Leaflabs long before they released the HAL API)

So you would need to replace the HAL calls with code to directly access the hardware ( but as the HAL is now open source, it would be reasonably easy to see what the HAL calls do, or possibky just copy them imto your code.)

I noticed that STM have several application notes on IR decoding and encoding, but I dont know if any apply to the F103 ( one AN is for the F0 and F3 but I dont know why they focussed on those to devices and not the F1 and F2 as well)

Anyway, if you choose to have a go at making a STM32 IR lib, I am sure it would be handy for a lot of people

Cmustard Mon Apr 11, 2016 4:48 pm

Hi Gentle gentlemen,

I’ve found several timer docs and presentations that all the timing stuff could be handled by the hardware directly
as the STM32FXXX’es all have hardware timers.
That’s when I figured it shouldn’t be too hard as long as I could stick to ST’s good advice,
examples etc. and possibly copy in several code sniplets as long as it was compatible with the duino Core.
and that’s probably where it gets hairy..

some more background on my motivation:
I’ve set myself on a target to develop a laser tag game (With overly ambitious targets)
Various game types (capture the flag) (hunt the rabbit) team A vs Team B etc. and more of such things.
So a player needs to know by whom of which team he/she was hit.
Typically I need line of sight IR communication as part of the
Ideally I’d like a central server to keep track of the scores and that kind of palaver.

similar to the comercial stuff in lasergame venues.
However that’s the long term goal… short term I’d like to work on the individual components.
and IR send recieve is the most important part.

I’ve tried stuff with the pro-mini (as the HW needs to be tiny enough to be built in a gun.)
but coupling an SPI OLED display AND ESP8266 AND buttons AND LEDs AND a Laser AND IRsensor AND an MP3 module for the sounds
Even if I’d do I2C stuff instead of SPI etc. I’d probably still end up in an assylum before it works.

All the individual stuff worked great, some together also, but all together as a final product…not so
I even looked at shift out registers etc. but that didn’t help much due to fixed pin functions and overlap of some functions
and last but not least the mini had not enough oomph.

So I moved over to the nodeMCU and things quickly got worse when I realised that that thing was unstable as hell and didn’t solve much of my initial problems. hahaha.. stupid me for not digging through the specs. enough before I bought a set. buy hey they were cheap :-)

So I learned from that mistake and started by sifting MCU’s designs.
The hardware of the STM32 looked pretty good and fit for purpose
The pin flexibility interrupts timer functions etc. all looked promissing.
only one caveat… a missing IR library.. well at least in duino-land

Now That’s the why, behind my story.

Ray’s comment on not willing to spend SW time cycles is an interresting view
I came across that on the pro mini as well (realtime handling of all the functions became a horror quickly as you can imagine)

Paul

RogerClark Mon Apr 11, 2016 8:25 pm

I cant remember who it was, But Im fairly sure someone else on the forum was building a laser tag system.

Re:Using STs examples

The STM32s have some cool hardware features, (most of which we have only scratched the surface of)
So if ST have some application notes on how to use the hardware more efficiently for this, its definitely worth reading.

However, be aware that different processors in the family have additional hardware that the F103 does not possess.
e.g. I think the F3 series seems to be targeted at analog input and processing.

stevech Mon Apr 11, 2016 11:13 pm

The ST “Standard Peripheral Library” (SPL) is an alternative to the HAL. Indeed the HAL was derived from the SPL.

Both are terrific open source (vast) drivers and MCU management that I use, and watch somewhat sadly, while ArduinoARM people reinvent these wheels. Freescale/NXP has something similar to HAL and SPL but I find them to be way inferior and limited.

mrburnette Mon Apr 11, 2016 11:35 pm

stevech wrote:The ST “Standard Peripheral Library” (SPL) is an alternative to the HAL. Indeed the HAL was derived from the SPL.

Both are terrific open source (vast) drivers and MCU management that I use, and watch somewhat sadly, while ArduinoARM people reinvent these wheels. Freescale/NXP has something similar to HAL and SPL but I find them to be way inferior and limited.

RogerClark Tue Apr 12, 2016 12:06 am

The problem with the SPL (and the HAL) is that they were only made truly Open Source, fairly recently.

Prior to that, although you could download the SPL and use it for your own commercial or non-commercial products, it was not possible to write an Open Source product which referenced the SPL, without requiring the end user to download the SPL separately (as the code contains a non-redistribution clause)

Hence why, we believe, that Leaflabs had to code their own API to the hardware from scratch.

Its really only since the beginning of the year that the output from the STM Cube could be used for Open Source projects, and even then some files initially had licensing issues (though not deliberately)

Note. I know that some other projects, like MakerLabMe etc have published SPL code from STM in their repo’s, but AFIK know it most likely breaches the terms of use in those SPL files to redistribute them (e.g on GitHub)

stevech Wed Apr 13, 2016 2:33 am

By “open source”.. what do you mean?
SPL and HAL – I’ve been working with them for only 1 1/2 years. I’m not an IP guru, but they are provided by ST to anyone who wants to register with name/email and download. No fees I’m aware of to incorporate these into products. Indeed, the ST’s purpose of these is to speed time to market and cost of development. NXP/Freescale does the same thing.

I’m doing commercial work with with HAL and there’s no issue with leaving their credits in the source, nor if we have to, crediting them in the release of the product that uses the binaries. Like many product cycles, no ST-original source code is provided, nor usually wanted by the customers.

I do NOT modify ST’s code for obvious reasons – mainly that I don’t need to and also I don’t want to cause a configuration mess as they release updates several times a year. I can take my sources minus ST’s sources from HAL and CubeMX, and create a baseline and tell someone how to do their own download of ST’s code and code-generate with CubeMX and get the same result. If need be.

non-commercial applications – I’ve not read the fine print. But I don’t think there are restrictions other than leaving the ST credit in place. Seems fair to me, as if I had to develop all those drivers from bare metal, it would have made the cost and schedule, and complexity, impractical. Not like a bit of code for a PIC or AVR.

Hobby market… well, you know that story. The best is to get it into University labs for imprinting – as Apple is want to do.

Lastly, the low cost of MCUs, and M3/M4 with generous sized flash/RAM – makes it illogical to do as we all used to do way back.. work for hours with an undersized MCU is false economics. Big non-recurring labor costs make sense only if you are building a million and have a big amortization base. For avocational.. we’re talking insignificant parts cost deltas.

So, I certainly missed the point of the posting.

RogerClark Wed Apr 13, 2016 4:28 am

There was a non-distribution clause in the STM

It means that its fine for you and anyone else to download and use the code

However, it was not possible to base an Arduino “core” on the STM, as the Arduino Core’s are shipped as source code, and it was not possible to include any SPL code.

If you do work for anyone and use the SPL, Technically you couldn’t (prior to this year) bundle the SPL with your code when you hand it over

Your client, technically had to download their own copy of the SPL to compile your code

Of course this is all history now, as STM changed their IP license this year to allow redistribution.

I was just trying to explain why the LibMaple Arduino core written by Leaflabs in 2012 did not use the SPL.

mrburnette Wed Apr 13, 2016 1:39 pm

stevech wrote:
<…>
So, I certainly missed the point of the posting.

ahull Wed Apr 13, 2016 4:14 pm

mrburnette wrote:
Have you guys noticed that this forum is not being recommended by Leaflabs? Cool.

You can still read the docs. The forums will remain active until August 2016, but at that point they will be converted to a static archive. Consider checking out the resources and community at http://www.stm32duino.com instead.

Ray

mrburnette Wed Apr 13, 2016 9:39 pm

ahull wrote:mrburnette wrote:
Have you guys noticed that this forum is not being recommended by Leaflabs? Cool.

You can still read the docs. The forums will remain active until August 2016, but at that point they will be converted to a static archive. Consider checking out the resources and community at http://www.stm32duino.com instead.

Ray

ahull Wed Apr 13, 2016 9:54 pm

Years ago I *almost* sent a thank you card to someone who had popped in with a homemade cake with the line “thank you for the cake, it was very nasty”… a brain fart rather than spell checker mistake. It should have read.. .. cake was very nice…. Fortunately the mistake was spotted before the insult was posted. :oops:

zmemw16 Wed Apr 13, 2016 10:36 pm

tasty ???

RogerClark Wed Apr 13, 2016 10:46 pm

Paistry ?

ahull Wed Apr 13, 2016 11:01 pm

zmemw16 wrote:tasty ???

mrburnette Wed Apr 13, 2016 11:47 pm

ahull wrote:Years ago I *almost* sent a thank you card to someone who had popped in with a homemade cake with the line “thank you for the cake, it was very nasty”… a brain fart rather than spell checker mistake. It should have read.. .. cake was very nice…. Fortunately the mistake was spotted before the insult was posted. :oops:

rexnanet Tue Apr 26, 2016 6:04 pm

Has anyone tried a go on “IRremote” library?

It has a lot of things already implemented. I think the “only work” needed to be done is to replace the interrupt an configuration calls that are made directly to AVR HW for ones to STM32 HW…

I’ve downloaded and I’m getting these errors:
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp: In member function 'void IRrecv::enableIRIn()':
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:115:6: error: 'cli' was not declared in this scope
cli();
^
In file included from G:\User\Documents\Arduino\libraries\IRremote\IRremote.h:24:0,
from G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:1:
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:246:3: error: 'TCCR2A' was not declared in this scope
TCCR2A = _BV(WGM21); \
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:120:2: note: in expansion of macro 'TIMER_CONFIG_NORMAL'
TIMER_CONFIG_NORMAL();
^
In file included from G:\User\Downloads\arduino-1.6.5-r5\hardware\Arduino_STM32\STM32F1\cores\maple/Arduino.h:30:0,
from G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:24,
from G:\User\Documents\Arduino\libraries\IRremote\IRremote.h:24,
from G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:1:
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:246:16: error: 'WGM21' was not declared in this scope
TCCR2A = _BV(WGM21); \
^
G:\User\Downloads\arduino-1.6.5-r5\hardware\Arduino_STM32\STM32F1\cores\maple/wirish.h:103:25: note: in definition of macro '_BV'
#define _BV(bit) (1 << (bit))
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:120:2: note: in expansion of macro 'TIMER_CONFIG_NORMAL'
TIMER_CONFIG_NORMAL();
^
In file included from G:\User\Documents\Arduino\libraries\IRremote\IRremote.h:24:0,
from G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:1:
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:247:3: error: 'TCCR2B' was not declared in this scope
TCCR2B = _BV(CS21); \
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:120:2: note: in expansion of macro 'TIMER_CONFIG_NORMAL'
TIMER_CONFIG_NORMAL();
^
In file included from G:\User\Downloads\arduino-1.6.5-r5\hardware\Arduino_STM32\STM32F1\cores\maple/Arduino.h:30:0,
from G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:24,
from G:\User\Documents\Arduino\libraries\IRremote\IRremote.h:24,
from G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:1:
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:247:16: error: 'CS21' was not declared in this scope
TCCR2B = _BV(CS21); \
^
G:\User\Downloads\arduino-1.6.5-r5\hardware\Arduino_STM32\STM32F1\cores\maple/wirish.h:103:25: note: in definition of macro '_BV'
#define _BV(bit) (1 << (bit))
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:120:2: note: in expansion of macro 'TIMER_CONFIG_NORMAL'
TIMER_CONFIG_NORMAL();
^
In file included from G:\User\Documents\Arduino\libraries\IRremote\IRremote.h:24:0,
from G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:1:
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:248:3: error: 'OCR2A' was not declared in this scope
OCR2A = TIMER_COUNT_TOP / 8; \
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:120:2: note: in expansion of macro 'TIMER_CONFIG_NORMAL'
TIMER_CONFIG_NORMAL();
^
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:249:3: error: 'TCNT2' was not declared in this scope
TCNT2 = 0; \
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:120:2: note: in expansion of macro 'TIMER_CONFIG_NORMAL'
TIMER_CONFIG_NORMAL();
^
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:222:30: error: 'TIMSK2' was not declared in this scope
#define TIMER_ENABLE_INTR (TIMSK2 = _BV(OCIE2A))
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:123:2: note: in expansion of macro 'TIMER_ENABLE_INTR'
TIMER_ENABLE_INTR;
^
In file included from G:\User\Downloads\arduino-1.6.5-r5\hardware\Arduino_STM32\STM32F1\cores\maple/Arduino.h:30:0,
from G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:24,
from G:\User\Documents\Arduino\libraries\IRremote\IRremote.h:24,
from G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:1:
G:\User\Documents\Arduino\libraries\IRremote\IRremoteInt.h:222:43: error: 'OCIE2A' was not declared in this scope
#define TIMER_ENABLE_INTR (TIMSK2 = _BV(OCIE2A))
^
G:\User\Downloads\arduino-1.6.5-r5\hardware\Arduino_STM32\STM32F1\cores\maple/wirish.h:103:25: note: in definition of macro '_BV'
#define _BV(bit) (1 << (bit))
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:123:2: note: in expansion of macro 'TIMER_ENABLE_INTR'
TIMER_ENABLE_INTR;
^
G:\User\Documents\Arduino\libraries\IRremote\irRecv.cpp:127:6: error: 'sei' was not declared in this scope
sei(); // enable interrupts
^

stevech Wed Apr 27, 2016 3:57 am

Very interesting article part 1 on IR with microprocessors.

Circuit Cellar magazine. May 2016.

Sign in to reply