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

[address@hidden]

On Mon Mar 16 13:42 , Joerg Wunsch  sent:

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

I think the best we can hope for is to build CPUs out of hand-made config files.

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

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

Perhaps any new or improved features should be made with an eye to reusability.

Michael Hennebry
address@hidden  note new address
---- Msg sent via CableONE.net MyMail - http://www.cableone.net