Re: [avr-gcc-list] Software JTAGICE using simulavr / limited simulavr ICE

[Mike Hudson]

On August 22, 2003 05:57 pm, you wrote:
> 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
> mistaken.
>
> 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?
>

No. Everything would be running on a single PC. The user would execute a 
script which would run the simulated JTAGICE interfaced to a pseudo 
serial port. 

On unix systems, avarice would then interface with a pty instead of the 
actual serial port.

On windows systems, I'm sure there's some sort of software serial port 
driver that would provide some sort of emulation. AVR Studio would 
detect the simulated JTAGICE and use that instead of the actual 
hardware.

The goal is to allow the user to connect their development system 
directly to the AVR's JTAG port using their parallel port - without the 
need for any external hardware or cash expenditure. 

> >     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.
>

By simulating a JTAGICE box in software, we don't _need_ to understand 
the specifics of the protocol. We simply emulate a physical hardware on 
which the atmel firmware runs, using the host CPU, parallel port, and a 
software serial port much in the way that the M16 on my bootice 
emulates the m163 inside the real jtagice. 

> >     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.
>

Yes, it would be simpler to simply do everything in software for actual 
devel. However, physical input and output is far more impressive from a 
educational standpoint. In the context of high school students, if you 
simply sit them down in front of a PC and say 'this simulates part x', 
they'll quickly get bored. If you let them build something, they'll 
stay interested longer.  For engineering students, just add a few shiny 
objects to the mix. :)

-- 
Mike Hudson

pgpNEj9ykh9Db.pgp
Description: signature