3 ms·

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 understan

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.

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.