Re: [EE] Saving "printf" arguments for later? Real-time on slow processor.

Wrapper seems like a clever option given you probably don't want to or can't make 
changes to the third party library, and hopefully then you can send in guaranteed 
idle time.

Just out of interest, I had a similar problem but different. Slow processor, PIC16 @ 
4MHz, never used printf for all the same reasons, instead used my own serial print 
functions. Characters copied to circular buffer, interrupt driven UART routine sends 
it. Processor is constantly taxed with other interrupts and tasks etc, increasing the 
ability for things to go wrong if they can. Worked fine until serial Tx demands wer 
increased. On investigation what somewhat surprised me was the time it was taking 
just to copy a string of characters into the buffer. Was related to compiler 
packing/un-packing constants in Flash, a uniquely PIC related thing. Fix was to 
persuade the compiler to allocate 1 x byte to temporarily store the character which 
saved a redundant call to unpack it again, sped the whole process up by 30% which 
was enough to overcome the problem. Compiler was optimising for space so I can't 
blame it too much, not enough program flash if asked to compile for speed.

Brent

On 16 Jan 2025 at 16:45, Jason White wrote:

> I've got a situation where I am running a very slow processor that happens
> to have a lot of spare RAM. The CPU sits idle half of the time. It has some
> real time processing that it must do on time every handful of seconds. It
> is just barely fast enough to do its real time work without printfs.
> 
> The device firmware interfaces with a huge complicated third party library.
> This library implements a "debug mode" where it calls printf in various
> places.
> 
> In debug mode it easily generates several kilobytes of formatted number
> containing text per minute. And, what the library does is so complicated
> that we really need the debug output to be generated all of the time (both
> in development and production).
> 
> Unfortunately, It turns out that printf is so slow that it causes the
> system to fail in a variety of subtle yet completely catastrophic ways.
> (due to it missing real time deadlines and not being able to detect that it
> has missed them)
> 
> Has anyone dealt with this before?
> 
> I've reached the conclusion that my best bet is to write a wrapper for
> printf.
> The wrapper would save the printf format string, and variadic arguments to
> a buffer so that I can process the printfs later when the CPU is idle.
> I think I can get away with this since all of the printfs just contain
> numbers and short (~8 byte) strings.
> 
> I'd be interested to hear other people's thoughts and experiences with this
> sort of problem.
> 
> 
> -- 
> Jason White