3

Can anyone explain to me what is the difference between an embedded program with and without RTOS. As when i start learning embedded, I always write code without any OS, all code is separated in to sub function and main function, sub function is called inside main function and it still run correctly, why does it still run without OS? And if I add RTOS to my code, what would happen? All answers are appreciated, thank you so much

OptimusPrime
  • 97
  • 5
  • How or where do you run your code? What do you mean with "add RTOS to my code"? – ledwinder96 Jun 14 '19 at 06:46
  • this isn't a bad of a question though. A RTOS is platform independent and therefore irrelevant what platform is used. And a RTOS can be integrated into any code so the code in question is not relevant. The only relevant thing is *why a RTOS is useful* – Tarick Welling Jun 14 '19 at 08:27
  • Have a look: http://www.keil.com/rl-arm/rtx_rtosadv.asp – Mike Jun 14 '19 at 09:05
  • From your context by RTOS you mean just multitasking OS, not necessarily a Real-Time one, right? – tonypdmtr Jun 14 '19 at 22:09
  • 1
    Imagine some tavern with lots of clients and the owner taking orders, preparing them, serving them, getting paid for them, cleaning up all the tables afterwards, etc. Now, try the same tavern with a dedicated cook, a few waiters, a cashier, and a busboy all working in tandem. Which scenario do you think works better? – tonypdmtr Jun 14 '19 at 22:28
  • The question is verging on the "too broad" perhaps. One of the best explanations I have come across is the ["Real Time Concepts" chapter](https://doc.micrium.com/display/osiidoc/Real-Time+Systems+Concepts) of the uC/OS-II book by Jean Labrosse. Essentially an RTOS makes it easier to schedule your application's tasks deterministically and to meet real-time deadlines. If your applications are simple and not appropriate to multi-threading, or have no hard real-time constraints, you probably don't need one - though there may still be advantages. – Clifford Jun 24 '19 at 23:49
  • The question is written well (+1), newcomers to embedded programming (and senior embedded programmers without RTOS experience) should all ask themselves this question once. The formulation also points to typical misunderstandings, what an RTOS may ever add to functions and subfunctions. – HelpingHand Apr 11 '20 at 17:14
  • In the result, I agree with @tonypdmtr 's last comment, but in order to help the answerer, we have to give help "how to manage a team that drives a tavern?". To stay with that metaphor, not every innkeeper knows how to start employing people (4 or more at once) and become more efficient and profitable - without going bankrupt after the first systick period, err, payroll month. – HelpingHand Apr 11 '20 at 17:17

2 Answers2

1

You didn't give any context to the question, but let assume you are trying to program some kind of micro-controller with a development environment that allows you to run with free RTOS.

Running without RTOS is the simple case you already understand - Your program starts in the main function and runs whatever loop or set of actions you have programmed.

Running with RTOS would add a set of .c files that, for the most part, implement a scheduler. You would then need to register the functions you want to run periodically as tasks in the scheduler before it starts its main loop. So the implementation of the OS would become part of your project, and compile along with your program.

To summarize, If you have decided you need to run multiple tasks, and that a scheduler would benefit your system, you can add RTOS instead of implementing the logic behind your loop on your own.

Nomios
  • 151
  • 7
  • 3
    That is a somewhat simplistic explanation of the behaviour of an RTOS. Certainly real-time tasks do not typically run "periodically" but rather respond to _external events_. Simple periodic execution can be achieved without an RTOS, What an RTOS adds is _pre-emptive priority based scheduling_, thread synchronisation, resource locking and inter-process communication mechanisms that when used correctly can deterministically guarantee reaction time to real-time events. – Clifford Jun 24 '19 at 23:34
  • 1
    Thanks for the clear-up, I agree that the response does not address the reasons to use RTOS correctly, I'll edit the answer to make it more accurate. My intention was to target the real nature of the question. My guess is that people who will in the future look for this will be at the stage where they know what an OS is, more or less understand simple bare metal programs, and try to step up to the more serious stuff, where the internet starts to get unfriendly for enthusiast programmers. – Nomios Jun 25 '19 at 22:35
1

what is the difference between an embedded program with and without RTOS [...]

I always write code [...] separated in to sub function and main function, sub function is called inside main function and it still run correctly

You mentioned the perfect starting point for answers: As you partition your code into separated functions, modules or classes (if we think beyond languages like C and assembler) by using function syntax and entering separate translation units into your linker tool, you can use an RTOS to partition the CPU the software runs on like if you had multiple CPUs, using a different one for every thing your software shall achieve. Please replace "achieve thing" by "run task cycle" now.

Note that unlike the function/module separation, the task context separation is not supported inside your programming language if you are using C or C++, for example. Therefore, you will have to integrate this separation with more manual work.

why does it still run without OS?

Don't confuse the RTOS/OS kernel with what you get if you visit Microsoft or the GNU/Debian/Fedora/SuSE Foundation (or Apple or Google or IBM or ...) and ask for an OS - they'll give you the actual OS kernel with lots and lots of applications that may be quite necessary to make productive use out of your target system (PC/handy) at all.

When talking about RTOS, we always consider the RTOS kernel. When talking about OS, we mean the kernel (unless we think of the pars pro toto usage as with "OSes" like Windows, Linux etc., which won't happen very often on SO). The kernel of an (RT)OS is the component that organises when to run a task and when to suspend it.

And if I add RTOS to my code, what would happen?

At first, nothing: You could apply an RTOS configuration with one single task and stuff the current implementation of your main loop software into that singleton task. This should work without limitations (If you take the parallelism to structure programs into functions - a main function is already the first function...).

But now you can start with a decomposition (architecture) of your software, adding tasks one by one, with small interfaces to the others. The RTOS library will implement those interfaces by providing you with inter-process communication elements (events/queues/mailboxes).

In an ideal RTOS-based architecture, every task shall receive its work packets as items from a mailbox (or event, or queue etc.). Whenever there isn't another item (message, event, queue data etc.) for the task, the RTOS kernel will block the task and switch over to another task that is ready for execution. This way, only tasks that have work to do will actually consume CPU time.

If there are multiple tasks which are ready for execution, the choice which task will run next depends on the scheduling algorithm, which you have to select when configuring the RTOS library. Usually, the tasks in a typical embedded system are assigned different priorities so that a task will only occupy the CPU if there is no ready task at higher prioity. Hence, an RTOS offers you a perfect solution to implement a system that implements both urgent and non-urgent tasks, e. g., tasks with and without real-time requirements.

Community
  • 1
  • 1
HelpingHand
  • 1,294
  • 11
  • 27