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

[Joel Sherrill]

Joerg Wunsch wrote:
> 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:
>
>   
I would like to add two preceding steps

   - ensure it is can replace avrtest for gcc testing

   - release version < 1.0  -- 0.99 or something

The above should be less work and a nice milestone.  We
might be there now.
> . complete missing features of the ATmega128 model (TWI, ADC?),
>   
I need to read the atmega128 manual versus the requirements
for the project I am working on.  Maybe I will be pitching in
on one of these if they need it.
> . 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.
>   
I think this is reasonable.  If someone wants to add an older
model, we shouldn't stop them. :)
> 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.
>
>   


--
Joel Sherrill, Ph.D.             Director of Research & Development
address@hidden        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available             (256) 722-9985