> -----Original Message----- > From: > [email protected] > [mailto:simulavr-devel-bounces+eweddington=cso.atmel....@nongn > u.org] On Behalf Of Knut Schwichtenberg > Sent: Monday, March 16, 2009 3:18 PM > To: Joel Sherrill > Cc: [email protected] > 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 _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
