simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Simulavr-devel] Re: AT43USB devices


From: Keith Gudger
Subject: [Simulavr-devel] Re: AT43USB devices
Date: Wed, 8 Oct 2003 07:06:29 -0700 (PDT)

Ted:

I'm making real progress, but I didn't find this patch "attached".  I
would like to try sending interrupts so I can check out the interrupt
table.  I would like to have this patch.  Could you explain "signal
96+12"?  Is this the same as SIG96?  What about "SIGUSR1"?  I guess I'm
confused...

Keith

On Mon, 6 Oct 2003, Theodore A. Roth wrote:

> 
> 
> On Mon, 6 Oct 2003, Keith Gudger wrote:
> 
> > Ted:
> >
> > (I tried to use the list, but the wonderful version of netscape on my Sun
> > machine at Atmel won't let me....)
> 
> That's ok. I've replied to the list also.
> 
> >
> > In trying to get the AT43USB3.. devices running in Simulavr, I found out
> > that the file ports.c only knows about ports a,b,c,d.  These devices have
> > ports e and f.  Are the only fixes for this in ports.c, *name_PIN,
> > *name_DDR and *name_PORT?  If so, I'll make those changes in the next
> > compile.
> 
> Probably better to add those as a second patch once the main USB dev
> support is added. Note that the 103 and 128 among others could take
> advantage of extending the number of possible ports.
> 
> >
> > Also, the USB devices address the USB registers at SRAM addresses between
> > 0x1fa0 and 0x1fff.  Is there a way to make this work in Simulavr?  Or does
> > it mean major changes to your data structures and methods to add a 2nd
> > discontinuous memory?  It would be nice to have, as the wonderful AVR
> > Studios don't support this....
> 
> The current design for VDev's can't handle discontinuous memory. This
> actually came up on the list in the last few weeks. I don't have a
> solution for that yet. I'm busy with other projects right now, so I
> haven't had a chance to dive into it.
> 
> >
> > Also, as a gdb expert... Is there a way to force interrupts in gdb?  I
> > haven't found any.
> 
> Someone else requested this a while back and I came up with a fairly
> simple hack. Basically, since the avr targets don't understand signals
> in the same sense as gdb (gdb uses the unix/posix point of view for
> signals), I used gdb's 'signal' command to send a signal to the
> target. This only requires a few minor changes to on the simulavr side
> and no changes to gdb. To make things easier on the gdb side, the user
> can define user commands in their .gdbinit file which give symbolic
> names to the signal numbers. For example:
> 
> -- begin example .gdbinit --
> define reset
>   signal SIGHUP
> end
> 
> define avr-irq-0
>   signal 96+12
> end
> -- end example --
> 
> Don't take the 12 seriously, I pulled it out of the air. ;-)
> 
> Attached is the patch if anyone cares to test it. Whoever asked for it
> originally never responded back so I let it slide. The patch might
> need some tweaking to work with the current cvs though.
> 
> Ted Roth
> 
> 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]