reccomendations for getting started with RTOS and threading?

[cbc02009]

I've done quite a bit of programming on simple single core processors like the 328p and the ARM M0, and now I'm curious about more complicated coding techniques for small MCUs.

In my senior design project we had a screen update function that we wrote by hand, but it took a long time relative to the rest of the program, and so the other, more important things would have to wait while it was running. I ran out of time to look into it, but I wondered if I could have solved that problem with threads.

Does anyone have any good books or textbooks or projects they could recommend for someone to learn about these kinds of topics? I don't really know enough to even know where to begin.

Thanks!

[ggchab]

A suggestion only: you may not need RTOS on a small micro-controller. Important things can be triggered by interrupts. This will suspend the screen update function that restarts when the important things are done. You may also use timer interrupts to do things at regular intervals. Interrupts priorities may help.

[tggzzz]

Interrupts priorities may help.

... in which case you have to be aware of "priority inversion".

I suggest the OP:

• reads a textbook on real-time programming and RTOSs. I've been doing this since the early 80s, so my textbooks are probably unobtainable!
• reads about design patterns related to distributed applications, multicore processing (there's a lot of overlap!)
• avoids designing applications at the mutex/semaphore level, and uses "higher" level abstractions
• the Java concurrency utilities are one set of such abstractions; it is well worth understanding the underlying design patterns, even if you never use Java
• do not share data between threads, but do send messages containing primitive values (i.e. no addresses!) between threads
• think asynchronously; do not assume any event ordering
• think in terms of FSMs: events (passed in messages), states (where a thread is waiting for an event), actions and transitions (when a thread receives an event in a state)

[cbc02009]

A suggestion only: you may not need RTOS on a small micro-controller. Important things can be triggered by interrupts. This will suspend the screen update function that restarts when the important things are done. You may also use timer interrupts to do things at regular intervals. Interrupts priorities may help.

Thank you, yes, it would have been overkill for the project I was working on. It was just a small thing that bothered me, but I ended up using flags to minimize its impact.

Interrupts priorities may help.

... in which case you have to be aware of "priority inversion".

I suggest the OP:

• reads a textbook on real-time programming and RTOSs. I've been doing this since the early 80s, so my textbooks are probably unobtainable!
• reads about design patterns related to distributed applications, multicore processing (there's a lot of overlap!)
• avoids designing applications at the mutex/semaphore level, and uses "higher" level abstractions
• the Java concurrency utilities are one set of such abstractions; it is well worth understanding the underlying design patterns, even if you never use Java
• do not share data between threads, but do send messages containing primitive values (i.e. no addresses!) between threads
• think asynchronously; do not assume any event ordering
• think in terms of FSMs: events (passed in messages), states (where a thread is waiting for an event), actions and transitions (when a thread receives an event in a state)

 Can you explain your third point? I know what mutex and semaphore are. Are you saying I should avoid them, or just ignore that level of abstration and move on to the next one? Why?

[tggzzz]

While mutexes and semaphores are sufficient and work on a small scale, if used in a undisciplined fashion in a typical system, the system eventually becomes brittle and unmaintainable.

That can best be understood after designing and implementing a system, by attempting to prove to someone else that there are no situations that could end up in deadlock or lovelock. That's extraordinary difficult, even with the use of design patterns

Having said that, mutexes and semaphores are critical to implementing the primitives used in higher level abstractions.

[nick_d]

 What is really needed here is experience, and to get experience, a working setup for experimentation.

We are using STM32F4 and STM32F7 parts and the client has required us to use FreeRTOS and implement separate threads for each part of the application, communicating by queues and such.

I implemented various interrupt handlers for peripherals that didn't already have a firmware driver provided by STMicroelectronics, and what these mostly do is wake up a FreeRTOS task that services the device and then goes back to sleep until the next interrupt wakes it up.

Why I mention those details is to recommend to the OP to set up an environment similar to what I have been required to use. First you run STM32CubeMX and graphically specify the pinout, function of each pin, and enable the needed functional blocks such as UART, CAN controller etc, and also the associated firmware blocks (STM32 HAL, FreeRTOS) and set clock, DMA, and interrupt configuration etc. It is all extremely easy and menu driven. You can also, if you wish, define FreeRTOS tasks, semaphores, queues etc here.

Then you run Atollic TrueSTUDIO which has been acquired by ST and is now free. And build your project and start filling in the code for the different tasks and so forth. All hardware has a HAL driver and while none of this is particularly efficient or elegant (and the HAL has bugs and missing features), it is extremely EASY to get started and mostly gets the job done. It is also easier for someone else to pick up later, than your hand optimized, interrupt driven code that directly accesses hardware (do this but only if you need to).

cheers, Nick

[mikerj]

In my senior design project we had a screen update function that we wrote by hand, but it took a long time relative to the rest of the program, and so the other, more important things would have to wait while it was running. I ran out of time to look into it, but I wondered if I could have solved that problem with threads.

An RTOS is certainly one way to solve this, and makes code easier to write  once you are fammilar with the way an RTOS works and is best used.  However an RTOS can add a significant code size penalty, and your problem could easily have been solved by breaking up the screen update function into multiple shorter execution blocks and then using a state machine to execute each block in the required sequence.  This is a kind of half way step to a cooperative task system, where every task is responsible for releasing CPU time for the other tasks, rather than a preemptive RTOS that will allocate short time slices to tasks as and when they need it.

Quite complex applications can be made using state machines like this, but maintenance and debugging start to become a major chore as complexity goes up.  Attempts to hide this complexity have been made e.g. Protothreads, but that tends to introduce it's own problems and I wouldn't recommend it.

[tggzzz]

In my senior design project we had a screen update function that we wrote by hand, but it took a long time relative to the rest of the program, and so the other, more important things would have to wait while it was running. I ran out of time to look into it, but I wondered if I could have solved that problem with threads.

An RTOS is certainly one way to solve this, and makes code easier to write  once you are fammilar with the way an RTOS works and is best used.  However an RTOS can add a significant code size penalty, and your problem could easily have been solved by breaking up the screen update function into multiple shorter execution blocks and then using a state machine to execute each block in the required sequence.  This is a kind of half way step to a cooperative task system, where every task is responsible for releasing CPU time for the other tasks, rather than a preemptive RTOS that will allocate short time slices to tasks as and when they need it.

Quite complex applications can be made using state machines like this, but maintenance and debugging start to become a major chore as complexity goes up.  Attempts to hide this complexity have been made e.g. Protothreads, but that tends to introduce it's own problems and I wouldn't recommend it.

Actually, extremely complex applications can be made using that abstraction. It is a classic design pattern used in, for one of many examples, the telecommunications system.

With a tiny bit of thought, architecture and implementation it is possible to log system performance and behaviour. That enables you to, amongst other things, prove your system is right and the other company's system is at fault. Keeping lawyers away is priceless

Another advantage is that there is often a simple direct relationship between the code and the specification.

Protothreads is a crappy solution to a problem that is introduced by the false concept that "C can do everything and everything should be done in C". If you allow yourself a tiny bit of machine-dependent code (to fiddle with the stack pointer) then life becomes a whole lot easier and simpler.