The Internet of Things is eating everything alive, and the world wants to know: how do you make a small, battery-powered, WiFi-enabled microcontroller device? This is a surprisingly difficult problem. WiFi is not optimized for low-power operations. It’s power-hungry, and there’s a lot of overhead. That said, there are microcontrollers out there with WiFi capability, but how do they hold up to running off of a battery for days, or weeks? That’s what [TvE] is exploring in a fantastic multi-part series of posts delving into low-power WiFi microcontrollers.
The idea for these experiments is set up in the first post in the series. Basically, the goal is to measure how long the ESP8266 and ESP32 will run on a battery, using various sleep modes. Both the ESP8266 and ESP32 have deep-sleep modes, a ‘sleep’ mode where the state is preserved, a ‘CPU only’ mode that turns the RF off, and various measures for sending and receiving a packet.
The takeaway from these experiments is that a battery-powered ESP8266 can’t be used for more than a week without a seriously beefy battery or a solar panel. Run times are much longer with an open network as compared to a secured network, and that security eats up a ton of power: connecting to a secure network every now and again means your ESP might only run for a day, instead of a week.
There is another option, though: the ESP32. While the ’32 is vastly more powerful and more capable than the ESP8266, it also has a few improved features that help with power consumption. Importantly, there’s a bug in the ESP8266 where it drops into modem sleep instead of light sleep about half the time. This error was fixed in the ESP32, but all that power does come at a cost. On the whole, if you’re concerned about security, the ESP32 is slightly better, simply because it does the ‘security’ part of connecting to a WiFi network faster. This is really a remarkable amount of testing that’s gone into this write-up, so if you’re developing something battery-powered with any ESP, it’s well worth the read.
It used to be that Web browsing was simple. You asked a server for some text, which was duly sent, and then formatted by your browser. Now a web page is as likely to be a full-blown application that is reading mail, editing text, or lots of other things and may use WebSockets to create a back channel to the server. Thanks to affordable hardware like the ESP8266 one of those things a modern web browser can do is sense and control the real world. [Acrobotic] has an interesting video about using WebSockets to allow a browser to talk to an ESP8266 web server in real time. You can see his simple demo in the video below.
Continue reading “WebSockets Embedded With The ESP8266”
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.
[Thanks Tod E. Kurt for the tip]
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.
Continue reading “Getting Started with STM8”
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.
Continue reading “Mbed Labs Chock Full of Arm Goodies”
[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.
Metal pegboard has its uses, even if the more common dead-tree version shows up more often in projects from DIY vacuforming to making a modular work surface for when space is at an absolute premium.
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!
Image of Mount Sopris, namesake of the project, by [Hogs555] (CC-BY 4.0)