Every month, semiconductor manufacturers across the globe retire old devices. A product that has been superseded, isn’t selling well, or maybe whose application has declined, is removed from the catalogue and ceases to be manufactured. Usually these moments pass unnoticed, just one old device among many. Who is going to remark upon the demise of a chip for a VGA card for example, or a long-ago-left-behind Flash memory chip?
One has come to our attention that is pretty unremarkable, but that could concern some of our readers. NXP have stopped manufacturing the LPC810M021FN8. What on earth is an LPC810M021FN8, you ask, the answer being that it appears to have been the last microcontroller with an ARM core available in a DIP package. Even that in itself is hardly earth-shattering, for if you really must use an ARM core rather than any of the myriad 8, 16, or 32 bit microcontrollers still available you can always get a DIP breakout board for a small surface mount chip.
This turn of events comes as a reminder that, while breadboard-friendly and popular among a section of our community, DIP packages are now particularly old-school. Other once-popular devices such as the LPC1114 have also long-since ceased to be available in this format, and we have to wonder how long we will be able to take advantage of DIP packages for some of the other microcontroller families.
A few years ago this news might have come as something of a disaster, but it now has more of a sense of the passing of a bygone era. It’s normal to use microcontroller dev boards in a larger DIP format for prototyping, so maybe getting used to a bit of surface-mount soldering on a break-out board will be only for the truly hard-core when the last DIP package has been retired. Other than that of course, the 555 is still available in a DIP8, and you can make anything with one of them!
If you didn’t have a chance to take the 810 for a test drive, the usual suppliers still list it in stock, Adafruit have a starter pack for it, and it will no doubt be possible to find it in small quantities for years to come.
There are so many different CPUs today and often the hardest thing about using any of them is getting started and gathering the right software tools. If you’ve ever eyed up the very inexpensive STM8 processor, you’ll want to check out [Shane Burrell’s] video (see below) about how to get started with the STM8.
The STM8 isn’t a 32-bit processor — you could probably guess that from the name. [Shane] uses SDCC (small device C compiler) to target the little chip. He also shows how he manages a fairly substantial piece of code and how he controls the build process.
One of the things we like about ARM processors is that there are a variety of options for library support. You can write your own code at the bare metal, of course, but you can also use many different abstraction libraries to make things easier. At the other end of the spectrum, there is Mbed, similar to the sort of libraries that Arduino supplies. Easy to use, although not always the best possible performance. Mbed now has an Mbed Labs site with a lot of extra goodies that go with the Mbed ecosystem, and it has quite a few interesting things.
[JesusGomez] has certainly put work into his Vertical Laboratory concept. There’s a bit more to the idea than simply using 3D printed parts to move electronics from the desktop onto a metal pegboard, although that part is certainly nicely done. There are 3D models for securely mounting various hardware such as Raspberry Pi, Beaglebone, ESP32, cable management, breadboards, and other common parts to a metal pegboard. Instead of having parts and wires splayed across a workbench, it can be mounted and organized vertically. Having a project or prototype mounted on pegboard is easier to store, saves room, and frees up desk space in small work areas. It also makes for an organized and visually pleasing layout.
A clever piece of design is in the plastic mounts that he created. He wanted parts to remain securely mounted unless intentionally removed, allow different mounting orientations, and to never require access to the back side of the pegboard. To accomplish this, the parts use a combination of pegs that slide-lock with bendable sections that act as lock tabs. Once mounted, the parts stay put until the lock tabs are released by gently prying them out of position. Since mounting and removal can be done entirely from the front, wall mounted pegboards with inaccessible backs can be used.
There are many parts to building a secure networked device, and the entire industry is still learning how to do it right. Resources are especially constrained for low-cost microcontroller devices. Would it be easier to build more secure devices if microcontrollers had security hardware built-in? That is the investigation of Project Sopris by Microsoft Research.
The researchers customized the MediaTek MT7687, a chip roughly comparable to the hacker darling ESP32. The most significant addition was a security subsystem. It performs tasks notoriously difficult to do correctly in software, such as random number generation and security key storage. It forms the core of what they called the “hardware-based secure root of trust.”
Doing these tasks in a security-specific module solves many problems. If a key is not stored in memory, a memory dump can’t compromise what isn’t there. Performing encryption/decryption in task-specific hardware makes it more difficult to execute successful side-channel attacks against them. Keeping things small keeps the cost down and also eases verifying correctness of the code.
But the security module can also be viewed from a less-favorable perspective. Its description resembles a scaled-down version of the Trusted Platform Module. As a self-contained module running its own code, it resembles the Intel Management Engine, which is currently under close scrutiny.
Will we welcome Project Sopris as a time-saving toolkit for building secure networked devices? Or will we become suspicious of hidden vulnerabilities? The researchers could open-source their work to ease these concerns, but value of their work will ultimately depend on the fast-moving field of networked device security.
Do you know of other efforts to add hardware-assisted security to microcontrollers? Comment below or let us know via the tip line!
The electronics for motion control systems, routers, and 3D printers are split into two camps. The first is 8-bit microcontrollers, usually AVRs, and are regarded as being slower and incapable of cool acceleration features. The second camp consists of 32-bit microcontrollers, and these are able to drive a lot of steppers very quickly and very smoothly. While 32-bit micros are obviously the future, there are a few very clever people squeezing the last drops out of 8-bit platforms. That’s what the Buildbotics team did with their ATxmega chip — they’re using a clever application of DMA as counters to drive steppers.
The usual way of driving steppers quickly with an ATMega or other 8-bit microcontroller is abusing the hardware timers. It’s quick, but there is a downside. It takes time for these timers to start and stop, and if you’re doing it two hundred times per second with four stepper motors, that clock jitter will ruin your CNC machine. The solution is to use a DMA channel to count down, with each count sending out a pulse to a stepper. It’s a clever abuse of the hardware, and the only drawback is the micro can’t send more than 2¹⁶ pulses per any 5ms period. That’s not really an issue because that would mean some very, very fast acceleration.
The Buildbotics team currently has a Kickstarter running for their four-axis CNC controller using this technique. It’s designed for Taig mills, 6040 routers, K40 lasers, and other various homebrew robots. It’s an interesting solution to the apparent end of the of the age of 8-bit microcontrollers in CNC machines and certainly worth checking out.
In the last episode, I advocated a little bit for Forth on microcontrollers being a still-viable development platform, not just for industry where it’s usually seen these days, but also for hackers. I maybe even tricked you into buying a couple pieces of cheap hardware. This time around, we’re going to get the Forth system set up on that hardware, and run the compulsory “hello world” and LED blinky. But then we’ll also take a dip into one of the features that make Forth very neat on microcontrollers: easy multitasking.
Mecrisp-Stellaris Forth runs on a great number of ARM microcontrollers, but I’ll focus here on the STM32F103 chips that are available for incredibly little money in the form of a generic copy of the Maple Mini, often called a “STM32F103 Minimum System Board” or “Blue Pill” because of the form-factor, and the fact that there used to be red ones for sale. The microcontroller on board can run at 72 MHz, has 20 kB of RAM and either 64 or 128 kB of flash. It has plenty of pins, the digital-only ones are 5 V tolerant, and it has all the usual microcontroller peripherals. It’s not the most power-efficient, and it doesn’t have a floating-point unit or a DAC, but it’s a rugged old design that’s available for much less money than it should be.
Similar wonders of mass production work for the programmer that you’ll need to initially flash the chip. Any of the clones of the ST-Link v2 will work just fine. (Ironically enough, the hardware inside the programmer is almost identical to the target.) Finally, since Forth runs as in interactive shell, you’re going to need a serial connection to the STM32 board. That probably means a USB/serial adapter.
This whole setup isn’t going to cost much more than a fast food meal, and the programmer and USB/serial adapter are things that you’ll want to have in your kit anyway, if you don’t already.
You can power the board directly through the various 3.3 and GND pins scattered around the board, or through the micro USB port or the 5V pins on the target board. The latter two options pass through a 3.3 V regulator before joining up with the 3.3 pins. All of the pins are interconnected, so it’s best if you only use one power supply at a time.