This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

how does retarget.c actually work?

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.

Parents
  • The reason I wanted to know was so I could control what is and is not getting included in my build. Knowing that all printf statements end up calling fputc() makes it all make sense.

    I'm finding more and more with embedded programming you can't not know everything about your code. The .map file is not just a bunch of noise; it tells you when you made an innocent mistake that hauled in libraries you might not need.

    I ended up implementing my own printf (more limited than the standard one) in my own console.c and saved another 2k of RAM by doing so. file attached.

    console.c

Reply
  • The reason I wanted to know was so I could control what is and is not getting included in my build. Knowing that all printf statements end up calling fputc() makes it all make sense.

    I'm finding more and more with embedded programming you can't not know everything about your code. The .map file is not just a bunch of noise; it tells you when you made an innocent mistake that hauled in libraries you might not need.

    I ended up implementing my own printf (more limited than the standard one) in my own console.c and saved another 2k of RAM by doing so. file attached.

    console.c

Children
No Data
Related