Replacing or disabling "printf" calls
rbtwas at gmail.com
Tue Oct 18 22:48:04 UTC 2011
Rafael Morales wrote:
> Hello everyone,
> Can any one help us to replace or disable that "printf" calls?
IMO you have a much bigger problem than memory space constraints. I
don't think you
wanna fly any rt code with "printf"s *anywhere* in code that is'nt
intended to be used
in normal operation.
Not meaning to state the obvious, "printf"'s are evil.
That last thing any rt code needs is to have a "printf" execute in a
time critical piece of
code. I got reminded of this in my last project when the other
engineering groups informed me
that my code (central control code of the system, how embarrassing) was
slow on its heartbeat
flag causing the system to shutdown. A carelessly place "printf" in a
diagnostic was the culprit.
"sprintf"s are'nt quite as bad a regular "printf" but in any rt loop,
they are to be avoided IMO.
What I have seen done in other code, was that the diagnostic reporting
was implemented in a
unprivileged diagnostic function (general file operations were done in a
The diagnostic message was conveyed to the diagnostic routing using a
"msg" function (ie.,
posix: "msgsnd" with the "IPC_NOWAIT" attribute set) which in theory
will have, minimal impact
on the high performance loop.
You say there are no "printf"s in the main program, are you sure they
will *never* be called?
I'd strongly recommend getting your driver source and going through it,
or something more radical
like a rewrite.
Even if you managed to replace them with stubs, seeing that "printfs"
exist for diagnostics, I'd have
to wonder about what other forms of diagnostic behavior may be tripped
(unintended for normal operation).
"printf"s for development diagnostics should be "if-def"d out and not
appear in your binary at all IMO.
More information about the users