Comment by bacon_waffle | Hacker News Reader

Comment by bacon_waffle | Hacker News Reader

Parent Full thread

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.

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.

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

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.

Reply on news.ycombinator.com