Electronics > Microcontrollers

RTOS Examples

<< < (4/4)

rstofer:

--- Quote from: Siwastaja on October 24, 2021, 09:34:22 am ---I especially love rstofer's arguments how simple it is react to an external event because you don't have to consume "computing cycles" waiting for it and can just configure an interrupt, where you post a semaphore, which the scheduler then dispatches to your task, which is written to wait for the semaphore. If it is already this complex on RTOS, it must be total pain in the ass without one!  :-DD

--- End quote ---

I think I was trying to discuss the idea of modularity.  The UART interrupt handler receives a char (say) and stuffs it in a queue.  It is a producer and doesn't know about, or even care about, the consumer.  As long as the queue doesn't overflow, everything is great.

The consumer (waiting on a posting or otherwise polling the queue) just wants to grab data from time to time.  It doesn't care what produced the data, it just looks in the queue and reacts accordingly.  It knows absolutely nothing about the internals of the producer.  With an RTOS, we wouldn't even test the queue.  When it gets posted, the consumer task will be scheduled.  Otherwise, it is just waiting and inactive.

Neither task knows anything about the other.  I can replace the UART producer with a similar SPI gadget without a single change in the consumer.  Similarly, I can replace the consumer without telling the producer anything.

All of the interconnection is done through the queue.

Producer-consumer modularity has been around a long time and certainly doesn't require an RTOS.  What the RTOS brings to the dance is a standard for queue operations (pointer protection and such) which can be a PITA for super-loop programs.  And scheduling!  Why test the queue when the queue operation can schedule the consumer directly.

Still, it's a choice.  The work still gets done...

Doctorandus_P:
I once had a job in maintaining software for an RTOS. (Nucleus)
It had 30+ tasks running in about 500kB of compiled code.

Once we had a bug that nobody could pin down, but the bug was reproducible in a particular version of the software. It was my task to throw away bits and pieces of the code while still being able to keep the bug reproducible. I managed to get it down to about 20kB, and that took about 7 work days. After that a colleague managed to pin it down to a pointer overflow in the RTOS kernel.

That's not a good environment for learning to work with an RTOS.

A few blinkenlights, combined with a bit of uart stuff a keyboard matrix and some display is a much better and gentler way to learn.

You can run an RTOS on an AVR, but it's not a good fit.
* Too limited in RAM.
* Too many registers that need to be saved for a task switch.
* Lack of different ISR priorities.

Some ARM cortex microcontroller is a much better fit for working with an RTOS.

nctnico:

--- Quote from: rstofer on October 24, 2021, 05:16:46 pm ---Producer-consumer modularity has been around a long time and certainly doesn't require an RTOS.  What the RTOS brings to the dance is a standard for queue operations (pointer protection and such) which can be a PITA for super-loop programs.  And scheduling!  Why test the queue when the queue operation can schedule the consumer directly.

--- End quote ---
Still the OS will do some polling (iterating through a list with tasks) on whether a task needs to be run or not under the hood.

--- Quote ---Still, it's a choice.  The work still gets done...

--- End quote ---
Indeed the choice isn't that black and white. It is not like an RTOS is only to serve mediocre programmers. In a super-loop every task needs to be non-blocking. However if one task blocks due to a bug or suddenly starts to take a lot of time, the other tasks will be starved from processing time in a super-loop system. An RTOS which does pre-emptive multitasking will divide processing time equally according the process priorities so a tasks which misbehaves is not halting the entire system. It also allows to have a watchdog task which checks the other tasks to see if one is hanging and then restart the particular task or the entire system.

Another solution to blinking 3 LEDs (as an exercise to have 3 parallel tasks!) is to use 3 hardware timer channels and use an interrupt to blink a particular LED. I like to see the interrupt controller as a task manager to have tasks run in parallel even when the application is implemented as a super-loop. Actually, you can have several super-loops this way. A main loop which runs a bunch of tasks and a timer interrupt from which another set of tasks is run.

All in all I don't think there is much difference in complexity between using an RTOS or super-loop. Each have their pitfalls; in the end you'll need a competent programmer to write robust code.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version