RE: [Simulavr-devel] Multiple CPU - Architecture discussion

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> u.org] On Behalf Of Joerg Wunsch
> Sent: Monday, September 08, 2008 1:49 PM
> To: address@hidden
> Subject: Re: [Simulavr-devel] Multiple CPU - Architecture discussion
> 
 
> AVaRICE is a different game: being written as a plain POSIX
> application straight from the beginning, it uses a number of
> POSIX-style OS services, namely fork() (without exec(), could probably
> be replaced by a thread-model abstraction), pipes between the parent
> and child processes, AF_INET sockets for the GDB connection, and the
> select() syscall to multiplex the GDB communication with the ICE
> communication.  The serial and USB communication channels can easily
> be abstracted in the same way as AVRDUDE does, but the entire IO
> stream multiplexing would need a really good redesign in order to
> become OS independent.
> 
> That's why AVaRICE currently can only be used in a Cygwin compilation.

But it really needs to be ported so it can be built using MinGW. This is a 
separate issue that should be discussed on the avarice mailing list.

 
 
> There has always been something like "AVR families" in the past, but
> they haven't been developed as "family devices" back then so nobody
> can tell whether these old devices are really the same.  So for
> example, the ATmega64 and ATmega128 /look/ like two members of a
> family, but they actually aren't up to the deepest level of detail.
> One obvious difference between both that immediately springs to mind
> is that the BREAK instruction only works in the ATmega64 but not in
> the ATmega128 (so the latter cannot support software breakpoints in
> the JTAG ICE).
> 
> For newer AVRs, the families are obvious since all family members
> share the same datasheet.

Unfortunately, there is nothing (that I know of) that is machine-readable that 
would delineate these families.

 
> > >The libc header files are derived from Atmel's XML files.
> 
> Not yet, at least not directly.  But it's the ultimate goal.

IIRC, there are a couple of recent devices where the header file was 
machine-generated from the XML device file. Starting now, all new devices will 
have header files that are machine-generated.
 
> 
> When asking for this, the response we always got is that it's not OK
> to store these files verbatim as part of an opensource project, but it
> is OK to extract whatever information is needed for our purpose, and
> then store that information as part of an opensource project.  The
> avr-libc idea here is (dating back to Ted Roth's days) to convert the
> Atmel XML into an avr-libc internal XML form that is then used as the
> master to generate the header files.  This offers us an additional
> advantage: any information that's /not/ in the Atmel files but which
> we want to have in our headers (like, for example, old names of IO
> registers that have been renamed later, or the old avr-libc SIG_XXX
> style interrupt vector names) can be maintained separately.
> 
> But we aren't there yet (alas).

And I doubt we will ever be. It is easier to go from XML device file -> header 
file. If there is any intermediate data format, then it gets complicated 
quickly concerning maintenance of the data. There is not enough resources at 
this time to go this route, and I doubt that there will be resources in the 
future. But this is a conversation for avr-libc-dev.