[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Software JTAGICE using simulavr / limited simulavr IC
Theodore A. Roth
Re: [avr-gcc-list] Software JTAGICE using simulavr / limited simulavr ICE
Fri, 22 Aug 2003 14:57:05 -0700 (PDT)
On Fri, 22 Aug 2003, Mike Hudson wrote:
> Here's something to ponder over the weekend, it came up during the usual
> Friday afternoon clock-watching banter. To the best of my knowledge, it
> hasn't been discussed before:
> Would it be possible to modify simulavr (or create an external
> interface plugin) in order to create a PC hosted version of the JTAGICE
> using the parallel port? You would likely need to extern simulavr to
> emulate parallel I/O lines and a single serial port, as well as add
> support for saving the contents of the flash memory.
I'm not sure I understand the logic in this. Please correct me if I'm
You want to have one computer running the dev tools and another
running simulavr with simulavr acting like a jtagice box with the two
computers communicating via the parallel port?
> Although this approach would run slower (and be less reliable) than the
> hardware JTAGICE, it would have near zero hardware cost. ( Although we
> really should resolve the whole firmware issue with Atmel. My personal
> opinion is that they should just sell a non-commercial firmware license
> for $20)
I don't think the problem has anything to do with the jtagice
firmware, but more to do with the AVR jtag on-chip debug protocol
which is proprietary to Atmel. Having the firmware does us no good
here, since we don't know what the signals to emulate are, or even
what is going on inside the device.
> A side effect of adding this support would likely be the acceleration
> of development on simulavr's external peripheral interface, and the
> ability to use it as a limited ICE.
> This could be enough for many educational environments, and people
> starting out with AVRs. I know that most high-school students would be
> completely satisfied with a few I/O lines and a serial port.
Wouldn't this goal be more easily achieved via running gdb with
simulavr on a single PC? There are many possibilities for displaying
pin state (graphically or even via the parallel port and a led dongle)
and even sending UART data out the real serial ports.