If you’ve read through the comments on Hackaday, you’ve doubtless felt the fires of one of our classic flame-wars. Any project done with a 32-bit chip could have been done on something smaller and cheaper, if only the developer weren’t so lazy. And any project that’s squeezes the last cycles of performance out of an 8-bit processor could have been done faster and more appropriately with a 32-bit chip.
Of course, the reality for any given project is between these two comic-book extremes. There’s a range of capabilities in both camps. (And of course, there are 16-bit chips…) The 32-bit chips tend to have richer peripherals and run at higher speeds — anything you can do with an 8-bitter can be done with its fancier cousin. Conversely, comparatively few microcontroller applications outgrow even the cheapest 8-bitters out there. So, which to choose, and when?
Eight Bits are Great Bits
The case that [Mike] makes for an 8-bit microcontroller is that it’s masterable because it’s a limited playground. It’s a lot easier to get through the whole toolchain because it’s a lot shorter. In terms of debugging, there’s (often) a lot less that can go wrong, letting you learn the easy debugging lessons first before moving on to the truly devilish. You can understand the hardware peripherals because they’re limited.
And then there’s the datasheets. The datasheet for a chip like the Atmel ATMega168 is not something you’d want to print out, at around 660 pages long. But it’s complete. [Mike] contrasts with the STM32F405 which has a datasheet that’s only 200 pages long, but that’s just going over the functions in principle. To actually get down to the registers, you need to look at the programming manual, which is 1,731 pages long. (And that doesn’t even cover the various support libraries that you might want to use, which add even more to the documentation burden.) The point is, simpler is simpler. And if you’re getting started, simpler is better.
32 Bit Rules!
Don’t get the wrong opinion of his talk — [Mike] is completely appreciative of many of the advanced features of the 32-bit chips. He mentions how the set/reset register on ARM architectures avoids the read-modify-write cycle that you have to go through on an 8-bitter. He mentions a problem he had with an old phone screen that needed a 9-bit SPI signal, ruling out using the hardware SPI on his 8-bit microprocessor. That STM32 chip has configurable hardware SPI that includes a 9-bit option.
There are a lot of problems that you’ll run into with simpler, smaller chips. And for many of these problems, there’s a simpler solution on a fancier chip. But knowing when you’re going to run into these pitfalls is a lesson best learned through experience. You can’t really appreciate how nice it is to have more UARTs than you need until you run out of them. Flexible pin-mapping seems unnecessary until you’ve spent enough time working around difficult layout problems. In short, [Mike] learned to appreciate the bigger chips for what they could do when he needed it.
The (relatively) unified and sophisticated toolchain available for programming ARM chips is a definite plus, once you know how to use it. Adding JTAG and real debugging capabilities into the project makes your life a lot easier. And the ARM core itself, providing a single CPU baseline that all of the chip producers then elaborate with their peripheral choices, reduces vendor lock-in and time spent re-learning if you need to switch. Try moving back and forth between PIC and AVR and you’ll know what he means.
The End of the Holy War?
[Mike] ends the 8-bit vs 32-bit war by saying you need to learn both, because only then will you understand which is the appropriate tool for the job. Sometimes you need a circular saw, and sometimes you need a hand saw. On the surface they both cut, but you can’t really internalize the different applications until you’re familiar with both tools.
And he ends with a cautionary tale, and one that’s painfully familiar. He designed a POV display board for a class demonstration, and outfitted it with a just-right 8-bit microcontroller. Once the PCB was fabricated and populated and he started programming, he realized that he was going to run out of RAM at the desired display resolution. There are all sorts of fixes and kludges and workarounds possible, but if he had started out with a larger chip, at least for the prototypes, he would have had a lot more leeway to experiment. Instead, he’s got a short run of oddly-shaped, copper-clad coasters.
In the end, [Mike] comes up with his simple rule for making the 8-bit versus 32-bit decision. If you’re learning microcontroller applications, and looking to understand the universe, you should grab an 8-bit chip because it’s easier to fully explore its limited possibilities. But if you’re prototyping a (complicated) project, you don’t want to be limited by the choice of chips. You want to free up your mind to focus on the maximum capabilities of the system as a whole. A little bit more money for a 32-bit microcontroller that has simply too many features is well spent. You can always look into trimming it down once you’ve got everything working.