Take an extreme case like the attempt to drop power in a motor control before a spike blows up your MOSFETs. The rest of the circuit might just be responding to button presses, variable resistors, water pressure sensors and such; something where real-time could be measured in a few tens of milliseconds.
The current spike protection might need to respond much faster than that. One might run the current sense into a GPIO of the MCU thinking that an interrupt on change could be used to drop or cut the power before any damage is done. First though, there's the delay in the current sense hardware. Then the read time for the port, the ISR delay and then into the code to take the action.
Such a scenery might require external hardware that has the greater real-time speed than is possible within the RTOS or even a MCU without any type of OS.
The question of "What is Real Time?" has been quite a problem for control and robotic systems. All too often, an OS is advertised as "Real Time" when the truth is far from it. While the definition may vary based on the system needed response times, I like to use the concept of Repeatability. If the OS can guarantee the repeating of code blocks in the same period / time frame then it "could be" considered "Real Time". I use this concept to address the various issues of speed to process, lag and response times, interrupt overhead, etc. A simple multi-tasking OS is not real time unless there is a fixed scheduler with enough processing capacity to service all the needed tasks without interference with the others. I am sure that there are better definitions and would welcome them for review.
Duane, it is true that there may well be things that need a more timely response than the MCU can provide so knowing what the RTOS can achieve with your hardware is an important piece of design information. It's the boundary between needing an OS and needing an RTOS I was trying to explore, though.
RD, I think that an OS that guarantees repeating code blocks in a specific time frame is one form of RTOS, and one often called for in safety-critical systems because it is essentially "deterministic," but I think anything guaranteeing bounded execution time for any desired piece of code under all circumstances (including resource contention, priority inversion, and the like) would be an RTOS.
But I agree, there must be better definitions out there. Let's hear some more.
Didier_Juges 2/9/2012 8:41:35 PM User Rank Blogger
Re: What about multiple definitions?
I think the real factor is if the response time of the OS is "deterministic", i.e. predictable and within a fairly narrow range.
The problem with Windows and most desktop OS'es is that most of the time, when you press a key or click the mouse, something happens "pretty fast" but sometimes not. That's because within the OS there are many blocking calls, and the OS has to finish what it is doing before handling the next request. Sometimes what it is doing while blocking is waiting for a response from a driver, and that can depend on external factors, therefore it is not deterministic.
A Real Time Operating System has very few blocking calls and those blocking calls have finite duration, which guarantees that something will happen in response to an external event within a certain time.
It does not have to have a certain speed, just that the response time is bound.
Perhaps its a matter of semantics, but I consider "deterministic" to mean repeatable within a narrow time window while "bounded" in the case of the RTOS is an upper bound only. Few real-time systems care if the response is faster than required, but they all care if it is slower. The added restriction of being "deterministic" seems to mostly arise when there are safety issues involved. Being able to prove something will happen within a narrow time window gives assurance that nothing unexpected will ever happen.
I think you can construct a mathematical model that captures a formal definition of "real time." It would begin with the notion of an event e, and the probability Pe(T) that a system fault will occur if event e, occuring at time t=0, is not serviced within T seconds. Start with the assumption that Pe(0) = 0 (no chance of a system fault if event is is serviced instantly) and that limit (Pe(T)) = 1 as T approaches infinity (an event that is never serviced always produces a system fault). A system is "K Real Time" if Pe(K) < R for some agreed-on value of R (0 < R < 1).
Granted this is a crude first cut at a model: most systems we work with handle ensembles of events, for example. But then simple models are the engineer's stock in trade. I think it's a start anyway -- certainly some distance from perfection.
northstar 2/10/2012 4:22:32 AM User Rank Program Manager
Re: What about multiple definitions?
Didier, I agree that "deterministic" is a requirement for an RTOS: designers or developers need guarantees that a flow is always executed that way. How many RTOSes are really deterministic at this time ... well, it is hard to prove. I also agree that an RTOS needs to guarantee a max time for an operation. To be honest, I think that we can talk about an RTOS only when speak about kernel or scheduler. Many (if not all) RTOSes comes with a TCP/IP stack or a filesystem stack. I really doubt that this code can be guaranteed to be deterministic.
And I think another clue to identify an RTOS is to be ... small :-). I think that is really a requirement, because otherwise is hard to keep a lot of code in certain time bounds. I think that Windows or Linux (not embedded) do not want to have "blocking" code, but the hw underneath is so complex, that simply they cannot achieve the goal. Let's take an RTOS (MQX for example or uC/OS) and put them on latest Pentium i7. It will work and will be an RTOS, but probably the only operation will be to write some characters on a simple display. And probably it will use like 0.0001% from hw power. Do we want more? Than bye-bye RTOS guarantees.
You write "How many RTOSes are really deterministic at this time ... well, it is hard to prove." I think the answer, though, is that NO RTOS can be truly deterministic in operation beacuase our interrupt events are occuring asynchronously, and they have to be prioritized and queued for service (because our processors are "single pipe"). In the end, this means that we can only form a statistical picture of the latency an event will experience before being serviced: it will depend on what else is going on in the event environment.
Even the humble 7474 D-flip flop isn't strictly deterministic, since a D input event and a CLK input event that happen at just the right times can turn it into a nice ramp generator.
Didier_Juges 2/10/2012 12:06:03 PM User Rank Blogger
Re: What about multiple definitions?
I think in that context bounded means that there is a maximum response time, and deterministic means that the response time is free from external influences.
Of course this must be more specifically characterized, because the assumption is that only a minimum amount of work can be performed under interrupt before leaving the ISR so that the next interrupt can be serviced.
You do not need a fast processor to have a fast response (of course, most uC systems have much faster response time than desktops with multi-GHz processors), but you need a fast processor if you want to do much before the next interrupt.
But even that is not a hard rule. It depends on your environment.
The commercial TCP/IP stack I have been using on an ethernet connected 8051 project blocks for something like 5mS (processor speed dependant obviously) after receiving a packet, even if the packet is not for this client. It turns out that the stack copies the entire ethernet buffer to RAM before checking the destination address. Since the ethernet buffer is already memory mapped, it would be much more efficient to check the destination address before copying the buffer, so that the content could be immediately discarded if the address does not match. In my application, 5mS was not a major problem, but it was close. That product is advertised as being compatible with RTOS, but they wisely stay away from claiming that the stack itself can meet hard real time requirements.
To save this item to your list of favorite Microcontroller Central content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
