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

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> u.org] On Behalf Of Knut Schwichtenberg
> Sent: Monday, March 16, 2009 3:18 PM
> To: Joel Sherrill
> Cc: address@hidden
> Subject: Re: [Simulavr-devel] [patch #6780] Automatic AVR 
> device generation
> 
> >>   
> > 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.

> Here is the monkey work ;-) Atmel does currently not provide a list of
> IO-subsystem with identical names but different features. The 
> first real boaring
> thing is to go through each CPU datasheet and find classes 
> with identical
> IO-subsystem per IO-subsystem :-(. Okay, that workload might 
> shrink a little for
> CPUs covered by the same datasheet But there are lots of 
> AVR-CPUs and the number
> is increasing continuously.

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. But there is 
no global organization to it. This is why on avr-libc the policy is now a 
single header file per device, and we are generating that from the public XML 
device data. I don't care if data is duplicated; it doesn't matter as disk 
space is cheap in comparison. What matters is how quickly we can support the 
device, and maintainability. We don't wring our hands anymore trying to make 
sense of it all, because it just doesn't make sense. And I'm not about to try 
to fit the data to some arbitrary model just because it's unseemly if it 
doesn't fit. Better to just acknowledge reality and move on.

I see that it is tempting on this project to try to fit the data into a 
hierarchical model. It's natural to try and do this because this project is 
written in C++ which lends itself to those types of models, what with 
inheritance. Time would be better spent in figuring out how to generate the 
code to support on a device from the public XML data. Yes, this will take 
several iterations as we go through several devices and we come across new 
patterns to account for. Yes, it's tedious work. But it's also a challenge in 
its own right. And if it gets done, it will make supporting new devices very 
easy. This is good because in my experience, there seems to be anywhere from 
5-15 new devices (variants) to support *every calendar quarter*. This is a 
significant load.

Eric Weddington