First RTOS project and first impressions

[e100]

Would it be fair to describe projects that use an RTOS as a delicate balancing act that aims to keeps producers, consumers and the interrupt timer watchdog happy?

My experience (as a beginner) is that contrary to expectations you cannot just add a new chunk of functionality as a separate task and expect it to happily co-exist without affecting other things. In addition anything that disables interrupts has the potential to trigger unexpected reboots. You have to be acutely aware of how the tasks interact which seems to contradict the claim that an RTOS allows blocks of functionality to be developed in isolation. Perhaps I'm doing things wrong, but as I said these are just my first impressions having come from superloop land.

[Doctorandus_P]

An RTOS is not some kind of magic wand that you wave at a problem to make it vanish.
Nor does it compensate for bad programming practices.
When I write ISR's for example they are never longer then a few hundred opcodes, and they execute in a a few tens of mircoseconds at most.

An RTOS also adds extra complexity, and it does take some studying to be able to work effectively with an RTOS. And RTOS does separate tasks from each other, and as long as those tasks live in their own bubble they are pretty much independent, but if a task can not communicate with other tasks it is not of much use. All interactions with other tasks has to be scrutinized carefully, but you can only do so if you if you have a fairly good knowledge of what an RTOS is, how it works, and where the limits are. Learning this takes a fair bit of study and practice. Below is a link to some exercise material, and it also has links to other aspects of an RTOS.

https://en.wikipedia.org/wiki/Dining_philosophers_problem

[nctnico]

Over the years one of my observations is that programmers go through several stages as they gain more experience:

- Superloop
- Seperate processes
- Back to superloop combined with parallel threads

[woofy]

Over the years, I've looked at using an RTOS a few times, even wrote a simple one for the Z80 once though that was more of a round robin scheduler. I've never really felt they offered me anything worthwhile though, just "in my way".
Most RTOS implementations are likely to be on micro-controllers that do not have any form of memory protection or privileged mode. A task can write anything anywhere potentially nuking the entire system.
My own preferred method is super-loop and interrupts. That way all of the code, hardware (and responsibility) are mine.

[peter-h]

I am using FreeRTOS and would never go back to the old ways. Makes coding so much easier.

But it takes a fair bit of setting up.

I too wrote my own Z80/Z180/Z280 RTOS, in the 1980s, and it made product development (of complicated comms protocol converters, back then) much easier.

A task can write anything anywhere potentially nuking the entire system.

That's always the case. There were all kinds of idealistic approaches in the 1980s, with MMUs offering protection etc, but it has all been abandoned And simple chips like the ST ARM32 can't do it anyway.

[tggzzz]

Would it be fair to describe projects that use an RTOS as a delicate balancing act that aims to keeps producers, consumers and the interrupt timer watchdog happy?

Only in the sense that's true for all real-time systems, both soft and hard realtime, and software and hardware.

My experience (as a beginner) is that contrary to expectations you cannot just add a new chunk of functionality as a separate task and expect it to happily co-exist without affecting other things. In addition anything that disables interrupts has the potential to trigger unexpected reboots. You have to be acutely aware of how the tasks interact which seems to contradict the claim that an RTOS allows blocks of functionality to be developed in isolation. Perhaps I'm doing things wrong, but as I said these are just my first impressions having come from superloop land.

Ah. Someone that believes that technology X is a magic bullet.

[tggzzz]

Over the years one of my observations is that programmers go through several stages as they gain more experience:

- Superloop
- Seperate processes
- Back to superloop combined with parallel threads

For real-time systems, that's not too inaccurate

I'd add:
- understand the benefits of specifying, designing and implementing systems using events, states, and processing events (i.e. FSMs)
- each thread processes one event to completion before starting on another
- one thread per core, if possible
- storing process state in an object/struct, not in the program counter associated with a thread
- one level of interrupts (plus powerfail interrupt)
- one level of thread priority

[tggzzz]

Over the years, I've looked at using an RTOS a few times, even wrote a simple one for the Z80 once though that was more of a round robin scheduler. I've never really felt they offered me anything worthwhile though, just "in my way".
Most RTOS implementations are likely to be on micro-controllers that do not have any form of memory protection or privileged mode. A task can write anything anywhere potentially nuking the entire system.
My own preferred method is super-loop and interrupts. That way all of the code, hardware (and responsibility) are mine.

Realtime systems encompass far more than that! They include everything from hardware to software, from embedded to applications running in standard operating systems such as Unix.

It is rare that one person or even team writes all the code nowadays. Usually there is, at a minimum, a library of some sort in the code.

See my comments (and nctnico's) in reply #6 https://www.eevblog.com/forum/microcontrollers/first-rtos-project-and-first-impressions/msg4334740/#msg4334740