Electronics > Microcontrollers

RTOS Examples

(1/4) > >>

BlogRahul:
I am trying to find some real use case for RTOS. Blinky LED's is not a RTOS application and does not require an RTOS. What are the good learning examples of RTOS that really require RTOS. 

nctnico:

--- Quote from: BlogRahul on October 21, 2021, 03:59:14 am ---I am trying to find some real use case for RTOS. Blinky LED's is not a RTOS application and does not require an RTOS. What are the good learning examples of RTOS that really require RTOS.

--- End quote ---
I beg to differ.  Seriously: create an application with 3 threads that each blink a LED. Start simple and go from there.

westfw:
In theory, I can make a SAMD21 (Seeed Xiao or Adafruit QT Pi, etc) into a three-port USB-Serial converter.The code would be a lot easier/simpler with an RTOS (not counting the RTOS itself, of course.)For each port, one task would read from Serial and Write to USB, and one task would read from USB and write to Serial.  Three ports, six (rather trivial) tasks.  Piece of cake (aside from the fact that many RTOSes probably don't have very good USB support...)


Another example would be to add a "debug command processor" to any program.  Open an extra USB CDC channel and process commands to look at the status of whatever else is going on.  Or use the serial port.  I have this implemented using careful mostly-nonblocking code (dump the peripheral register content, look at memory, etc); it would be trivial and less invasive on top of a RTOS (non-blocking output to a CLI channel is pretty annoying to do manually.)

Implement multiple servos or stepper motors, each with speed control.  (Stepper 1 moves at 10 steps per second, Servo 0 goes from 0 to 45 degrees in 10 steps over 1 second, etc.)

Go ahead and implement that 80s-like computer that runs a BASIC interpreter while bit-banging a video display and PS/2 keyboard.  Driving the video is probably closer to "real time" than most examples.  Video at highest priority, keyboard next, actually interpreting the BASIC program last.

rstofer:
One of the advantages of RTOS projects is the way in which tasks interact. Each major component of a project can be written as a separate, standalone, task that runs from time to time.  There is no complex logic as might be required in a super-loop approach.  Communications between tasks is handled in a standardized and predictable way.  Entire tasks can be added/removed/changed without the other tasks being affected.

Tasks can wait for things to happen.  They don't consume compute cycles testing for input that may never come, they simply get scheduled when something is posted to a semaphore or queue.

None of this stuff actually requires 'real-time' but if you extend it to the flight controls of an F-22, things get real interesting, real quick.  The plane is inherently unstable and the flight controls make it flyable.

Given some kind of memory management, the code to respond to an event doesn't even need to be resident in memory.  Loading the code impacts latency and some tasks are more urgent than others.

There's no point in dealing with incoming characters, other than to put them in a queue, until a message is known to be complete.  Maybe the interrupt routine puts characters in a queue and sets the 'message received' semaphore when it sees carriage return.  If it's not done this way, handling a console can get complex.  And you still need a queue...

One of the nice things about ST's STM32CubeIDE is that it will emit code to create a FreeRTOS framework.  Most of the heavy lifting is done by auto-magic and all the user has to do is create the tasks and link them in.

There's no absolute reason an RTOS needs to be used as long as there is some concept of scheduling in some kind of priority order with some scheme for message handling.  But that's exactly what an RTOS does!

rstofer:
The 3 blinking LED example with different periods is really a good idea.  Expand it such that the frequency is changed with each push of a button.  Maybe implement an interrupt for the button, post to a semaphore from the interrupt routine and then, when it is time for a particular LED task to run, look at the semaphore and adjust the period for this and subsequent blinks of that LED.  On the next operation of the button, revert to the original timing.

Meanwhile, the other 2 LEDs are merrily blinking along.

Something like that...

It serves no good purpose whatsoever except for creating and scheduling 3 tasks, getting a button interrupt to operate and working with a semaphore and an RTOS.  Although, a dual rate LED might be a handy error indicator...

Of course this stuff can be done in a super loop.  It has been for decades.  But using an RTOS is easier and the code is a lot cleaner.

Navigation

[0] Message Index

[#] Next page

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