Everyone loves NeoPixels. Individually addressable RGB LEDs at a low price. Just attach an Arduino, load the demo code, and enjoy your blinking lights.
But it turns out that demo code isn’t very efficient. [Ben Heck] practically did a spit take when he discovered that the ESP32 sample code for NeoPixels used a uint32 to store each bit of data. This meant 96 bytes of RAM were required for each LED. With 4k of RAM, you can control 42 LEDs. That’s the same amount of RAM that the Apollo Guidance Computer needed to get to the moon!
His adventure is based on the thought that you should be able to generate these signals with hardware SPI. First, he takes a look at Adafruit’s DMA-Driven NeoPixel example. While this is far more efficient than the ESP32 demo code, it still requires 3 SPI bits per bit of NeoPixel data. [Ben] eventually provides us with an efficient solution for SPI contro using a couple of 7400 series chips:
[Ben]’s solution uses some external hardware to reduce software requirements. The 74HC123 dual multi-vibrator is used to generate the two pulse lengths needed for the NeoPixels. The timing for each multi-vibrator is set by an external resistor and capacitor, which are chosen to meet the NeoPixel timing specifications.
The 74HC123s are clocked by the SPI clock signal, and the SPI data is fed into an AND gate with the long pulse. (In NeoPixel terms, a long pulse is a logical 1.) When the SPI data is 1, the long pulse is passed through to the NeoPixels. Otherwise, only the short pulse is passed through.
This solution only requires a 74HC123, an AND gate, and an OR gate. The total cost is well under a dollar. Anyone looking to drive NeoPixels with a resource-constrained microcontroller might want to give this design a try. It also serves as a reminder that some problems are better solved in hardware instead of software.
Continue reading “Inefficient NeoPixel Control Solved with Hardware Hackery”
Interfacing with the outside world is a fairly common microcontroller task. Outside of certain use cases microcontrollers are arguably primarily useful because of how easily they can interface with other devices. If we just wanted to read and write some data we wouldn’t have gotten that Arduino! But some tasks are more common than others; for instance we’re used to being on the master side of the interface equation, not the slave side. (That’s the job for the TI engineer who designed the temperature sensor, right?) As [Pat] discovered when mocking out a missing SPI GPIO extender, sometimes playing the other role can contain unexpected difficulties.
The simple case for a SPI slave is exactly that: simple. SPI can be wonderful in its apparent simplicity. Unlike I2C there are no weird addressing schemes, read/write bits, stop and start clock conditions. You toggle a clock line and a bit of data comes out, as long as you have the right polarity schemes of course. As a slave device the basic algorithm is of commensurate complexity. Setup an interrupt on the clock pin, wait for your chip select to be asserted, and on each clock edge shift out the next bit of the current word. Check out [Pat]’s eminently readable code to see how simple it can be.
But that last little bit is where the complexity lies. When you’re the master it’s like being the apex predator, the king of the jungle, the head program manager. You dictate the tempo and everyone on the bus dances to the beat of your clock edge. Sure the datasheet for that SRAM says it can’t run faster than 8 MHz but do you really believe it? Not until you try driving that clock a little quicker to see if there’s not a speedier transfer to be had! When you’re the slave you have to have a bit ready every clock edge. Period. Missing even a single bit due to, say, an errant print statement will trash the rest of transaction in ways which are hard to detect and recover from. And your slave code needs to be able to detect those problems in order to reset for the next transaction. Getting stuck waiting to send the 8th bit of a transaction that has ended won’t do.
Check out [Pat]’s very friendly post for a nice refresher on SPI and their discoveries working through the problems of building a SPI slave. There are some helpful tips about how to keep things responsive in a device performing other tasks.
A Raspberry Pi Zero (W) and Arduino are very different animals, the prior has processing power and connectivity while the latter has some analog to digital converters (ADCs) and nearly real-time reactions. You can connect them to one another with a USB cable and for many projects that will happily wed the two. Beyond that, we can interface this odd couple entirely through serial, SPI, I2C, and logic-level signaling. How? Through a device by [cburgess] that is being called an Arduino shield that supports a Pi0 (W). Maybe it is a cape which interfaces with Arduino. The distinction may be moot since each board has a familiar footprint and both of them are found here.
Depending on how they are set up and programmed, one can take control over the other, or they could happily do their own thing and just exchange a little information. This board is like a marriage counselor between a Raspberry Pi and an Arduino. It provides the level-shifting so they don’t blow each other up and libraries so they can speak nicely to one another. If you want to dig a bit deeper into this one, design files and code examples are on available.
Perhaps we’ll report on this board at the heart of a pinball machine retrofit, a vintage vending machine restoration, or maybe a working prop replica from the retro bar in Back to the Future II.
Communicating with microcontrollers and other embedded systems requires a communications standard. SPI is a great one, and is commonly used, but it’s not the only one available. There’s also I2C which has some advantages and disadvantages compared to SPI. The problem with both standards, however, is that modern computers don’t come with either built-in. To solve that problem and allow easier access to debugging in SPI, [James Bowman] built the SPIDriver a few months ago, and is now back by popular demand with a similar device for I2C, the I2CDriver.
Much like the SPIDriver, the I2C driver is a debugging tool that can be used at your computer with a USB interface. Working with I2C is often a hassle, with many things going on all at once that need to sync up just right in order to work at all, and this device allows the user to set up I2C devices in a fraction of the time. To start, it has a screen built in that shows information about the current device, like the signal lines and a graphical decoding of the current traffic. It also shows an address space map, and has programmable pullup resistors built in, and can send data about the I2C traffic back to its host PC for analysis.
The I2CDriver is also completely open source, from the hardware to the software, meaning you could build one from scratch if you have the will and the parts, or make changes to the code on your own to suit your specific needs. If you’re stuck using SPI still, though, you can still find the original SPIDriver tool to help you with your debugging needs with that protocol as well.
More and more companies are offering ways for customers to personalize their products, realizing that the increase in production cost will be more than made up for by the additional sales you’ll net by offering a bespoke product. It’s great for us as consumers, but unfortunately we’ve still got a ways to go before this attitude permeates all corners of the industry.
[Keegan Ryan] recently purchased a TV and wanted to replace its stock boot screen logo with something of his own concoction, but sadly the set offered no official way to make this happen. So naturally he decided to crack the thing open and do it the hard way The resulting write-up is a fascinating step by step account of the trials and tribulations that ultimately got him his coveted custom boot screen, and just might be enough to get you to take a screw driver to your own flat panel at home.
The TV [Keegan] brought was from a brand called SCEPTRE, but as a security researcher for NCC Group he thought it would be a fun spin to change the boot splash to say SPECTRE in honor of the infamous x86 microarchitecture attack. Practically speaking it meant just changing around two letters, but [Keegan] would still need to figure out where the image is stored, how it’s stored, and write a modified version to the TV without letting the magic smoke escape. Luckily the TV wasn’t a “smart” model, so he figured there wouldn’t be much in the way of security to keep him from poking around.
He starts by taking the TV apart and studying the main PCB. After identifying the principle components, he deduces where the device’s firmware must be stored: an 8 MB SPI flash chip from Macronix. He connects a logic analyzer up to the chip, and sure enough sees that the first few kilobytes are being read on startup. Confident in his assessment, he uses his hot air rework station to lift the chip off the board so that he can dive into its contents.
With the help of the trusty Bus Pirate, [Keegan] is able to pull the chip’s contents and verify its integrity by reading a few human-readable strings from it. Using the
binwalk tool he’s able to identify a JPEG image within the firmware file, and by feeding its offset to
dd, pull it out so he can view it. As hoped, it’s the full screen SCEPTRE logo. A few minutes in GIMP, and he’s ready to merge the modified image with the firmware and write it back to the chip.
He boots the TV back up and finds…nothing changed. A check of the datasheet for the SPI flash chip shows there are some protection bits used to prevent modifying particular regions of the chip. So after some modifications to the Bus Pirate script and another write, he boots the TV and hopes for the best. Finally he sees the object of his affection pop up on the big screen, a subtle change that reminds him every time the TV starts about the power of reverse engineering.
Reader [poipoi] recently wrote into our tip line to tell us about an “amazingly fast” Raspberry Pi display driver with a README file that “is an actual joy to read”. Of course, we had to see for ourselves. The fbcp-ili9341 repo, by [juj], seems to live up to the hype! The software itself appears impressive, and the README is detailed, well-structured, educational, and dare we say entertaining?
The driver’s main goal is to produce high frame rates — up to around 60 frames per second — over an SPI bus, and it runs on various Raspberry Pi devices including the 2, 3 and Zero W. Any video output that goes to the Pi’s HDMI port will be mirrored to a TFT display over the SPI bus. It works with many of the popular displays currently out there, including those that use the ILI9341, ILI9340, and HX8357D chipsets.
The techniques that let [juj] coax such frame rates out of a not-terribly-fast serial bus are explained in detail in the README’s How it Works section, but much of it boils down to the fact that it’s only sending changed pixels for each frame, instead of the full screen. This cuts out the transmission of about 50% of the pixels in each update when you’re playing a game like Quake, claims the author. There are other interesting performance tweaks as well, so be sure to check out the repo for all the details.
There’s a video comparing the performance of fbcp-ili9341 to mainline SPI drivers after the break.
Continue reading “Blazing Fast Raspberry Pi Display Driver Will Melt Your Face then Teach You How”
It’s pretty hard to use the internet to complete a task without being frequently distracted. For better or worse, there are rabbit holes at every turn and whilst exploring them can be a delight, sometimes you just need to focus on a task at hand. The solution could be in the form of distraction-blocking software, razor-sharp willpower, or a beautifully crafted modern “typewriter”. The constraint and restriction of a traditional typewriter appealed to [NinjaTrappeur], but the inability to correct typos and share content online was a dealbreaker. A hybrid was the answer, with a mechanical keyboard commanding an E-ink display driven by a Raspberry Pi.
The main point of interest in this build is the E-ink screen. Though it’s easy to acquire theses displays in small sizes, obtaining a screen greater than four inches proved to be a challenge. Once acquired, driving the screen over SPI was easy, but the refresh rate was horrific. The display takes three seconds to redraw, and whilst [NinjaTrappeur] was hoping to implement a faster “partial refresh”, he was unable to read the appropriate values from the onboard flash to enable manual control of the drawing stages. Needless to say, [NinjaTrappeur] asks if people have had success driving these displays at a more usable rate, and would love to hear from you if so.
Some auxiliary hacks come in the form of terminal emulator adaptation, porting the E-ink screen library from C++ to C, and capturing the keyboard input. A handmade wooden case finishes it off.
If it’s old-school typewriters that float your boat, we’ve got you covered: this solenoid-actuated typewriter printer eventually became a musical instrument, and this daisy wheel machine produces ASCII art from a live camera.
[Via Boing Boing]