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 [email protected] note new address ---- Msg sent via CableONE.net MyMail - http://www.cableone.net _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
