Question

I know the basic functional differences between printf and sprintf. But, I would like to know about some timing/delay related differences between them both. Apparently, I want to use it in one my tasks for a custom built RTOS. What do you reckon ? I would like to know more how it would affect the performance of the system. (if any). Usually, I dont use print functions because of the massive delay but, I have to mandatorily use it here.

FYI, output is displayed on the terminal window using RS232.

Thanks.

Was it helpful?

Solution

The primary issue here is that printf() writes to stdout which can (and almost certainly will) block the calling thread. It's not at all uncommon on an embedded system for stdout to be a very slow RS232 port.

For this reason you never do this in a real-time thread as it rapidly becomes high non-real-time.

Writing into a buffer with sprintf() is fairly cheap (providing the buffer has already been allocated). It certainly doesn't block.

You'll probably find that your RTOS provides an asynchronous logging mechanism that can be called from a real-time thread without the risk of blocking. This is will be nothing more than a ring-buffer into which you write your terminal output and a lower priority thread to print it to the terminal.

OTHER TIPS

Well ... All other things (which are unspecified) being equal, I guess sprintf() should be "faster" than printf(), since the former just writes to a in-memory buffer, while the latter writes to some I/O "device". Most devices will incur more delays than just writing to RAM will, which is why printf() is likely to be slower.

Those differences are probably quite minor though, the major issue is that most implementations do dynamic memory allocations which can be very expensive.

I would recommend stripping down your requirements so that you can implement them without using an off-the-shelf sprintf() implementation, or going through the code of the implementations you have to see if/when they do heap allocations.

sprintf() has no hardware dependencies, printf() is subject to your underlying low-level support for stdout. A naive implementation that pushes data to the UART and busy-waits for the transmit register or FIFO to become available would indeed have a "massive delay" as you say - but that would be a foolish implementation in a real-time system.

You would normally push the data to a ring-buffer, pipe or character queue, which is serviced by an interrupt routine. If the buffer is empty when you are about to push data to it, you would force the transmitter to start by buffering all but the first character then writing that directly to the UART. The UART interrupt will then keep the transmitter fed until the buffer is empty. From your application level, you are just writing data to memory, so the delay will be minimal and deterministic.

stdin can be implemented similarly, with the ISR writing and the application asynchronously reading.

By using an RTOS IPC mechanism such as a pipe or queue, or using synchronisation primitives such as semaphores you can implement blocking, baulking and timeout semantics on the data output.

If your UART supports DMA, you can potentially further reduce the interrupt rate and CPU overhead.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top