Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Small open source project

Posted by Ban Moris on 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

RE: Small open source project

Posted by Dave on 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.

RE: Small open source project

Posted by Ban Moris on 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?

RE: Small open source project

Posted by Dave on 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

RE: Small open source project

Posted by Ban Moris on 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?

RE: Small open source project

Posted by Dave on 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.

RE: Small open source project

Posted by William Davy on 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

RE: Small open source project

Posted by Dave on 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.

RE: Small open source project

Posted by William Davy on 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.

RE: Small open source project

Posted by Richard on 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.

RE: Small open source project

Posted by Ban Moris on 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...

RE: Small open source project

Posted by Richard on 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() [or portYIELD_FROM_ISR() depending] 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.

RE: Small open source project

Posted by Ban Moris on 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?

RE: Small open source project

Posted by Adam Turowski on 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).


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists