Replacing or disabling "printf" calls

[rwas]

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 
similar fashion).
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.


Robert W.