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

[Joerg Wunsch]

(I'll restrict my reply just to the list.)

As Knut Schwichtenberg wrote:

> Some issues:

> - In the way avrdude/avrice have windows specifics we need to have
> that too

AVRDUDE has only one thing that is Windows-specific, this is the
handling of the low-level IO.  This is for both, serial IO (bitbang
and RS-232), and direct access to the parallel port through IN/OUT
instructions as Windows doesn't ship a driver that allows for a
properly abstracted parallel port access.  A simulator wouldn't have
any need for that kind of stuff.

The third transport layer is USB, and it's abstracted by libusb.

Anything else in AVRDUDE is OS independent.

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.

> -> Visual C vs. gcc

It's not necessarily Visual C.  MinGW could be used as well.  It's a
GCC compilation environment, but offers access to the native Win32 API
rather than any kind of emulation (as Cygwin does).  I'm not even sure
whether AVRDUDE can really be compiled in Visual C or not.

> >E.g., from a simulation point of view atmegas
> >48, 88, 168 and 328 are a lot alike.

> Here it would be really helpful if Atmel has a family overview.

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.

> >IIRC there is a way to get gcc to read
> >a file and emit all the generated #defines.
> >These could be used directly or fed to another tool.

> Do you mean the "-E" were all includes are extracted?

-E -dM

> >The libc header files are derived from Atmel's XML files.

Not yet, at least not directly.  But it's the ultimate goal.

> >There must have been a first use, i.e. a direct use.
> >What was the rule that allowed it?

> That's the best question for today. Jörg Wunsch always mentions the
> license issue.

> The AVR Studio is free of charge and may be freely copied and
> distributed in its original form.

That's the point.  The original Atmel XML files are only allowed for
redistribution as part of the original AVR Studio installer.  So if
you take it to the letter, you aren't even allowed to have these files
on a non-Win32 machine unless that machine could execute the Win32
installer...  (A plain basic Wine installation crashes when trying to
run it.)

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

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)