Whenever we write up a feature on a microcontroller or microcontroller project here on Hackaday, we inevitably get two diametrically opposed opinions in the comments. If the article featured an 8-bit microcontroller, an army of ARMies post that they would do it better, faster, stronger, and using less power on a 32-bit platform. They’re usually right. On the other hand, if the article involved a 32-bit processor or a single-board computer, the 8-bitters come out of the woodwork telling you that they could get the job done with an overclocked ATtiny85 running cycle-counted assembly. And some of you probably can. (We love you all!)
When beginners walk into this briar-patch by asking where to get started, it can be a little bewildering. The Arduino recommendation is pretty easy to make, because there’s a tremendous amount of newbie-friendly material available. And Arduino doesn’t necessarily mean AVR, but when it does, that’s not a bad choice due to the relatively flexible current sourcing and sinking of the part. You’re not going to lose your job by recommending Arduino, and it’s pretty hard to get the smoke out of one.
But these days when someone new to microcontrollers asks what path they should take, I’ve started to answer back with a question: how interested are you in learning about microcontrollers themselves versus learning about making projects that happen to use them? It’s like “blue pill or red pill”: the answer to this question sets a path, and I wouldn’t recommend the same thing to people who answered differently.
For people who just want to get stuff done, a library of easy-to-use firmware and a bunch of examples to
crib learn from are paramount. My guess is that people who answer “get stuff done” are the 90%. And for these folks, I wouldn’t hesitate at all to recommend an Arduino variant — because the community support is excellent, and someone has written an add-on library for nearly every gizmo you’d want to attach. This is well-trodden ground, and it’s very often plug-and-play.
But the other 10% are in a tough position. If you really want to understand what’s going on with the chip, how the hardware works or at least what it does, and get beyond simply using other people’s libraries, I would claim that the Arduino environment is a speed bump. Or as an old friend of mine — an embedded assembly programmer — would say, “writing in Arduino is like knitting with boxing gloves on.”
His point being that he knows what the chip can do, and just wants to make it do its thing without any unnecessary layers of abstraction getting in the way. After all, the engineers who design these microcontrollers, and the firms that sell them, live and die from building in the hardware functionality that the end-user (engineer) wants, so it’s all there waiting for you. Want to turn the USART peripheral on? You don’t need to instantiate an object of the right class and read up on an API, you just flip the right bits. And they’re specified in the datasheet chapter that you’re going to have to read anyway to make sure you’re not missing anything important.
For the “get it done” crowd, I’m totally happy recommending a simple-to-use environment that hides a lot of the details about how the chip works. That’s what abstractions are for, after all — getting productive without having to understand the internals. All that abstraction is probably going to come with a performance cost, but that’s what more powerful chips are for anyway. For these folks, an easy-to-use environment and a powerful chip is a great fit.
But my advice to the relative newbie who actually wants to learn the chip is the exact opposite. Pick an environment that maximally exposes the way the chip works, and pick a chip that’s not so complicated that it completely overwhelms you. It’s the exact opposite case: I’d recommend a “difficult” but powerful environment and a simple chip.
If you want to become a race-car driver, you don’t start you out on a Formula 1 car because that’s like learning to pilot a rocket ship. But you do need to understand how a car handles and performs, so you wouldn’t start out in an automatic luxury sedan either. You’d be driving comfortably much sooner, but you lose a lot of empathy for the drivetrain and intuition about traction control. Rather, I’d start you out on something perhaps underpowered, but with good feel for the road and a manual transmission. And that, my friends, is straight C on an 8-bitter.
I hear the cries of the ARM fanboys and fangirls already! “8-bit chips are yesterday, and you’re just wasting your time on old silicon.” “The programming APIs for the 8-bit chips are outdated and awkward.” “They don’t even have DMA or my other favorite peripherals.” All true! And that’s the point. It’s what the 8-bitters don’t have that makes them ideal learning platforms.
How many of you out there have actually looked at the code that runs when you type
systinit() or whatever? Even if you have, can you remember everything it does? I’m not saying it’s impossible, but it’s a lot to throw at a beginner just to get the chip up and running. Complex chips are complex, and confronting a beginner with tons of startup code can overwhelm. But glossing over the startup code will frustrate the dig-into-the-IC types.
Or take simple GPIO pin usage. Configuring the GPIO pin direction on an 8-bitter by flipping bits is going to be new to a person just starting out, but learning the way the hardware works under the hood is an important step. I wouldn’t substitute that experience for a more abstract command — partly because it will help you configure many other, less user-friendly, chips in the future. But think about configuring a GPIO pin on an ARM chip with decent peripherals. How many bits do you have to set to fully specify the GPIO? What speed do you want the edges to transition at? With pullup or pulldown? Strong or weak? Did you remember to turn on the GPIO port’s clock?
Don’t get me started on the ARM chips’ timers. They’re plentiful and awesome, but you’d never say that they’re easy to configure.
The advantage of learning to code an AVR or PIC in C is that the chip is “simple” and the abstraction layers are thin. You’re expected to read and write directly to the chip, but at least you’ll know what you’re doing when you do it. The system is small enough that you can keep it all in your mind at once, and coding in C is not streamlined to the point that it won’t teach you something.
And the libraries are there for you too — there’s probably as much library code out there for the AVR in C as there is in Arduino. (This is tautologically true if you count the Arduino libraries themselves, many of which are written in C or C-flavored C++.) Learning how to work with other people’s libraries certainly isn’t as easy as it is in Arduino, where you just pull down a menu. But it’s a transferable skill that’s worth learning, IMO, if you’re the type who wants to get to really know the chips.
…But Get Big
So start off with the 8-bit chip of your choice — they’re cheap enough that you can buy a stick of 25 for only a tiny bit more than the price of a single Arduino. Or if you’d like to target the 8-bit AVR platform, there’s a ton of cheap bare-bones boards from overseas that will save you the soldering, and only double the (minimal) cost. Build 25 projects with the same chip until you know something about its limits. You don’t have to achieve lft levels, or even memorize the ghastly “mnemonic” macro names for every bit in every register, but at least get to know how a timer/counter is good for. Along the way, you’ll develop a library of code that you use.
Then move on. Because it is true that the 8-bitters are limited. Along the way, you’ll have picked up some odd habits — I still instinctively cringe at 32-bit floating point multiplications even on a chip with a 32-bit FPU — so you don’t want to stagnate in the 8-bit world too long.
Maybe try an RTOS, maybe play around with all the tools you’ve been missing on the smaller chips. Luxuriate in the extra bit depth and speed! Use the higher-level, black-boxy libraries if you feel like it, because you’ll know enough about the common ways that all these chips work inside to read through the libraries if you want to. If you started out the other way, it would all be gibberish — there’s not a
digitalWrite() in sight!
After a few projects with the big chips, you’ll have a good feel for where the real boundaries between the 8- and 32-bit chips lie. And despite what our comments would have you believe, that’s not something that anyone can tell you, because it depends as much on you as on the project at hand. Most of us are both blue-pill and red-pill microcontroller users from time to time, and everyone has different thresholds for what projects need what microcontroller. But once you’ve gained even a bit of mastery over the tools, you’ll know how to choose for yourself.