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: Tue, 17 Mar 2009 09:32:21 +0100
User-agent: Mutt/1.5.11

As address@hidden wrote:

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

> I suspect that we might need a class or something per mode.
> We would build timers out of modes.

That does not make much sense to me, because the hardware is organized
differently.  The new modes are sitting on top of new hardware
registers (like a second OCRxB register).

In my opinion, the simulator would best match the way the hardware is
designed.  Hardware design doesn't work using OO methods: there's no
(OO-like) inheritance, which new stuff is built on top off.  Instead,
there's true copy&paste, with possibly new stuff added.  Note that
this implies existing functionality could be altered after the
copy&paste step.

This might not sound appealing to someone who's grown up with OO
programming techniques, but it's the reality of how hardware design
works.  Trying to force the diversity resulting out of that into a
strict OO inheritance model will break in unforseen ways.


As Weddington, Eric wrote:

> What I have discovered in working on avr-libc and the toolchain for
> years, is that it is foolish to try to construct any type of
> hierarchical structure out of the various device features. Various
> people keep trying to do this until they realize the sad fact that
> there is no overarching organization to it. There are localities of
> organization: this sub-family here has this set of features, and
> certain sub-families may be related in certain ways.

I think the hardware did improve in that respect quite a bit over
time.  For sure, a simulator could reuse the very same model for all
those devices that appear within a single datasheet (and thus form a
single family now).  The differences between individual devices within
one family are small enough to cope with them.  E.g. in the family of
ATmega48/88/168, the only user-visible difference I immediately
remember of is that the self-programming model of the smallest
ATmega48 is different than that of the larger ones: the ATmega48 does
not feature an explicit bootloader section, it's only got a SELFPRGEN
fuse that allows or forbids the SPM instruction.

It's my very personal impression that with all recent AVRs, the code
reuse in the hardware design is much cleaner that it used to be with
the AT90 and early ATmega series.  So if you pick a random 16-bit
timer in the ATmega1280, and compare it to the only 16-bit timer of an
ATtiny24, they almost completely match except the timer in the
ATmega1280 features an additional OCRxC register.

So I now wonder whether it wouldn't make most sense to draw a roadmap
like:

. complete missing features of the ATmega128 model (TWI, ADC?),

. release version 1.0,

. copy&paste existing hardware models as the base for new models (AVR
  hardware of vintage 2005 onwards), extend these to match with the
  newly added things,

. start creating device models solely for recent AVRs based on that,
  and completely ignore legacy devices like the AT90, and early ATmega
  and ATtiny devices.

This implies a number of now still quite popular devices will never be
supported, like an ATmega8 or ATmega16.  But by the time we could
possibly be ready with the above, these will likely be as obsolete
already as the AT90 series already is today, but by that time, we
could at least provide a good coverage for those AVRs which will be
well established in the market then.

I don't see enough man power available for even thinking about ATxmega
support though.

-- 
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]