They've done it again?
I was already annoyed by peripheral incompatibilities between the Mega's and the tinies.
Yep. Not only different peripherals, but a whole new way of accessing them (now structure-based rather than individual registers.)
On the bright side, I think the new Tinies and Megas are more compatible with each other than they've been in the past.
Well, that was introduced with the XMEGAs, but they carry on. DA is based on xmega2 core, I think ("AVRxt" in the instruction datasheet).
The weirdest syntactical thing about that, I think, is the TCA is written as a union even. So you have to specify TCA0.SINGLE.BLAH or .SPLIT.
every single time. But eh, it's just for a little IO, and toss it in a macro if you find it annoying.
I found the TCD docs highly confusing, and TCA a bit hard to parse but not quite as bad, and TCB factually wrong on a certain aspect (when they say it's "stopped", in applicable states, they really mean it doesn't count when CNT = 0 or CMP or whatever; likewise, you can force a reset by setting CNT = CMP or MAX; the text implies additional internal states, but in fact, as far as I can tell, it's strictly the count compared to other registers, and decision logic so you aren't required to use an event to trigger/stop it). I think everything else is pretty much as it says, as you'd expect? Again, check the errata of course. I didn't discover any device errata (doc errata I would argue so), but confirmed a few, they're not too bad.
Going from MEGA to XMEGA/Dx will be a minor culture shock because of the syntax, yeah; from XMEGA to Dx, almost nothing. PORT, USART, SPI, DAC and probably others will be familiar from XMEGA; ADC is... kind of hybrid I'd say, some XMEGA features (and yes it's 12 real bits, and the internal refs aren't bad), but stripped down a bit (no auto sequenced mux, have to service that from interrupt).
At least, that was the DA I used most recently, perhaps more advanced peripherals (bring back XMEGA ADC? etc.) go on the later series, I haven't checked.
If you're particularly slow at reading peripherals docs*, by all means invest in something much more powerful, and potentially more consistent across the series / families. (I don't know much detail offhand about STM32s, I would guess they do a mix of both [keeping and changing things] too?)
(*Not a knock, just an honest self assessment. I feel like my own reading comprehension has dropped a bit over the years. Not enough to be a problem, but I feel slower I mean. If you're much slower still, or more error prone, indeed it would be a good investment to commit to studying, in as much detail as you can force yourself through, a platform more powerful than you will usually need, so you aren't stuck poring over datasheets of myriad smaller chips, but also bigger chips, on the occasion you would otherwise need to use them. The cost is easily justifiable as long as quantities are small (sub 1000s?). Or, also a possibility in this sort of case, you could have [late onset?] ADHD, and treatment may be available; in any case, whatever works for you.
)
These day's I only use the old atmega's for the projects where they "fit", because I have no interest to buy a new programmer every 5 year because they changed the programming interface again.
FYI, if you have like a AVRISPMKII or newer, PDI is supported, which means XMEGA is available. The Dx use UPDI, but UPDI doesn't even need a programmer as such, you can do it from any old serial port (logic level) with a resistor. I literally use a FTDI TTL-232R-3V3 and adapter cable. Be sure to get the latest version AVRDude to support it. But yeah, notwithstanding the above.
Tim
Home
Help
Search
Login
Register
