As [email protected] 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. ;-) _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
