how does retarget.c actually work?

[Jim]

I'm trying to get a handle on the various ways I can implement console output on this system.

I have in the past used the retarget.c/.h code from this forum that uses simple_uart.c.

There is also a file called "console.c" that seems to attempt to implement a similar thing.

And finally, there is app_uart.c, which is a bit more fully-featured uart, mainly in that it allocates FIFOs and has a callback on received data.

Questions:

1. The retarget.c/.h approach worked for me before, but I don't understand why, and that bothers me. With it linked into my app, I am able to call printf() to push messages to the serial port. It seems to do this by implementing fputc(), and maybe it's obvious to other people, but I'm surprised that printf() would be fully supported by the implementation of fputc. Can someone explain this?

2. Any reason why I can't rewire retarget.c using app_uart?

3. How much memory is the overhead of printf versus lower-level hackery to push a string to the uart? I'd like to know how much I'm wasting. I assume console.c is there to be more efficient, but how much more efficient is it? Rough idea would be sufficient here.

[Ole Morten]

Implementing a simple fputc is the easiest way to get printf to work with a custom interface. This is a result of the way that printf is implemented, and is hence outside of our control. I'm a little unsure what exactly you feel you need to know about this, but you may have use in taking a look at this.

You most definitely could use app_uart for retargeting, but the only change would be to make fputc call app_uart_put() instead of simple_uart_putc(). It doesn't really make much of a difference.

As for RAM usage of printf(), this will depend heavily on toolchain used. I can't find any numbers for Keil, but for GCC you can refer to this question. You can also consider setting aside a big heap, fill it with a known value and afterwards check how much of it was used to know how much heap your exact printf-use requires.