5 ms·

I think they are an easier architecture to learn about microcontrollers than ARM. The atmega328, used in a lot of arduino boards, only has 84 peripheral regist

I think they are an easier architecture to learn about microcontrollers than ARM. The atmega328, used in a lot of arduino boards, only has 84 peripheral registers. At least with avrgcc, a program to blink an LED is less than 10 lines. Every ARM device I've used is far more complex, both in register count, and minimal code examples. The ability to understand all of the hardware of an entire device is much more attainable on an AVR. 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.

bacon_waffle 4y ago
As I've tried to write in another response; my assumption is that most people aren't getting in to embedded to learn about architecture, and they'll start with a development environment like the Arduino IDE that handles that complexity of setting up clocks etc for those examples. 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.
- flyingcircus3 4y ago
  I don't think the arduino software ecosystem is a good path to becoming proficient in embedded development. The very concepts that you need to really understand well, working with registers and understanding the microcontroller as a set of digital circuits, are abstracted away. 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.
  - wink 4y ago
    I'm with bacon_waffle on this - for the majority of people where I witnessed this the entry doesn't really matter, and once you come up to the limitations you'd have to kinda start from scratch for this arch anyway, but the top-down approach goes a long way. 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
  - bacon_waffle 4y ago
    That's a tricky one; there's just such a wide variety of learning styles, goals, prior knowledge, interests... In my formal education, we used a 68k platform to learn assembly and the sorts of things you're talking about. That epistemic style is very different from what I see most makers using, and maintaining excitement about. 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.

bacon_waffle 4y ago

As I've tried to write in another response; my assumption is that most people aren't getting in to embedded to learn about architecture, and they'll start with a development environment like the Arduino IDE that handles that complexity of setting up clocks etc for those examples. 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.

flyingcircus3 4y ago
I don't think the arduino software ecosystem is a good path to becoming proficient in embedded development. The very concepts that you need to really understand well, working with registers and understanding the microcontroller as a set of digital circuits, are abstracted away. 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.
- wink 4y ago
  I'm with bacon_waffle on this - for the majority of people where I witnessed this the entry doesn't really matter, and once you come up to the limitations you'd have to kinda start from scratch for this arch anyway, but the top-down approach goes a long way. 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
- bacon_waffle 4y ago
  That's a tricky one; there's just such a wide variety of learning styles, goals, prior knowledge, interests... In my formal education, we used a 68k platform to learn assembly and the sorts of things you're talking about. That epistemic style is very different from what I see most makers using, and maintaining excitement about. 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.