I hope that I will get the correct answer to my question on this forum which I have been searching for for a long time.
There is no doubt that RTOS is in great demand in the market. Recruiters also prefer profiles of candidates who have RTOS knowledge.
RTOS is useful where guaranteed response time is required
But I don’t understand when we should use freeRTOS as compared to the traditional programming method. I have not found any real-world application in which freeRTOS can be used instead of the traditional programming method.
If there is only one, two, or three time-critical tasks are in a system. Would it be better to use freeRTOS instead of the traditional programming method?
as far as I can understand if there are so many says (50 +) critical tasks are in a system that requires a guaranteed response time. then using FreeRTOS can be beneficial
please define “the traditional programming method.” FreeRTOS is an operating system, not a programming style or paradigm. Are you asking why use an RTOS over a desktop operating system? Or why use an RTOS instead of a single message pump? In the latter case, the question is not “why” but “where.” There are scenarios in which a single main loop acting as a messager pump or similar is sufficient; it all depends on the degree of concurrency required by the application.
The way you formulate it makes it very difficult to stab guesses at an answer.
Using an RTOS tends to make sense once you have operations at multiple levels of urgency.
By the ‘Traditional’ method, I am presuming the single-thread monolithic event loop. The problem with this method and levels of urgency is that all slower/less urgent operations need to be broken down into small pieces, short enough to meet the requirements of the most urgent operation, and checking if something urgent has come up since the last check.
With an RTOS, you can divide the program into separate tasks, and when a higher priority task becomes ready to run, the RTOS will just switch to it, so the lower priority tasks don’t need to do anything to make sure the high priorities get meet.
They do need to pay some heed, as if they take any lock needed by a high priority task then can block the higher priority task that needs that lock.
If the question is about when to use multithreading, then that is a judgment call based on your own experiences and preferences. Always use the right tools for the job - sometimes multithreading, sometimes single threaded, but its subjective as to what “right” means. To me one of the key points in maintainability as complexity grows - what is the cost over the lifecycle of the product (note “product”, not “project”). A good example is our TCP/IP stack, which runs in its own thread, can be developed in isolation, can be used in multiple projects, can be prioritised in accordance with whatever else the system needs to do, can be tested by itself…and removes any requirement for the application writer to care about what is happening on the network at all (almost).
I wrote this page a very long time ago - it may not stand up to scrutiny today
…and one more issue to complement what the two Richards wrote: All the arguments we brought forward first of all apply to ALL RTOSs, not only FreeRTOS. What makes FreeRTOS different from other approaches to real time computing is a different question altogether…
My instructor told me if running on a chip like an 8 bit AVR, will be slower if using an RTOS. just adds overheads. its best to using interrupts and a while(1). The point is that RTOS brings no benefit.
He gave example : if the system that has only one tasks that’s need Guaranteed response time, Does it actually need a RTOS ? Why would you need a RTOS for a single task?
I got confused by his question. That’s why asking here He say’s he has more than 30 years of experience but he never need to use rtos he just use tradition method using interrupts and a while(1) loop.
The question becomes, can the ‘high priority task’ be JUST an ISR. If so, you might not need an RTOS. Sometimes this is true, but often it is not. This can especially true for very simple processors that can’t nest interrupts.
He’s right in that respect: IF there is no need for concurrency, there is no need for support for it.
Yes, but either he has been an instructor for 30 years and therefore never had to write anything more complex than a blinky app, or he has managed to find a niche that pretty much failed to go beyond about 1995.
I myself have been writing embedded firmare for 25+ years now, and I remember very shadily the early days when hardware and requirements were so simple that, yes, you could pretty much get away with a while() loop. Yet, today’s MCUs do have enough memory and speed to serve several concurrent tasks; plus, for at least 15 years every meaningful embedded application had at least two different concurrent tasks to accomplish: Some kind of “application” (reading sensors, cards or whatever) and propagating those ovwer a host interface. Frequently there is also some kind of service or diagnostic task, and that is where a single message pump becomes terribly awkward and unmanagable.
Looks like your instructor should take some time off to arrive in the real world…
No, that is not what that means. FreeRTOS will work fine with any single threaded app (as every Blinky app will prove). But the main purpose of any RTOS is to arbitrate and coordinate multiple concurrent threads of execution (ie tasks and ISRs). Again, the higher the degree of concurrency in a given system, the more you will benefit from using an RTOS. There is tons of literature out there to prove the point, ie take the chapter on scheduling of any 101 textbook on operating systems.
Then again, if your instructor feels like disproving ideas that have been around and worked in bazillions of applcations in the field, have him or her make the point here. I am willing to put a lot of money on the table to argue that nobody with sufficient experience in the field will question the usefullness of RTOSs in even mildly concurrent embedded applications.
End of discussion on my side here, let us go back to work…
EDIT: Another point your instructor probably is right about is that an OS does take away some degree of determinism and predictabilitiy from your system. HARD real time is best accomplished with full control over all of your control paths. Yet I doubt that your instructor is focussed on teaching you to design space warrior robots or something that else that requires hard real time.
