Is there any ported RTOS for STM32F407VE?

[xtream123]

Hi there guys,
Is there any available or ported RTOS for STM32F407VE using stevstrong's core?
Thank you.

[stevestrong]

I am not aware of any RTOS port for my core.
And me, I do not plan to do it.

[xtream123]

oh..I see, thanks, maybe time can tell.

Why you do not have a plan?is it hard to port an RTOS?

[ag123]

you may want to take a look at this one
an event loop developed on maple mini
https://github.com/ag88/stm32duino-eventloop
but the codes are not specific to the mcu

note that this isn't the only one and neither is it a good let alone best one, there are plenty more implementations and examples which are probably better
https://www.google.com/search?q=event+loop+arduino

an event loop is a 'glorified' version of this,

Code: Select all

loop() {
  task1();
  task2();
  task3();
}

or more correctly 'co-operative multi-tasking', so each task() should not hog and wait for things, instead use global variables to keep state and let go the time slice and return from the function.

the difference between an event loop vs the above simple 'scheduler' is it works more like a node-js event loop
https://www.tutorialspoint.com/nodejs/n ... t_loop.htm
i place events in a queue and send them to tasks so each task has to evaluate if it should process an event.
does it work? well the whole 'windowing' system world works nearly based on this concept, so do node js, javascript etc.

why event loop? for RTOS, it needs to allocate memory to each vtask, hence, this fragments the already very limited memory and you would soon run out of memory. using an event loop, lets you do 'co-operative' multitasking and you can 'send events' between tasks (e.g. task1 check button presses, post the event, another task check the queue and process the event (if needed). 'dynamic' memory is basically your local variables (placed on the stack) and that gets unwound when each function (task) returns.
- not real time, but the event loop has a hidden surprising result of keeping everything in a queue (actually a circular buffer), so your events happen one after another in sequence. it got rid of a lot of synchronization pains, if you put every thing on a queue, there is no need to synchronize, every thing happen one after another as the event loop dispatches events to the tasks one after another.
what about real time? the interrupt request handlers take care of that, anything that needs 'real time' goes into the isr or hardware

the other benefit of an event loop is each task() is a regular c function or c++ method. so you can call it from anywhere with little concerns.

[ag123]

but seriously even an event loop may be deemed superfluous, if ray reads this thread, he'd probably agree
many other things has been done without needing an event loop

Demonstration code for several things at the same time
https://forum.arduino.cc/index.php?topic=223286.0
Multi-tasking the Arduino - Part 1
https://learn.adafruit.com/multi-taskin ... ino-part-1

[stevestrong]

Why you do not have a plan?is it hard to port an RTOS?

I don't know how hard is it to port.
But I will not do it because I don't need it.
Why do you need it?

For easily managing timings I lately used this simple tasker: https://github.com/joysfera/arduino-tasker

[xtream123]

but seriously even an event loop may be deemed superfluous, if ray reads this thread, he'd probably agree
many other things has been done without needing an event loop

Demonstration code for several things at the same time
https://forum.arduino.cc/index.php?topic=223286.0
Multi-tasking the Arduino - Part 1
https://learn.adafruit.com/multi-taskin ... ino-part-1

Thanks ag123 for sharing your insights about this. Actually I haven't tried to use an RTOS ever since, just having some hearsay that its hard to debug a program if you are using an RTOS.

[xtream123]

Why you do not have a plan?is it hard to port an RTOS?

I don't know how hard is it to port.
But I will not do it because I don't need it.
Why do you need it?

For easily managing timings I lately used this simple tasker: https://github.com/joysfera/arduino-tasker

Well, firstly, I want to experience using an RTOS, secondly, one library for an RFID reader (PN532) with HSU from elechouse( https://github.com/elechouse/PN532 ) has a longer waiting time or timeout for waiting an acknowledgement or response therefor other activity of the mcu or in the program would be delayed significantly for 1 second.

Currently, I have managed to reduce the timeout by changing the timeout in the library to about 25ms, but im doubting if these change would have a significant negative effect in the long run.

Thanks for the link. I will give it a try together with ag123's shared info.

[ag123]

i came to write such codes a little more often these days, nearly an idom

Code: Select all

enum state_enum {
 INIT = 0;
 RUN,
 DONE,
 TIMEOUT
};

state_enum state = INIT;
int timeout = 0;
int done = false;
loop() {

if(state == INIT) {
  timeout = millis() + 10000; //wait 10 secs
  done = false;
  state = RUN;
} else if (state == RUN && millis() =< timeout) {
  done = check_results();
  if(done) state = DONE;
} else if (state == RUN &&  millis() > timeout) {
  state = TIMEOUT;
  //do things when timeout if necessary
}

}

this is more complicated than a simple busy wait loop e.g.

Code: Select all

while(1) 
  if( check_results() ) break;

, but basically by keeping state, one manages to do 'asynchronous' polling rather than simply spin lock for the results, thus preventing stalls

the downside is you may need to modify the library or do the checks differently as this is co-operative multitasking

RTOS isn't without a problem either. an RTOS basically hooks the systick interrupt. and when systick occurs, it saves the existing register states and changes the stack pointer and instruction pointer so that it points to a different stack (a different set of local variables) and instructions. it would also need to save and restore other state data i'd think. The end result is you need to partition memory into silos for each vTask() to run on its own stack.
for mcus on low ram e.g. 20k on stm32f103 this quickly become a limitation. stm32f407 may work better with RTOS.

found 2 nice articles on context switching on cortex-m, these are nearly as good as building an RTOS scheduler
https://blog.stratifylabs.co/device/201 ... Cortex-M3/
https://www.adamh.cz/blog/2016/07/conte ... cortex-m0/

perhaps, you could give it a shot to try to port RTOS based on some of the hints pointed here. you could then send a PR to steve to be included in the libraries

[stevestrong]

You can write your own my_delay() function where you can do other stuff while waiting for radio lib response.

Or, even more elegant, you can write your own yield() function to do other stuff, as yield() is already included in delay().