Re: Disobeying jet engines - why?

On a sunny day (Wed, 30 Jan 2008 08:44:17 -0800) it happened John Larkin
<jjlarkin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
<u891q3tki5vgsepk46cd6esgdkdmnj44jt@xxxxxxx>:

I program embedded stuff in assembly, but I do usually have to "debug"
a new design. I use a nice 11x14" fanfold listing, fully commented,
and a laptop pc with a PE Micro background debug pod. I unplug the
application eprom and plug in a ram adapter, then load the code
through the BDM. That lets me examine/patch memory, set breakpoints,
step code, diddle ports, whatever. I also measure execution times of
interesting routines and add them to the comments in the listing.

Sometimes a big hunk of code, dozens or hundreds of lines, just works
the first time, and sometimes there are silly, dumb mistakes.
Sometimes the hardware doesn't work as expected, like the serial DAC
that has to be clocked one more time than the data*** suggests.

We are also integrating the uP code with as many as six Xilinx fpga's
(which are configured by the code), an Ethernet adapter, sometimes a
user interface, and all sorts of sundry junk. For all of this to work
at powerup is rare, although it does happen now and then.

It does seem like, once the fundamental stuff is up and running, there
comes a point where just observing system behavior is sufficient to
spot bugs and lead you to the right part of the source code to fix it.

I figure we spend way under 10% of a project's time debugging the
hardware and firmware, not enough to motivate more sophisticated
tools. Manuals and test sets/procedures are much bigger problems.


John

100% agreed.
.

Quantcast