Over at RCgroups, user [Cesco] has shared a very interesting project which uses the ever-popular ESP8266 as both a transmitter and receiver for RC vehicles. Interestingly, this code makes use of the ESP-Now protocol, which allows devices to create a mesh network without the overhead of full-blown WiFi. According to the Espressif documentation, this mode is akin to the low-power 2.4GHz communication used in wireless mice and keyboards, and is designed specifically for persistent, peer-to-peer connectivity.
Switching an ESP8266 between being a transmitter or receiver is as easy as commenting out a line in the source code and reflashing the firmware. One transmitter (referred to as the server in the source code) can command eight receiving ESP8266s simultaneously. [Cesco] specifically uses the example of long-range aircraft flying in formation; only coming out of the mesh network when it’s time to manually land each one.
[Cesco] has done experiments using both land and air vehicles. He shows off a very hefty looking tracked rover, as well as a quickly knocked together quadcopter. He warns the quadcopter flies like “a wet sponge”, but it does indeed fly with the ESP’s handling all the over the air communication.
To be clear, you still need a traditional PPM-compatible RC receiver and transmitter pair to use his code. The ESPs are simply handling the over-the-air communication. They aren’t directly responsible for taking user input or running the speed controls, for example.
This isn’t the first time we’ve seen an ESP8266 take the co-pilot’s seat in a quadcopter, but the maniacal excitement we feel when considering the possibility of having our very own swarm of flying robots gives this particular project an interesting twist.
Sometimes you have to switch a light. Maybe it’s an LED but sometimes it’s mains-powered. That’s not too hard, a transistor and a relay should do it. If you have to switch more lights, that’s not too bad either, as long as your microcontroller has enough free GPIOs. But, if you need to switch a large number of lights, like 256 of them, for example, you’re going to need something else.
[Jan]’s project didn’t switch quite that many lights, but 157 of them is still enough of a chore to need a creative solution so he decided to use a 256-bit shift register to do the legwork. The whole thing is powered by a NodeMCU ESP8266 and was professionally built on DIN rails in a metal enclosure.
The build is interesting, both from a technical point of view and from an artistic one. It looks like it uses more than a mile of wiring, too. The source code is also available on the project page if you happen to have a need for switching a huge number of lightbulbs. Incandescent blulbs aren’t only good for art installations and lamps, though, they can also be used in interesting oscillator circuits too.
The PocketBeagle single-board computer is now a few months old, and growing fast like its biological namesake. An affordable and available offering in the field of embedded Linux computing, many of us picked one up as an impulse buy. For some, the sheer breadth of possibilities can be paralyzing. (“What do I do first?”) Perhaps a development board can serve as a starting point for training this young puppy? Enter the BaconBits cape.
When paired with a PocketBeagle, everything necessary to start learning embedded computing is on hand. It covers the simple basics of buttons for digital input, potentiometer for analog input, LEDs for visible output. Then grow beyond the basics with an accelerometer for I²C communication and 7-segment displays accessible via SPI. Those digging into system internals will appreciate the USB-to-serial bridge that connects to PocketBeagle’s serial console. This low-level communication will be required if any experimentation manages to (accidentally or deliberately) stop PocketBeagle’s standard USB network communication channels.
BaconBits were introduced in conjunction with the E-ALE (embedded apprentice Linux engineer) training program for use in hands-on modules. The inaugural E-ALE session at SCaLE 16X this past weekend had to deal with some last-minute hiccups, but the course material is informative and we’re confident it’ll be refined into a smooth operation in the near future. While paying for the class will receive built hardware and in-person tutorials to use it, all information – from instructor slides to the BaconBits design – is available on Github. Some of us will choose to learn by reading the slides, others will want their own BaconBits for independent experimentation. And of course E-ALE is not the only way to learn more about PocketBeagle. Whichever way people choose to go, the embedded Linux ecosystem will grow, and we like the sound of that!
There’s a sinking feeling when a firmware upgrade to a piece of equipment goes wrong. We’ve all likely had this happen and bricked a device or two. If we are lucky we can simply reapply the upgrade or revert to a previous version, and if we’re unlucky we have to dive into a serial debug port to save the device from the junk pile. But what happens when both those routes fail? If you are [Arko], you reverse-engineer the device and write your own bootloader for it.
The offending bricked object was a Monoprice MP Mini Delta 3D printer to which he was foolhardy enough to apply new firmware after seeing a friend’s machine taking it without issue. Finding the relevant debug interface on its main PCB he applied the firmware upgrade again, only to realise that in doing so he had overwritten its bootloader. The machine seemed doomed, but he wasn’t ready to give up.
What follows in his write-up is a detailed examination of the boot mechanism and memory map of an ARM Cortex M0 processor as found in the Monoprice’s STM32F070CB. We learn about vector tables for mapping important addresses of interrupts and execution points, and the mechanics of a bootloader in setting up the application it launches. This section is well worth a read on its own, even for those with no interest in bricked 3D printers.
In the end he had a working bootloader to which he appended the application firmware, but sadly when he powered up the printer there was still no joy. The problem was traced to the serial connection between the ARM doing the printer’s business and the ESP8266 running its display. After a brainstorm suggestion with a friend, a piece of code was found which would set the relevant registers to allow it to run at the correct speed.
So after a lot of work that resulted in this fascinating write-up, there was a working 3D printer. He suggests that mere mortals try asking Monoprice for a replacement model if it happens to their printers, but we’re extremely glad he persevered. Without it we would never have had this fascinating write-up, and would be the poorer without the learning experience.
This isn’t the first time we’ve brought you 3D printer bootloader trickery.
Rust Programming Langauge has grown by leaps and bounds since it was announced in 2010 by Mozilla. It has since become a very popular language owing to features such as memory safety and its ownership system. And now, news has arrived of an Embedded Devices Working Group for Rust aiming at improving support for microcontrollers.
Rust is quite similar to C++ in terms of syntax, however Rust does not allow for null or dangling pointers which makes for more reliable code in the hands of a newbie. With this new initiative, embedded development across different microcontroller architectures could see a more consistent and standardized experience which will result in code portability out of the box. The proposed improvements include IDE and CLI tools for development and setup code generation. There is also talk of RTOS implementations and protocol stack integration which would take community involvement to a whole new level.
This is something to be really excited about because Rust has the potential to be an alternative to C++ for embedded development as rust code runs with a very minimal runtime. Before Arduino many were afraid of the outcome of a simple piece of code but with rust, it would be possible to write memory-safe code without a significant performance hit. With a little community support, Rust could be a more efficient alternative. We have seen some Rust based efforts on ARM controllers and have covered the basics of Rust programming in the past if you want to get started. Good times ahead for hardware hackers.
Often times, the only way to get exactly what you want in a device is to just build it yourself. Well, maybe not the only way, but we’ve all certainly told ourselves it was the only way enough that it might as well be true. We don’t know if the DIY imperative felt by [Olav Vatne] to construct his own Bluetooth mechanical number pad was genuine or self-imposed, but in either event, we’re glad he documented the process for our viewing pleasure.
Broken up into three separate posts on his blog, the construction of his custom numpad starts innocently enough with buying a kit from AliExpress. In a rather bizarre twist, the kit arrived assembled, which lead to an arduous period of desoldering to separate all the principle parts [Olav] wanted in the first place. So much for saving time.
Once he freed all the mechanical keys from the kit’s PCB, he went to town hand-wiring the matrix. After testing to make sure all the keys were wired correctly, the matrix got connected to an Adafruit Feather 32u4 Bluefruit. With the electronics sorted, [Olav] moved on to the software side. Here he was able to accomplish one of his primary goals, having a numpad that works over both USB and Bluetooth.
The last step of the process was creating the wooden enclosure. It basically goes together like a picture frame, with special care given to make sure there are appropriate openings in the case for the switches and USB port to pop through without ruining the overall look of the device.
Thanks to cheap USB-capable microcontrollers, hand-made artisan keyboards are now a thing. This project is a nice way to get started with custom input devices, and it only gets better from here.
For the last thirty or so years, the demoscene community has been stretching what is possible on computer systems with carefully crafted assembly and weird graphical tricks. What’s more impressive is hand-crafted assembly code pushing the boundaries of what is possible using a microcontroller. Especially small microcontrollers. In what is probably the most impressive demo we’ve seen use this particular chip, [AtomicZombie] is bouncing boing balls on an ATtiny85. It’s an impressive bit of assembly work, and the video is some of the most impressive stuff we’ve ever seen on a microcontroller this small.
First, the hardware. This is just about the simplest circuit you can build with an ATtiny85. There’s an ISP header, a VGA port with a few resistors, a 1/8″ audio jack driven by a transistor, and most importantly, a 40MHz crystal. Yes, this ATtiny is running far faster than the official spec allows, but it works.
The firmware for this build is entirely assembly, but surprisingly not that much assembly. It’s even less if you exclude the hundred or so lines of definitions for the Boing balls.
The resulting code spits out VGA at 204×240 resolution and sixty frames per second. These are eight color sprites, with Alpha, and there’s four-channel sound. This is, as far as we’re aware, the limit of what an ATtiny can do, and an excellent example of what you can do if you buckle down and write some really tight assembly.
Continue reading “Racing The Beam On An ATtiny”