C printf to custom hardware

Question

I have existing code with various debug messages. Our embedded system does not have an external connection for a terminal. I want to modify the printf so that its output goes to a memory location, rather than STDOUT, which is mapped to a FIFO. I guess I need to find write my own outbyte/outnum. Just cant seem to find the GNU code where I can grab things.

I am running a microblaze processor inside an Xilinx FPGA. All print statements are for debugging. We are running GNU tools (Xilinx SDK). For development, was able stick an UART in the design and wire the uart to a few test points.

As we get ready to deploy, I will no longer have this visibility. We do have a USB-to-Serial connecton, but it looks like a fifo, not a serial port to the embedded system. We have a protocol for sending messages over this link. I was thinking of adding a debug message to our protocol. I would like to redirect my print statement to a buffer, and then process this buffer.

I was trying to take the existing printf (xil_printf) and create my own cc_printf, by rewriting the outbyte code, but just not able to dig down in the code far enough to see how to do it. (Frankly, I am VHDL/hardware guy).

Overall code size is tens of thousands of lines of C code. My section is maybe 3-4 thousand lines of code. The basic operation is for software/hardware updates of the system to come in via the USB port and moved to FLASH memory. My code parses incoming packets coming over the USB-to-serial link. Basically there is a bit set that tells me that there is a packet ready in a receive buffer. I process the packet and write to FLASH. As part of the protocol, there are ACK/NACKs/ABorts. I currently use the printf to printout statuses to my lab bench version of the system.

As stated, I would like to embed these printouts into our protocol. I am not married to printf, and would use some other print-function. I would like to print out messages and data. If something else would be a better starting point, I am fine with that. It seems that the biggest issue for me is grabbing the output of the print and directing it where to go.

Answer 1

Don't use printf directly, for debugging purposes.

Use a macro, perhaps something like

#define DEBUGPRINTF(Fmt,...) do \
   {printf("%s:%d: " Fmt "\n", __FILE__, __LINE__,  __VA_ARGS__);} while(0)

Then, once you have converted all your debug printf (and only these) to DEBUGPRINTF you just need to change the definition of that macro (e.g. on the embedded system, perhaps using snprintf ...).

So in the rest of your code, replace a printf("debugging x=%d\n", x); with DEBUGPRINTF("debugging x=%d", x); but do that only for debugging prints. BTWK 4KLOC (for your part) is really tiny, and even 200KLOC (for the whole thing) is small enough to make that replacement doable "by hand" (e.g. Emacs "find & replace interactively").

^{(I am guessing that you are first developing a small piece of code -a few thousand lines- on your laptop, and later porting it to the embedded system)}

Once you have converted all your debug printf to DEBUGPRINTF (and only the debugging prints!) you can redefine that macro, perhaps inspired by

#define DEBUGPRINTF(Fmt,...) do \
  {snprintf(debugbuffer, sizeof(debugbuffer), Fmt, __VA_ARGS__); } while(0)

^{(I guess that you'll need to add something more in that macro -probably before the closing brace- to actually send the debug output -that is the content of debugbuffer- somewhere, but how to do that is implementation & system specific)}

But more likely you'll disable the debug printf with

#define DEBUGPRINTF(Fmt,...) do{}while(0)

BTW, the embedded target system might not even have any snprintf ...

If you want to study some readable C standard library implementation (on Linux) consider looking inside musl-libc source code. You'll need to understand what system calls are.

Actually, you should in fact write and debug your code on your laptop (e.g. running Linux) and only put on the embedded system something which you believe has no bugs. In practice, avoid deploying code with debug printfs (or think in advance of something much better). See also this.

It seems that the biggest issue for me is grabbing the output of the print and directing it where to go.

Probably use snprintf then "send" the debugbuffer to the appropriate place using appropriate primitives. With snprintf you know the size of the message (e.g. with the return value from snprintf and/or using %n in the format control string). Or have your own logging or debugging variadic function (using <stdarg.h> and va_start etc ....)

Do not confuse debugging messages with logging messages. If you want logging, design it carefully. But debugging messages should probably be removed at deployment time.

Answer 2

The Posix function fmemopen allows you to open a memory buffer like a file and returns a FILE * that can be used with the standard IO functions, like fprintf. As far as printing to a device that's not a serial port, I don't know what OS (of any) you are running on, but if present you could write a stream device driver for that custom device and set your stdout and stderr (and maybe stdin) to that. If you're running without an OS then somewhere someone has created a FILE structure that in interfacing with the serial port somehow, and printf is using that.