Thank you for the informitave reply. I understand the debugging process now,
i have used debugging in software development enviroments, just never in
microprocessors, mind you, iv done very little in the microprocessors, iv
always done everything with relays or transistors or what have you. But my
latest project calls for some more brains!
Ill give you a run down of what im doing,
2 sensors (elevation and rotation) feed a variable voltage into the device,
it turns them into a variable. The device listens on the com port for
commands from the computer, it will parse that and convert it into commands.
The device then decides the quickest way to get to the desired location
(clockwise / anti-clockwise) taking into account the fact i dont want the
rotator turing around and around constantly, as the wires would get tangled.
Then it rotates the rotator until the sensor variables match the desired
ones. There will be an lcd screen to readout the current position, for
aiding in manual operation, and mabye someday will have a primitive menu
system for calibration of the sensors and variouos other things.
I always love thingking how things will work, but i hate learning how to do
them! but the more i think about this project the more i want to get it
done. I was going to use a pic chip, but i really didnt like the look of
assembly, and i have used C and C++ quite extencivley in the past, so it
would not need much learning for me to apply that knowledge to embedded
systems design, or so i hope!
Paul, EI5GTB.
On 3/20/08, Graham Davies <Yahoo37849@ecrostech.com> wrote:
>
> --- In AVR-Chat@yahoogroups.com <AVR-Chat%40yahoogroups.com>, "Paul
> Sinclair" <paul@...> wrote:
>
> > I'm really not familiar with the
> > debugging of these chips "on a
> > chip with a debug interface"
>
> Maybe you've used a hosted software development environment, like
> Visual Studio or Elipse. Working on a chip with a JTAG interface is
> very much like this, except that LEDs flash and motors spin. You
> make a change to the code. You punch the "build" button and the new
> code is compiled. You set some breakpoints by right-clicking on a
> line of code. You punch run. There's a pause while the binary file
> is transferred to the target microcontroller, then off we go. When
> the breakpoint is hit, execution stops and you can bring up various
> views of memory, registers, variables, ports, etc. to see what's
> going on. Single step, step into functions, step out of functions
> and run again. I haven't used debugWIRE as much, but it's pretty much
> the same if a bit slower.
>
> On the other hand, without a debugger, when you've re-built the
> program you have to pop up a separate tool to take the binary file
> and transfer it to the target. When that's done, you disconnect from
> the target and reset it. Then things either work or they don't. If
> they don't, you have to figure out why either using pure brain power
> or with the aid of extra bits of code inserted to make the invisible
> visible. For each trial, it's build, load, reset and ponder all over
> again.
>
> Don't get me wrong, a debugger isn't a panacea. There are problems,
> particularly in hard real-time systems, that aren't helped a whole
> lot by a debugger. But, I've done projects with them and projects
> without and by-and-large I much prefer to work with.
>
> Graham.
>
>
>
[Non-text portions of this message have been removed]