ag09 wrote on Sunday, September 11, 2011:
Hi all,
I am very interested in using FREERTOS. I would kindly ask the member of this forum if there is any open source project which employs the FreeRtos that schedules real-applications. I mean that the FreeRtos communicates a physical environment…
Best regards
davedoors wrote on Sunday, September 11, 2011:
It is in the nature of an RTOS that it interacts with its environment. Any application you find that uses FreeRTOS will communicate with a physical environment.
ag09 wrote on Sunday, September 11, 2011:
Sure, but I meant if there is any open source application or project that demonstrates this communication. I just want to understand how the freeRtos interfaces the physical environment by downloading an example on a target hardware and analyse the behaviour. However, I find it a bit difficult to start from the scratch.
Any suggestion?
davedoors wrote on Sunday, September 11, 2011:
The FreeRTOS download has many projects that include things like ethernet and uart IO. Look in the FreeRTOS/Demo directory. Each one is documented on the FreeRTOS site too. http://www.freertos.org/a00090.html
ag09 wrote on Sunday, September 11, 2011:
many thanks for your quickly response.
is it true that freertos can only meet soft time requirements. What is about the hard time requirements?
davedoors wrote on Sunday, September 11, 2011:
is it true that freertos can only meet soft time requirements
There are lots of false rumors about FreeRTOS, but even I have never heard that nonsense before.
williamdavy wrote on Sunday, September 11, 2011:
Hi Dave,
To be pedantic, FreeRTOS tends to be a soft real time system. The only guarantee that is provided is that a Task is moved to the Ready List based on the tick count or an event (queue delivery, etc). If there is a higher priority task then that will run instead meaning that the deadline is missed. In FreeRTOS, missed deadlines are expected and are part of the normal operation.
Indeed, if I had to write code that had to respond within a particular time, a critical deadline, it would tend to be in the interrupt context if it were short/quick so as to avoid the overhead of the OS task switching time entirely.
Good system design will allow you to get very close to hard real time performance but the OS doesn’t impose it.
Regards,
William
davedoors wrote on Sunday, September 11, 2011:
If you define hard real time to be nearest deadline first scheduling then you are right, but that is academic land. Hard, soft, are all ill-defined terms. FreeRTOS is a prioritized preemptive scheduler, like all of its commercial peers in the same class. It has no concept of a deadline, you give tasks priorities, not deadlines. It does have a concept of priority. The app writer knows what the deadlines are, and if the app being written can meet them or not through analysis knowing that FreeRTOS makes a promise to run tasks in priority order. Because analysis, if needed, provides certainty, by nearly all definitions it is hard real time. Math analysis is easy and provides certainty, but for most users that is overkill.
williamdavy wrote on Sunday, September 11, 2011:
I agree with you, Dave.
The determinism gives the hard real time capabilities but it requires the system designer to realise that. My point was that the OS doesn’t force you into it, allowing application code to manipulate the scheduler and enable/disable interrupts are just two examples of features that demonstrate the soft real time of the OS. Most people are likely to be using FreeRTOS to provide concurrency with the time dependent stuff running at higher priorities, exploiting the guarantees that the OS provides.
Platforms such as the Cortex-M3 are particularly good because the interrupts are masked based on priority meaning that critical stuff can run outside of the OS with almost no jitter or delay.
In response to ag09, FreeRTOS can be used in Hard real time systems. However, you have to design your system to do so.
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.
ag09 wrote on Monday, September 12, 2011:
many thanks for all your replies.
@Richard: your explanation about using interrupt to meet hard time requirements leads me to another question that if I can schedule the task through interrupt then the Rtos does not differ in this case so much from linux OS since I can there allow any task to be immediately scheduled by setting an interrupt with high priority….
Please correct me if I ma wrong…
rtel wrote on Monday, September 12, 2011:
Yes, tasks can be scheduled from interrupts, and if the task that is scheduled by the interrupt has a higher priority than the originally interrupted task, you can use portEND_SWITCHING_ISR() to return directly to the scheduled task. That is called deferred interrupt handling and is normal practice.
Look at the API reference for any API function that ends in …FromISR(), and at the example interrupt routines in the demo projects for examples of how that is done. Also look at the interrupt nesting section http://www.freertos.org/a00110.html#kernel_priority to see when it can be done, and if it meets the needs of your system requirements.
Regards.
ag09 wrote on Tuesday, September 13, 2011:
I looked at the API and I understood more about interrupting. But I am still having trouble understanding if there are any major differences between Linux and FreeRTOS if I only use priority-based Interrupt function to schedule tasks? are there?
aturowski wrote on Tuesday, September 13, 2011:
Linux kernel is not real time kernel because no one cares to make sure to have critical sections extremely short and actually specify the maximum length of critical section. This is fair enough, because this is not Linux kernel design goal.
FreeRTOS is likely to be more responsive to the interrupts and actually you can calculate how responsive it will be (by knowing maximum length of the critical section).