I'm writing some C abstraction libraries for my non-Arduino AVR projects. As particular hardware features differ between parts, I've been trying to keep that support as broad as possible so I don't limit my options down the line. Don't want to develop an API that only works for a handful of chips.
I found that Wikipedia has a list of ATtiny parts and their respective architectures, which is nice, but no such luck for the ATmega series. Would also like a more thorough examination that compares specific hardware features and registers on (e.g.) the USART and timer implementations.
At the moment, I'm combing through the datasheets and taking laborious notes. I'm not even entirely sure which parts are common and well-supported, since (IMO) the Atmel website has a horrible product matrix. I figure the architecture would be a good clue there, as if one or two parts are NLA, the entire generation is probably legacy.
You can look at the "architectures" that gcc divides the chips into, but those are probably pretty cpu centric rather than having anything to do with the peripherals.
They seem to be. GCC looks to use them to determine which extra instructions are available -- makes sense for a compiler. I have no idea if the AVR_ARCH flag has any other relevance, e.g., if it's a true generational marker or just an arbitrary instruction set grouping.
There are so many small variations between parts that I would love to see something more definitive. E.g., the USI (serial) stuff changed a bit. USICR, USISR, USIDR are the core registers, while the 24/45/85 added a second buffer (USIBR), and the 261A/461A/861A added USIPP to swap the physical pins between PORTA and PORTB. Then there's USART, which so far seems to be fairly consistent -- with the exception of being called UDR, UCSRA/B/C, etc., on the 2313, and UDR0, UCSR0A/B/C, etc., on the mega line.
I can only imagine how many other surprises there are...
Why not send a request to Atmel support?
They will either tell you to take a long walk on a short pier or may actually surprise you and send some useful information or links.
Keep the email short and to the point which may increase your chances of success, as I'm sure they get thousands of requests a day.
Another approach would be to create a wiki and get some collaborators on board to help out.
I for one think what you are trying to achieve would be very useful and will be willing to help out where I can and when time permits.
You may even be able to convince one (or more) of the mods here to create a sticky for you where members can post differences as and when they find them.
Usart is NOT so consistent. Check out how ubrrh vs ubrrl is handled on mega8 vs mega328, for example.
(and the registers are in different locs as well...)
The "part description files" that come with AVR Studio may help. They are XML files which makes them easy to parse and fairly human readable. They're used to generate the morass of AVR header files. At a minimum they should provide you with a list of which processors have which registers / bits. (I have never look at one myself so I could easily be leading you astray {but not deliberately}.)
Another resource to investigate is the Atmel Migration Notes for ATmega microcontrollers... the "to" current version. This will provide some insight to changes that went into the fab.
The "part description files" that come with AVR Studio may help.
Well, once you figure out what the differences ARE, you can probably figure out which chips have which differences from the .h files included by avr/io.h:
grep -l URSEL * #find chips with shared register address for UBRRH
iom16.h
iom162.h
iom16a.h
iom32.h
iom323.h
iom8.h
iom8515.h
iom8535.h
But I don't know of any document that lists which peripherals ended up with "new" implementations like this.
Thanks for the suggestions guys. It's appreciated.
I didn't know about the XMLs -- I'll have to take a look at those and see if it's easier to compare than the header files. I didn't realize those were auto-generated. Some of them are kinda unique the way they're written, so I assumed they were maintained by hand.
westfw -- I think I see what you're saying about the UBRR differences, although I don't think it'll be a big deal for my project. For writes, I just have to remember to set URSEL. (I don't know why they couldn't just give them their own register locations, but hey whatever.) More of a pain for read ops, but like the datasheet says, you shouldn't have to read them very often. I assume the main case is for R/M/W ops.
Now timers on the other hand... I'm finding all kinds of little differences. Holy cow, anything goes with those things!
To be honest, they are now auto-generated, which means that in the version shipped with Arduino, only SOME of them are auto-generated. This accounts for some of the strange discrepancies between files that should be nearly identical. (for instance, iom168.h (older) defines bits PB0, etc, while iom168p.h (auto-generated) only defines PORTB0)
