Electronics > Microcontrollers

FreeRTOS - pre-emptive or not?

<< < (13/13)

Yes, when having to deal with complex, broken and buggy libraries to implement simple things which take 5 nonblocking LoC without the library, life gets very difficult very quickly. The answer is obvious, adding more complexity until it somehow kinda magically works out. During this process, it's very typical that most fancy pre-requirements (nanoseconds! 10000 years MTBF!) are relieved to be able to deliver at all. For example, "robust" means it works on lab table during demonstration. "Real time" means something happens within the human timeframe of not noticing the delay (i.e., < 10ms).

It doesn't have to be that way.

Unless the project really is complex. I mean like autonomous space shuttle that lands on the Moon while doing moonwalk better than Michael Jackson ever did level complex. In such case, you may want to leverage existing machine vision algorithms, for example, meaning actually complex libraries instead of 5-LoC ad-hoc solution. And you may want something fancier than a 1kHz tick interrupt.

But FreeRTOS likely isn't the solution for that use case, either.


--- Quote from: NorthGuy on October 17, 2021, 03:56:39 pm ---
--- Quote from: mikerj on October 17, 2021, 01:16:20 pm ---An RTOS does not prevent direct access to peripherals, interrupts or DMA.  Even if you are using a simple scheduler or a conventional superloop with state machine you would still need to provided protection to  shared resources like DMA that run outside of a tasks execution.

--- End quote ---

While DMA transfer is in progress, you will have a flag which tells you that. You can poll the flag if you wish, or, if you want to react sooner, you can create an interrupt which fires immediately as the DMA transfer is finished. Moreover, you can assign priorities to interrupts. Say you can configure priorities in such a way that the DMA interrupt does happen, but not if fast ADC interrupt is in progress. Or perhaps your DMA controller may be clever enough to trigger a different DMA transfer once the first one is done. All these mechanisms are already there, and there's absolutely no need to use RTOS to duplicate them.

--- End quote ---

And I haven't suggested there is.  I saying that shared resources who use does not start and end within a "tasks" allocated time need some form of mutual exclusion to prevent collisions and race conditions.  Polling the DMA flag might be good enough, but equally it might not be, this is exactly the kind of thing that can cause race conditions.

--- Quote from: NorthGuy on October 17, 2021, 03:56:39 pm ---The new thing that RTOS add, which wasn't already there, is multi-threading. It lets you run multiple threads (tasks if you wish) which can preemt each other and thereby share the CPU creating an illusion that each task runs on its own CPU. This lets you write your code in  linear fashion - if you need to wait for something, you just block the thread and then, when the condition is satisfied, the thread continues automatically. Without RTOS, you would have to write non-blocking code - if you want to wait for something, you would have to find a way to continue other tasks and poll periodically for the condition.

--- End quote ---

This isn't even true, there are cooperative only RTOSs and RTOSs that can be configured to only work cooperatively.  A good RTOS brings far more to the game than you seem to think they do.

--- Quote from: NorthGuy on October 17, 2021, 03:56:39 pm ---The decision between using RTOS or not should be based on whether you want to write blocking or non-blocking code. Blocking code is arguably easier to write, certainly much easier to find on the Internet. But to use it, you would have to bring in the RTOS.

--- End quote ---

Again no. Even if you write non-blocking code (e.g. state machines) then you are very likely to want some kind of priority scheme, and some way of passing data between your "tasks" or synchronising them.  All the stuff that's built into an RTOS, but reinventing the wheel can be fun too.

The fact is that available CPU and MCU architectures are designed to run without RTOS. That is why problems you think appear when working without, in reality mostly do not exist. You would see that immediately if you actually did this work. I have never ever had to even remotely think about a race condition accessing DMA. This hasn't even crossed my mind. DMA peripherals are designed to work fine from bare metal code. Interrupt priorities exist for a reason, too.

But I don't need my code to be in "linear" fashion with wait-for-something-else inbetween. I'm fine writing nonblocking or "callback-like" code.

The RTOS scheme is all backwards; instead of RTOS solving a problem, RTOS invents problems then solves them. If you work logically backwards thinking that "oh, RTOS solves this problem -> removing RTOS removes the solution -> problem remains", you get the logically wrong result.

This is not saying RTOS does not have possible strengths, not at all. But the argument that life without is difficult because of shared resources like peripherals is just complete and utter.... I don't even need to say it out loud. This is a FUD argument. Instead, why wouldn't you concentrate on telling us what are the strengths and benefits of RTOS? Without coming up with made-up problems that supposedly happen without, because there are experienced developers who immediately see these are made-up problems.


--- Quote from: mikerj on October 18, 2021, 10:47:50 am ---All the stuff that's built into an RTOS, but reinventing the wheel can be fun too.

--- End quote ---

Oh, "reinventing the wheel" again. Look at it this way. Many, if not all of these things, existed before RTOSes. So, following your logic, RTOSes are nothing more than reinvented wheels :)

"Reinventing the wheel" is one of the most misused metaphors.

Really it means taking something old, that works really well and can't be improved by making large changes, yet change it fundamentally to turn it into something new that performs worse, for example make it square. This happens all the time, but "not using RTOS" is not such case. Opposite could be said arguably, though.

But it follows the logic of these RTOS people. In their world view, the RTOS is the only way to do anything more complex than a LED blinker, and if you don't use it, then it logically follows that you are writing your own "RTOS equivalent" each and every time from scratch, and doing it in inferior way, hence "reinventing the wheel". If a scheduler in RTOS is 1000 LoC, the logical conclusion is, if you don't use it, you have to write your own scheduler which is also at least 1000 LoC and likely worse because it sees less testing and is done in hurry compared to a well-designed RTOS. But this is complete fallacy if and when you don't need an OS scheduler at all.

We are not alone with this view. Not using RTOS can be a marketing argument showing how widely people are sick about "having to use" RTOS. For example, Fanstel markets their BC833M product family (well, basically Nordic Semiconductor microcontrollers) with this statement:

"The embedded stack interface uses an asynchronous and event driven model removing the need for RTOS frameworks."

source: https://static1.squarespace.com/static/561459a2e4b0b39f5cefa12e/t/60270895e454bd0fb5d24793/1613170839894/BC833M_Product_Specifications.pdf

This is actually a pretty good one sentence description how embedded MCU development is normally done. It's good they tell this because with such clear information, the actual implementation team can convince their boss that no, RTOS is not desirable in the project.


[0] Message Index

[*] Previous page

There was an error while thanking
Go to full version