Re: [Simulavr-devel] I/O map for usart1

[Theodore A. Roth]

On Tue, 25 Nov 2003, Keith Gudger wrote:

> Ted:
>
> My employer has made a mess of mapping the 2nd UART into the I/O space of
> the different devices.

[grin]

> Here is some of the mappings I've found so far:
>
> Part Name    UDR1  Extended I/O?  Vector Address
> ATMega64     0x9c  Yes            0x3E
> ATMega128    0x9c  Yes            0x3E
> ATMega161    0x23  No             0x1e
> ATMega162    0x23  Yes            0x2c
>
> I *was* planning to use the fact that the 128 etc. parts had an extended
> I/O space to map the UART registers in the proper space, then I found the
> 162 has the extended I/O space and the 2nd UART at the bottom of the I/O
> space!
>
> Any suggestions?  I'm currently using the 128 to check out UART1, as I
> would have to add some of the other parts if I want to check their I/O
> addresses.  Adding those parts entails changing the intvects.x stuff, too.

Can you explain why you would need to change the invects? Seems to me
that the vector table should already be abstracting away all the vector
addresses.

Well, I'm hoping to change the way VDev's work. I want to remove the
linked list and use a lookup table. The register address will be the
index into the lookup table and the table will store a reference to the
VDev object. The current mask stuff in devsupp should go away. The VDev
initializer per device would need to be a terminated array of structures
with each structure holding a ptr to the VDev new function and a static
array of addresses to install the VDev at in the lookup table. I've
already started on this, but haven't made a lot of progress yet.  Still
a lot of details to work out.

I don't think that simulavr really needs to make a distinction between
IO space and EXT IO space. It's really just one big IO space with
variable length. Correct me if I'm wrong, but I can't remember seeing
anything but 0x20-0x5f and 0x20-0xff as being the only two IO space
(mem-mapped) ranges.

Ted Roth