Quality RTOS & Embedded Software

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




Loading

Printf()-like task

Posted by hermarcel on October 17, 2013

I am trying to delegate the actual execution of printf()'s to a seperate task. The call to my variant of printf() should only queue a message for the printf()-task. Does anyone know of a portable way to pass the caller's arguments using a queue (both ends)? Preferably without the need of examining the format-string on both sides.


Printf()-like task

Posted by davedoors on October 17, 2013

Have the task that creates the string sprintf() the string to a buffer, then pass a pointer to the buffer on the queue to the task delegated with the actual output.

Check your sprintf() function is thread safe. Should be if it targets embedded.

The buffers can be pre allocated if you have enough RAM, with the task that actually does the output marking the buffer as free, or adding it to a free list, once its contents have been completely output.

Just one idea. There are probably other ways of achieving the same thing. If your output only contains constant strings then there is no problem of course, you only get issues when the strings are created dynamically.


Printf()-like task

Posted by hermarcel on October 18, 2013

I would like to have the "formatstring+argument"-processing done by the printf-task as well.


Printf()-like task

Posted by dragonflight1 on October 27, 2013

well the question is how careful you want to be, and if you don't have to be completely general. I have just done this, but I simplified it by limiting the # of arguments to a reasonable size (I chose 6 - but then I'm writing to a 2x16 character display!).

On the transmitting side you use a variadic function and copy the maximum # of arguments you want to support (remember longs and floats count double and of course doubles count 4 times)

On the receiving side you can just create a function call fprintf( fmt, arg1, arg2, arg3 ,,, argn );

fprintf will not care if there are extra arguments and the longs and long longs will "reassemble" themselves.

In my case I assumed - specified/restricted - the formats to be constant and universally accessible and passed a pointer to the format and then the actual arguments in a single struct through a queue.

Because you are fetching a fixed number of arguments it is possible that this can cause a problem, but on most machines they are stored on the stack and unless you go crazy you shouldn't be accessing outside the stack


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




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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

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

OpenRTOS and SafeRTOS