Another big draw is all of the daughterboards that use the arduino headers. No other ecosystem besides perhaps the raspberry pi has anything close to the amount of compatible boards.
Another big draw is all of the daughterboards that use the arduino headers. No other ecosystem besides perhaps the raspberry pi has anything close to the amount of compatible boards.
In my experience, most newbies who have yet to pick a micro either want to learn programming, or electronics, or they've got an idea for a thing they want to build which will need a microcontroller; in any of those scenarios I think AVR is probably not the best answer.
So, I feel like recommending a person start with ATMEGA328P because it's a simpler architecture than ATSAMD21, is like saying that people should learn to drive in a 1960s pickup truck because it's simpler.
> Another big draw is all of the daughterboards that use the arduino headers. No other ecosystem besides perhaps the raspberry pi has anything close to the amount of compatible boards.
This isn't really an argument for AVR though, is it? All but one of the dev boards I've worked on in the last few years have either been Arduino or Feather form-factor, none have been AVRs. The one exception is a much chunkier machine.
With that goal in mind, I see simple devices like AVRs as a better first device because there is just less to configure. There's less to debug when things go wrong. There's only one clock domain. The datasheet is far shorter than most ARM devices.
When I look at the example projects for devices I use at work, such as nrf52, or stm32, and then try to put myself in the shoes of someone learning this for the first time, they seem overwhelmingly complex, when compared to similar examples for AVR parts.
I must admit that AVR hardware debugging is miles behind ARM though.
That said, I'm also just a higher-level software person and doing low-level embedded is too tedious for me to do it as a hobby :P
As you say, the debugging story on AVR in particular isn't great, but these tiny systems are famously hard to debug in general. I honestly think that people learning this stuff would usually be better served on a bigger machine where there's at least a console available. Yes, more complex, but at the same time that complexity allows for some separation between the thing being debugged and the debugging environment itself.
Professionally, most of my biggest challenges are around working with people who tend to attack the low level problem, without leveraging the high-level tools and abstractions. They might "fix" the problem quickly, but it creates this horrible maintenance situation where every little thing is subtly different, iteration is incredibly slow, and the system requires a bunch of skill to work on at all. I'd much rather have people who're good at software development and vaguely aware of how the machine works under the hood, than folks who're great at assembly and vaguely aware of how to use Docker.