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

General FreeRTOS Question

Posted by Terry Ohm on February 15, 2010
Hello,

Hi. I'm new to FreeRTOS, and had some questions about the "Using the FreeRTOS Real Time Kernel - A Practical Guide.pdf" manual.

1) On page 28 there is a statement concerning the Idle Task Hook (where you can put user defined code into the Idle Task: "Blocking the idle task in any way could therefore cause a scenario where no tasks are available to enter the Running state!". I know NOT to do this, but if the Idle task is the lowest priority, why would it block higher priority tasks? Does blocking the Idle task prevent the Kernal from transitioning task execution?

2) .On pages 26 and 27 it descusses how a periodic high-priority task preempts two lower priority tasks when a given time is reached. According to the output, the high priority task only prints its message after the time is reached. Should it not also print out its message as the first line of output, since it is the highest priority task?

I would appreciate any insight. Thanks.

Terry

RE: General FreeRTOS Question

Posted by Richard on February 15, 2010
“1) On page 28 there is a statement concerning the Idle Task Hook (where you can put user defined code into the Idle Task: "Blocking the idle task in any way could therefore cause a scenario where no tasks are available to enter the Running state!". I know NOT to do this, but if the Idle task is the lowest priority, why would it block higher priority tasks? Does blocking the Idle task prevent the Kernal from transitioning task execution?”


As you rightly say, the idle task does run at the very lowest priority, so will not block a higher priority task from running.

The passage you refer to says not to cause the idle task to block, not because it will block higher priority tasks, but because if the idle task does block then it is likely there will be NO tasks that are available to run and there must always be at least one task available to the kernel for scheduling.


“2) .On pages 26 and 27 it descusses how a periodic high-priority task preempts two lower priority tasks when a given time is reached. According to the output, the high priority task only prints its message after the time is reached. Should it not also print out its message as the first line of output, since it is the highest priority task?”


The images only show a snapshot of the output, which does not start at time 0, so you cannot see the print out occurring.

Hope this helps.

Regards.

RE: General FreeRTOS Question

Posted by Terry Ohm on February 15, 2010
Thanks you very much. That makes sense about the Idle Task hook -- There should be no reason to block the Idle task, since the program should at least be doing something.

For the second question I know the output is cut off, but according to their execution diagram on page 27, at T1 the high-priority task does not print its string initially (as I would expect). Just wondering if that might be a typo. Thanks.

RE: General FreeRTOS Question

Posted by Richard on February 15, 2010
My page 27 has a screen shot on but not a diagram. Are you looking at the diagram that is labelled "The execution pattern of Example 6"?

Regards.

RE: General FreeRTOS Question

Posted by Terry Ohm on February 15, 2010
Yes. In my document there is a diagram labeled "Figure 12 The execution pattern of Example 6" under a DOS-box output labeled "Figure 11 The output produced when Example 6 is executed". Figure 11 shows at T1 Continuous 1 runs, at T2 Continuous 2 runs, etc., until T5 when the Periodic task finally runs. Maybe your documentation is different (mine says Copyright 2009); I don't think I can use this forum to send the diagram.

RE: General FreeRTOS Question

Posted by Richard on February 15, 2010
Ok - we are looking at the same diagrams, but I'm still failing to understand your point. Maybe I'm being a bit thick here.

In my diagram 12, the text above T5 reads:

"4 - At time t5 the tick interrupt finds that the Periodic task block
period has expired so moved the Periodic task into the Ready
state. The Periodic task is the highest priority task so
immediately then enters the Running state where it prints out its
string exactly once before calling vTaskDelayUntil() to return to
the Blocked state."

So this is saying that the periodic task prints out its message as soon as it starts to run, then blocks itself again.

In diagram 11 the output produced by the program is shown, but not from any particular time so imagine it has been running for a while. If it was shown from the beginning then the message from the periodic task would be the first that was shown.

Am I getting closer?

Regards.

RE: General FreeRTOS Question

Posted by Terry Ohm on February 15, 2010
No maybe I'm just thinck. I just thought (assuming all tasks were created at the same time) that since the Periodic task has the highest priority, it would run through printing its message until it was blocked (vTaskDelayUntil). I assumed that "Time 1" was the start of the program, and therefore would show the Periodic message being printed out right off the bat, before either low priority task had a chance to do anything.


[ 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