Re: Debugging: Am I a dreamer. . . ?

In article <WAQDW9SO4GGIFA4D@xxxxxxxxxxxxxxxxxxxx>, Chris H <chris@xxxxxxxxxxxx> writes:
In message <JYp7F0WlGlHP@xxxxxxxxxxxxxxxxxxxxxxxx>, Simon Clubley
<clubley@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes

Are you objecting to the use of the C function printf() within a embedded
environment for debugging or are you objecting to the use of serial port
output as a debugging tool ?

Printf mainly.


In which case, you are not going to get much argument from me when the
embedded devices that we are talking about are at about the AVR level.

The serial port is used by various debug systems. Monitors and some
RTOS.

In AVR land, I don't use printf as it's bloated (by embedded standards),
Exactly.

but I do have my own interrupt based UART I/O routines that I use for
normal communication with other serial devices as well as debugging.

The routines implement a tty for the hardware UART as well as a Tx-only
software UART for debugging output. As both UART's are interrupt based,
and the output can be optionally buffered in an application specified
buffer, I see very little overhead in using the software UART for
outputting debug information.

Fair enough. I assume this code is shipped in the release?


This is in an hobbyist environment, but yes the UART driver code is included
as part of a finished project.

As for the debug code, it's added and removed as required during debugging,
but I do find it useful to output high level statistical data on the debug
port in some projects, which I can then look at if needed.

In that case, I still need to be able to output the statistical data without
causing the rest of the code, including any I/O on the hardware UART, to
stall, so I still need the current low overhead approach which works just
fine for me.

Where you need to ship release, not debug, code you can't beat an ICE
for full speed non intrusive debugging. They have many features you just
can't do with a serial port.


Once again, no argument here about the extra ICE functionality, but I've
not yet encountered a situation here where I _absolutely needed_ those
extra capabilities, which given that I'm in an hobbyist environment is
probably not a great surprise, especially when the time versus cost
tradeoffs are different in that environment.

Simon.

--
Simon Clubley, clubley@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Microsoft: Bringing you 1980's technology to a 21st century world
.

Relevant Pages

  • Re: How to get Interface reference counting in ATL
    ... component is actually called from an ASP page. ... application in production environment, not step by step. ... Debugging in an production environment is a very bad idea, ...
    (microsoft.public.vc.atl)
  • Re: DesignBAIS/Dave Bryant
    ... a REAL debugging environment for Visage, ... similar to the inbuilt trace/debug facilities we provide in Visage (we ... the Visage client side debugging facility has always offered this ...
    (comp.databases.pick)
  • Re: Help with CreateProcess problem
    ... This is very simple debugging. ... CreateProcess call you are making requires ASCII or wide characters? ... not correctly inherit the environment. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: [Lit.] Buffer overruns
    ... > infobahn wrote: ... I have never argued that we should not use appropriate debugging ... >> drape them all over the production environment. ...
    (sci.crypt)
  • Re: forms Control collections
    ... The release build in the vs dev environment is still debuggable (even if ... debugging, how fast is it then? ... Are you catching and possible exception in the loop? ... Klaus ...
    (microsoft.public.dotnet.languages.vb)