simulavr-devel
[Top][All Lists]
Advanced

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

Re: [Simulavr-devel] [patch #6780] Automatic AVR device generation


From: Joerg Wunsch
Subject: Re: [Simulavr-devel] [patch #6780] Automatic AVR device generation
Date: Mon, 16 Mar 2009 21:42:58 +0100
User-agent: Mutt/1.5.11

As Onno Kortmann wrote:

> > Would you use it as part of a regular build or something you
> > did as a beginning step of writing support for a new CPU model?

> Well, I did it to make functional yet incomplete models of the
> tiny2313 and the tiny15l.  And I thought that having at least some
> of the commonalities factored out in a template would already help a
> bit in making new AVR device classes faster :-)

What I'm really wondering about is: until very recently, almost each
AVR appeared to have subsystems that often differed in subtle details.
That appears to have improved a little with recent ATmega and ATtiny
products, approximately starting with all those AVRs that feature the
new RC oscillator (the one that only has a single 8 MHz clock rate),
and/or the new watchdog (the one that can trigger an interrupt).

However, as simulavrxx is still quite incomplete in that area (not
even the ATmega128 is complete), how would an automatic translation
from the XML file cover that?  What exactly can be auto-generated by
now, beyond the basic (and quite simple) standard IO ports
(PINx/DDRx/PORTx), and the very basic timer stuff?  But even for
timers, things are already going to get really scary.  Let's leave out
the historic AT90Sxxx parts by now, and pick only the ATmega16 and
ATmega128, two parts that have been something like "standard" AVRs for
a number of years now.  Let's pick timer 0 on each of them, as it
belongs to the simpler and less complex peripherals.  It starts with
timer 0 being a possible asynchronous timer on the ATmega128, while
this feature is present on timer 2 in the ATmega16 (and most modern
AVRs as well).  Then, the ATmega128 offers prescaler values for 1/32
and 1/128, while the ATmega16 lacks those.

Now, if you continue that with comparing against an ATmega164P or
ATmega1281 (successors of the ATmega16, and ATmega128, respectively),
you'll suddenly notice an explosion in the feature list: 8 operation
modes instead of 4, two compare match units instead of one, and oh,
the ATmega1281 lacks the prescaler values 32 and 128, too (presumably,
because they moved to timer 2 which is the async timer there).

How much of that could be auto-generated?  How much of the different
ADC MUX options of the various devices (single-ended, differential,
differential with gain, internal bandgap measurement, internal
temperature sensor) could possible be auto-generated?

Please don't get me wrong: I think the idea of automatically
generating device classes really sounds fantastic, but I'm a little
sceptical that there's simply too much of the basics still missing to
make that really become a useful tool *right now*.

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

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




reply via email to

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