Electronics > Microcontrollers

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

(1/34) > >>

incf:
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 (formatted) numbers and short strings.

I'd be interested to hear other people's thoughts and experiences with this sort of problem.

footnote: it is a shame I can't just spit the format string and raw stack values out the serial port to be interpreted by a PC program later. Have to parse the format string.

Edit: CPU is a ARM Cortex-M0+

edit: see last post, after implementing everything, a test printf with 8 arguments takes 600 cpu clock cycles

tggzzz:
If printf is too slow, then don't printf so often nor so much. Don't bother wrapping printf.

Store the information in a RAM buffer fast. Information might be the bytes representing a number (not the human readable version thereof), or for predefined text simply store an integer indexing the text or a pointer to the text, or for an FSM state a pointer to the class implementing the state logic, or for an FSM event, an integer representing the type of the event plus the information in the event arguments.

When time allows, either transmit that information to another processor, or convert that information into a human readable format and then discard the information.

incf:
I don't have any control over the third party library. It uses printf*, and all of it's debugging functionality is either "on", or "off."

*or rather, it calls a function that I supply that is expected to behave like printf

Siwastaja:
Did you see this thread, it mentioned some ideas:

https://www.eevblog.com/forum/microcontrollers/low-footprint-printf-replacement-for-embedded-dev/?all

DavidAlfa:
Write a wrapper to _write that copies the string to a queue and runs the uart in the backgroung in interrupt mode, or in main() but sending only one byte at a time, so it doesn't block the program execution.
Also, try increasing the baudrate, it's likely causing a bottleneck.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod