Debugging: Am I a dreamer. . . ?

Chris H wrote:
> In message <m1d4o7remo.fsf@gmail.com>, Hao Wang <doitmy@gmail.com> writes
>> Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe <toe@lavabit.com> writes:
>>
>>> I've been programming in C for the best part of a decade now but it's
>>> only within the last year that I've really started doing embedded
>>> systems programming.
>>>
>>> When I did C programming for a personal computer, I commonly debugged
>>> my code simply by putting in printf statements around the place to
>>> check variable values, and also by using the instrument that lets you
>>> check the values of variables at runtime when you're stepping through
>>> the code.
>>>
>>
>> If you really programming in C for years, you know that using printf
>> or debugger to remove bugs, only gives the design more bugs. Embedded
>> solutions stay away bugs by careful design (in both IC/HW/BSP/SW).
> 
> I wasn't going to mention that as it usually causes a bun fight bit 
> since you have...
> 
> You should never debug using printf.
> 
> This is why there are simulators, debuggers and Emulators.  Even for 
> PC's I can recall Borland had a system where you could debug one PC from 
> another. For embedded using printf should have dies out over a decade ago.
> 

What's wrong with debugging using printf?  I don't mean specifically 
"printf", which you should normally avoid in a small embedded system, 
but the general idea of putting out extra information while the program 
runs is a very useful debugging technique.  Simulators, debuggers, and 
emulators are all important for development and debugging, but sometimes 
it is easier to send out signals to show what is happening.  Of course 
such things involve changes to your code, and changes to the run-time 
characteristics of your system - but that's often perfectly acceptable 
during development and debugging.  It is not a good idea to rely on 
printf-style debugging as your *only* method of debugging - but equally 
it is a waste to arbitrarily exclude it from your toolbox.

In message <48184695$0$23852$8404b019@news.wineasy.se>, David Brown 
<david@westcontrol.removethisbit.com> writes
>Chris H wrote:
>> In message <m1d4o7remo.fsf@gmail.com>, Hao Wang <doitmy@gmail.com> writes
>>> Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe <toe@lavabit.com> writes:
>>>
>>>> I've been programming in C for the best part of a decade now but it's
>>>> only within the last year that I've really started doing embedded
>>>> systems programming.
>>>>
>>>> When I did C programming for a personal computer, I commonly debugged
>>>> my code simply by putting in printf statements around the place to
>>>> check variable values, and also by using the instrument that lets you
>>>> check the values of variables at runtime when you're stepping through
>>>> the code.
>>>>
>>>
>>> If you really programming in C for years, you know that using printf
>>> or debugger to remove bugs, only gives the design more bugs. Embedded
>>> solutions stay away bugs by careful design (in both IC/HW/BSP/SW).
>>  I wasn't going to mention that as it usually causes a bun fight bit 
>>since you have...
>>  You should never debug using printf.
>>  This is why there are simulators, debuggers and Emulators.  Even for 
>>PC's I can recall Borland had a system where you could debug one PC 
>>from  another. For embedded using printf should have dies out over a 
>>decade ago.
>>
>
>What's wrong with debugging using printf?  I don't mean specifically 
>"printf", which you should normally avoid in a small embedded system,

Well you have answered the question.

>but the general idea of putting out extra information while the program
> runs is a very useful debugging technique.

Yes but not the same as using printf.

>Simulators, debuggers, and emulators are all important for development 
>and debugging, but sometimes it is easier to send out signals to show 
>what is happening.

I have not found that to be the case but then I usually have a 
simulator, debugger or ICE to hand.

>  Of course such things involve changes to your code, and changes to 
>the run-time characteristics of your system

Which is why I don't like it. That said some debuggers instrument the 
code and some distort the time element.

>- but that's often perfectly acceptable during development and 
>debugging.

I agree. For testing some code it can be useful... This is often for 
things like Unit Test where you wrap the function(s) under test in a 
test harness that can have printf or equivalents.

>It is not a good idea to rely on printf-style debugging as your *only* 
>method of debugging - but equally it is a waste to arbitrarily exclude 
>it from your toolbox.

I think we agree.



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Thanks for the replies.

So can anyone recommend a way of debugging a program on a PIC16F684?
Please use full words instead of using initialisms; for instance I
haven't got a clue what an ICE is or what it stands for.

Do I necessarily have to reserve certain pins on the chip for
debugging? That would be a bad thing because I need all the pins in my
current project.

In message 
<5fff0a48-e51d-4f2f-92e3-616ac1cffa91@d1g2000hsg.googlegroups.com>, 
Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe <toe@lavabit.com> writes
>
>Thanks for the replies.
>
>So can anyone recommend a way of debugging a program on a PIC16F684?
>Please use full words instead of using initialisms; for instance I
>haven't got a clue what an ICE is or what it stands for.

Then you probably should not be doing embedded programming. Trey google 
with "ICE" and "embedded"

In-Circuit-Emulator. This is the main debugging tool for embedded work 
where there is no JTAG or BDM.

See
http://www.lauterbach.com
http://www.isystem.com
http://www.signum.com
http://www.nohau.com
et-al

or even

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=14
06&dDocName=en534451

where Microchip have information on the various ICE (their word) they do 
for their own parts.

>Do I necessarily have to reserve certain pins on the chip for
>debugging? That would be a bad thing because I need all the pins in my
>current project.

Then the only option would be an ICE.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris H wrote:

> In-Circuit-Emulator. This is the main debugging tool for embedded work 
> where there is no JTAG or BDM.

JTAG stands for Jesus, Theresa And God, and of course BDM stands for the 
Blessed Virgin Mary. You need all the help you can get when you're 
debugging.

JS

In article <X0BDLJNJEFGIFAL8@phaedsys.demon.co.uk>, Chris H <chris@phaedsys.org> writes:
> In message <48184695$0$23852$8404b019@news.wineasy.se>, David Brown 
> <david@westcontrol.removethisbit.com> writes
>>
>>What's wrong with debugging using printf?  I don't mean specifically 
>>"printf", which you should normally avoid in a small embedded system,
> 
> Well you have answered the question.
> 
>>but the general idea of putting out extra information while the program
>> runs is a very useful debugging technique.
> 
> Yes but not the same as using printf.
> 

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 ?

In AVR land, I don't use printf as it's bloated (by embedded standards),
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.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980's technology to a 21st century world

In message <fv9nvu$547$1@aioe.org>, sprocket <jas@spam.cop.uk> writes
>Chris H wrote:
>
>> In-Circuit-Emulator. This is the main debugging tool for embedded 
>>work  where there is no JTAG or BDM.
>
>JTAG stands for Jesus, Theresa And God, and of course BDM stands for 
>the Blessed Virgin Mary. You need all the help you can get when you're 
>debugging.
>
>JS

Amen :-)

Btw who is Theresa? The only one I knew had nothing to do with god... 
more the other side :-)
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Apr 29, 10:21 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Tue, 29 Apr 2008 16:45:34 -0700, Tom=E1s =D3 h=C9ilidhe wrote:
> > I've been programming in C for the best part of a decade now but it's
> > only within the last year that I've really started doing embedded
> > systems programming.
>
> > When I did C programming for a personal computer, I commonly debugged my=

> > code simply by putting in printf statements around the place to check
> > variable values, and also by using the instrument that lets you check
> > the values of variables at runtime when you're stepping through the
> > code.
>
> > Anyway, when I was doing my embedded systems project this year for
> > college, I was kind of in the dark when my board's program started to
> > malfunction. If I'd been using a PC, I would have used the debugger to
> > single-step through code to check variables' values. What I eventually
> > did was take the offending code and move it across to a PC, and then I
> > used the PC to debug it.
>
> > Anyway, here's the dream I had in my head, which may or may not be a
> > pipe dream:
> >    You know the PIC16F684 chip that costs less than a dollar, well
> > what if they brought out the debug version of it (that costs maybe 20
> > dollars). The debug version would fit perfectly into the normal chip
> > slot, except that it would have some sort of socket on the top of it for=

> > hooking it to a PC for doing stuff like printf's, and also maybe for
> > running a full debugger that will let you check variables' values?
>
> Many chips have in-circuit debugging features, including that one.  Read
> the fine manual.  Few require the chip-and-socket approach -- that's more
> of an 80's/90's thing.
>
> For some applications you'll find that reserving a pin (or pins) for
> debugging that you can twiddle with in software instead of a printf is
> more valuable than gold.  Given an oscilloscope, not only will it tell
> you _that_ your code executes, but if you're careful it'll tell you when
> and for how long.
>
> --
> Tim Wescott



My general rule is: do not use printf() for debugging if you do not
use it in the normal embedded application (Not all embedded systems
are bare bones, no display systems.) That said I usually do not use
printf() at the point of going to real hardware. by then you should
have unit tested to the point that you KNOW there are no unhandled
failure points. (You have to KNOW this if you are developing any
medical device.)

I have worked on several systems where circuitry for a single output
register controlling a set of LEDs has proven VERY useful. I was
always amazed how much information I could get just watching the LEDs
flashing (sometimes even displaying 2things at once).

Ed

In message <JYp7F0WlGlHP@eisner.encompasserve.org>, Simon Clubley 
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>In article <X0BDLJNJEFGIFAL8@phaedsys.demon.co.uk>, Chris H 
><chris@phaedsys.org> writes:
>> In message <48184695$0$23852$8404b019@news.wineasy.se>, David Brown
>> <david@westcontrol.removethisbit.com> writes
>>>
>>>What's wrong with debugging using printf?  I don't mean specifically
>>>"printf", which you should normally avoid in a small embedded system,
>>
>> Well you have answered the question.
>>
>>>but the general idea of putting out extra information while the program
>>> runs is a very useful debugging technique.
>>
>> Yes but not the same as using printf.
>>
>
>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.

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?

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.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Apr 30, 1:00=A0pm, Chris H <ch...@phaedsys.org> wrote:

> >So can anyone recommend a way of debugging a program on a PIC16F684?
> >Please use full words instead of using initialisms; for instance I
> >haven't got a clue what an ICE is or what it stands for.
>
> Then you probably should not be doing embedded programming. Trey google
> with "ICE" and "embedded"


You really are very unbright. You're saying that if someone doesn't
know about something then they shouldn't try to learn about it. Quite
the scholar there.

Thanks for the links.