rtel wrote on Monday, September 12, 2011:
I think this thread has gone off its original topic, and it is difficult to reply without writing a thesis. What is certain though is that you will never get agreement unless you first agree what you mean by hard real time. In its most basic form, if a system is deterministic then you can argue it is hard real time. You then get into another argument about what scheduling algorithm gives best determinism, but that is to miss the point, it makes no difference to whether a system can be used in an application with hard real time requirements or not.
Example 1: An airbag
This is the example most often used as hard real time. A crash sensor senses a crash and the airbag must deploy within x milliseconds. It is difficult to argue against that being hard real time - it is a real deadline to meet as not meeting it has dire consequences.
So can software scheduled by FreeRTOS be used in this system?
Yes - on two counts. First, critical section times are deterministic, so the schedulability of the system can be calculated up front. The calculation may show that the deadline will always be met even when the deployment is performed in a task. If the calculation shows the worst case critical section is too long, then most newer FreeRTOS ports never completely disable interrupts - so you can implement the deployment of the airbag in an interrupt.
Example 2: Motor control
Many brushless motor control systems use commutation algorithms that need very strict timing - maybe the algorithm needs implementing every 2ms.
Is that a hard real time system? Well, with just the information I have provided above, you can argue no it isn’t, unless you put some sort of frequency deadline on top of the temporal deadline. If the 2ms “deadline” is missed, nobody will be the wiser if it happens once in every 1000 cases. So it is not a deadline with any real meaning on its own. If you say, the deadline must not be missed any more than 1 in 100 times, because that will adversely effect the behaviour, then you are starting to describe a hard real time requirement. (again you could use FreeRTOS in such a system, and indeed I have done, but relying on interrupts.
Example 3: Bank statement printing system
Here a bank statement must be printed withing two days of the end of the month. Now we are talking days, not milliseconds - is that a hard real time requirement? Depends on who you ask. It is unlikely to warrant a real time operations system whatever the conclusion of the argument, though.
You can argue around the grey areas in between every point for ever. I try not to, though.