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

[Joel Sherrill]

Joerg Wunsch wrote:
> 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).
>
>   
The details of how the models vary is outside my expertise.
I can only offer project guidance below.
> 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?
>
>   
Is is possible to define a set of C++ classes such that
each device "class" has a set.  Say a set of timer classes
or ADC classes?  Whether they are implemented immediately
or not, we could define the class interfaces and inheritance
structure.  

Speaking from experience from RTEMS, very few people
can add major infrastructure and framework.  But many
are capable of filling in the pieces.  If we have the right
class structure automatically generated, then we are
making it our roadmap more obvious.  We are all but
saying: "We need N timer classes to simulate the
supported set of AVR CPU models.  Here are the
class names and how they map to each model."

The AVR simulator world is unique in my experience
because Atmel is involved.  You guys have the insight
to make the structure happen.  Most other simulator
projects have to suffer through public documents
without vendor support and any commonality identified
is just plain luck.
> 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*.
>
>   
I agree that there is no way we can exercise this
functionality now. 

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