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


Blocking, Semaphores and printf

Posted by Louis Everett on September 25, 2010
I "thought" I understood how the scheduler worked but I need some help.
I am running freertos on a pic32, using a starter kit and MPLAB.
I started with an example that creates two tasks that use semaphores to pass strings to a routine that "takes" the semaphore uses the printf command to print the string to the output. Works fine.

Now. I created a third task with a higher priority than the other two "printing" tasks. All it does is block for 1/2 second then unblock and toggles an led.

If I comment out the printf statement the led blinks once per second as expected. If I keep the printf statement in, the led blinks erratically. It appears that the printf statement doesn't yield. There is no vTaskSuspendAll turning off the scheduler.

I would have expected it to yield to the blinker. Obviously I don't understand something. Can anyone help explain this to me?

RE: Blocking, Semaphores and printf

Posted by Richard on September 25, 2010
How is printf() working, where is it printing too, and is it buffered or non buffered.

If you are printf()'ing down to the debugger then it can take a long time and will be uninteruptable, if it is non-buffered then even worse. You are taking the execution out of the control of the scheduler and so I would not expect it to behave in a real time way.

If you are printf()'ing to an efficient UART driver, then that would be different, but it still depends on how the printf() library is implemented.

There are a lot of questions where people say I use printf() and evereything stops working, generally printf() is not something that I would expect to work well on a small microcontroller unless you are using a big stack, and the library function is redirected somewhere that is not going to effect the debuggers run time timing.


RE: Blocking, Semaphores and printf

Posted by Louis Everett on September 25, 2010
Thanks this is a big help. I don't know the answers really but what you are saying makes sense.
It is printing to the debugger. I had assumed it was interruptible BECAUSE an earlier example i was following had placed the printf inside a critical section (vTaskSuspenAll etc.) so I "assumed" they were showing me that the printf was interruptible. I think I will experiment a little with that example.

It does make sense that the printf "turns control" to the debugger and that the scheduler cannot interrupt the debugger since its not "part of the chip".

Let me ask a follow up question. If I use any regular library routine that deals with on board (on chip) registers exclusively, no debugger is involved, then it seems to me that the only way it would be non-interruptible would be if the library routine turned off ALL interrupts. I understand maybe the library is non-reentrant and other "dangers" could exist BUT if a standard library turned off all interrupts for an excessive length of time it would cause serious problems with all programs not just FreeRTOS. Is this logic sound?

RE: Blocking, Semaphores and printf

Posted by MEdwards on September 25, 2010
Looks like sound logic to me, but I would not expect a standard C library to every mess with interrupts. Libraries that deal with peripherals (rather than ANSI libraries) probably will though. Also on some systems trap instructions are used to make calls to an underlying BIOS - DOS is an example of such a system.

RE: Blocking, Semaphores and printf

Posted by Louis Everett on September 25, 2010
yes its all coming together for me now. Thanks for the help.

I did some experimenting to get a better idea of what is happening and you two are exactly correct.

in the example i was following, the one that made me "think" the printf was interruptible, there are two functions being used, a printf followed by a flush. My experiments are indicating that the printf does not yield (not sure about the flush since it runs so quickly) BUT it will yield between the printf and the flush (which makes sense) hence the need for the critical code section, to prevent yielding between the printf and the flush.

I'd say it ALL makes sense now, but I'm sure there are new discoveries for me ... waiting patiently.

Thanks again.

[ 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