On Sunday 17 May 2009, Duane Ellis wrote: > david> Hmm, I noticed that chip/atmel/at91/at91sam7x128.tcl (for example) > david>defines a global AT91C_ID ... which strongly presumes that there's > david> only one at91 family chip, since those IDs vary between chips. > > In general, atmel has a single set of IP that defines a peripherals, and > they re-use it over and over again across all of the AT91 series parts, > sort of like a "we have a uart in our chip library". Other chip > companies do the same thing. All atmel uarts have the same flavor - they > have one uart design - and it has evolved over the years.
Right, but AT91C_ID is a good example of how Atmel changes things between parts. Those IDs are used in two controller-specific ways: defining IRQ lines, and gating clocks (for clocks that can be gated). So when one part may have four UARTs, another may have just two but will add a CAN controller; those IDs will then mean different things. Compare that sam7 part with any of the sam9 parts, for example, or an rm9200. You're correct that those individual controllers haven't tended to vary much. (The AVR32 parts use pretty much the same designs.) That's software-friendly, but not all hardware houses work like that. And in newer designs, Atmel has had to evolve some of their more fundamental things ... running out of pinmux options and module IDs for more complex chips will do that. > david> What I had started to do with some DaVinci stuff is define a > david> dictionary with various chip-specific symbols, then have the > david> utilities use the relevant dictionary. > > Good idea! The real trick is to understand how the family goes together. And accept that what seems constant for now may well change soon, for most vendors. The next chip iteration is likely to differ in more than just the amount of memory or clock speed. That understanding develops over time, and is encapsulated in code that handles more and more of the family. A dictionary does OK for handling "this controller is at a different address" differences, and can help address other types of differences. Mostly I see it as a way to structure things ... there may be better ones. Globals won't work. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
