We know, we know — yet another Nixie clock. But really, this one has a neat trick: an easy to use, feature packed driver for Nixies that makes good-looking projects a snap.
As cool as Nixies are — we’ll admit that to a certain degree, familiarity breeds contempt — they can be tricky to integrate. [dekuNukem] notes that aside from the high voltages, laying hands on vintage driver chips like the 7441 can be challenging and expensive. The problem was solved with about $3 worth of parts, including an STM32 microcontroller and some high-voltage transistors. The PCBs come in two flavors, one for the IN-12 and one for the IN-14, and connections for the SPI interface and both high- and low-voltage supplies are brought out to header pins. That makes the module easy to plug into a motherboard or riser card. The driver supports overdriving to accommodate poisoned cathodes, 127 brightness levels for smooth dimming, and a fully adjustable RBG backlight under the tube. See the boards in action in the video below, which features a nicely styled, high-accuracy clock.
From Nixie tachs to Nixie IoT clocks, [dekuNukem]’s boards should make creative Nixie projects even easier. But if you’re trying to drive a Nixie Darth Vader, you’re probably on your own.
For those of us not old enough to remember, and also probably living in the States, there was a relatively obscure computer built by Microsoft in the early 80s that had the strong Commodore/Atari vibe of computers that were produced before PCs took over. It was known as the MSX and only saw limited release in the US, although was popular in Japan and elsewhere. If you happen to have one of these and you’d like to play some video games on it, though, there’s now a driver (of sorts) for SNES controllers.
While the usefulness of this hack for others may not help too many people, the simplicity of the project is elegant for such “ancient” technology. The project takes advantage of some quirks in BASIC for reading a touch-pad digitizer connected to the joystick port using the SPI protocol. This is similar enough to the protocol used by NES/SNES controllers that it’s about as plug-and-play as 80s and 90s hardware can get. From there, the old game pad can be used for anything that the MSX joystick could be used for.
We’ve seen a handful of projects involving the MSX, so while it’s not as popular as Apple or Commodore, it’s not entirely forgotten, either. In fact, this isn’t even the first time someone has retrofitted a newer gaming controller to an MSX: the Wii Nunchuck already works for these machines.
For this year’s Hackaday Prize, we’re giving everyone the opportunity to be a hardware startup. This is the Best Product portion of the Hackaday Prize, a contest that will award $30,000 and a residency in our Design Lab to the best hardware project that is also a product.
Imagine all the memory chips in all the landfills in the world. What if we could easily recover those hosed motherboards and swap out ROM files on malware-damaged chips. That’s the promise of [Blecky]’s EEPROM/Flash Emulator project on Hackaday.io. This project seeks to be the ultimate memory interface, emulating SPI-interface EEPROM or Flash memory chipsets with ease. It can also be used as a security device, checking the BIOS for untoward changes.
The EEEmu packs an Atmel SAM4S Cortex-M4 processor-based microcontroller, an SD card reader, a micro USB for reprogramming, boost converter, voltage regulator, and includes additional 3.3V GPIO/I2C ports, all on a wee 51.5x20mm circuit board. Version 2 is slated to include more features to facilitate use as a normal micro controller: more GPIO pins, USB voltage monitoring, and high-Z control for SPI output.
EEEmu is completely open source, with [Blecky] sharing his code on GitHub and even has created an EEEmu Fritzing part, also found in his repository.
The ESP32 is the successor to the wildly popular ESP8266. There seems to be no end to what the chips can do. However, despite all the wireless communication capabilities, the module doesn’t have a display. [G6EJD] wanted to connect an ILI9341 TFT display and he put the code and information on GitHub. You can also see a video of his work, below.
Since the display uses a serial interface, there isn’t much wiring required. The Adafruit GFX library does the heavy lifting, utilizing the SPI library for the actual communications. The first demo shown on the hardware can pull weather data decoded. If you want more details on the display’s operation, check out [G6EJD’s] YouTube channel and you’ll find other videos that go into more detail.
We’ve seen these displays married to an ESP8266 with an integrated PCB, too. There’s a choice of libraries, and perhaps we’ll see a similar range of choice for the ESP32.
Continue reading “ESP32 Display is Worth a Thousand Words”
While it’s true that your parts bin might have a few parts harvested from outdated devices of recent vintage, there’s not much to glean anymore aside from wall warts. But the 3×48-character LCD from [Kerry Wong]’s old Uniden cordless landline phone was tempting enough for him to attempt a teardown and reverse engineering, and the results were instructive.
No data sheet? No problem. [Kerry] couldn’t find anything out about the nicely backlit display, so onto the logic analyzer it went. With only eight leads from the main board to the display module, it wasn’t likely to be a parallel protocol, and the video below shows that to be the case. A little fiddling with the parameters showed the protocol was Serial Peripheral Interface, but as with other standards that aren’t exactly standardized, [Kerry] was left with enough ambiguity to make the analysis interesting. Despite a mysterious header of 39 characters, he was able in the end to drive the LCD with an Arduino, and given that these phones were usually sold as a bundle with a base and several handsets, he ought to have a nice collection of displays for the parts bin.
With how prevalent this protocol has gotten, [Kerry]’s post makes us want to get up to speed on the basics of SPI. And to buy a logic analyzer too.
Continue reading “The Other Kind of Phone Hacking”
If you’re at all into medical hacks, you’ve doubtless noticed that the medical industry provides us with all manner of shiny toys to play with. Case in point is a heart-monitoring IC that’s so brand new, it’s not even available in all of the usual distributors yet. [Ashwin], who runs a small prototyping-supplies company, ProtoCentral, has been playing around with the new MAX30003 ECG chip, and the results look great.
The punchline is that the four-to-five dollar chip does everything for you, including analog filtering, wander removal, and even detecting the pulse rate. Using the chip is simple: you plug in two electrodes on one end, and you get the waveform data out over SPI on the other, with little or no work to do on the microprocessor side. The Arduino in the examples is just passing the SPI data straight to the laptop, with no processing going on at all.
[Ashwin] is selling these as breakout boards, but everything is open source, from the hardware to the GUI, so check it out if you’re interested in building your own. In particular, the circuit is just a voltage regulator and five volt level shifter.
Everything we know about electrocardiography projects, we learned from this presentation, and it looks like the devil is in the (many) details, so it’s nice to offload them to custom silicon whenever possible. We just think it’s awesome that we can scoop up some of the giant medical industry’s crumbs to play around with.
Are you already comfortable working with Serial Peripheral Interface (SPI) parts and looking for a challenge? We suspect many of you have cut your teeth on 8-bit through 32-bit microcontrollers but how much time have you spent playing with hardware interfaces on embedded Linux? Here a new quest, should you choose to accept it. [Matt Porter] spoke in detail about the Linux SPI Subsystem during his presentation at FOSDEM 2017. Why not grab an embedded Linux board and try your hand at connecting some extra hardware to one of the SPI buses?
The hardware side of this is exactly what you’d expect from any embedded SPI you’ve worked on: MOSI, MISO, a clock, and a slave select. [Matt] gives a succinct overview of SPI and reading datasheets. Our own [Elliot Williams] has done an excellent job of digging through the basics and most common gotchas if you need to get up to speed on all the SPI basics.
The fun details in the talk start at about 18:30 into the video when [Matt] jumps into the Linux side of SPI. You need a controller driver and a protocol driver. The controller driver is responsible for dealing with the pins (actual hardware) and the protocol driver handles the job of making sense of the SPI packets (messages containing any number of transfers) going in or out. In other words, the controller drive just want bits and pushes them in or out on hardware, the protocol driver makes those bits meaningful to the Linux system.
Adding SPI devices (think devices like LCDs and sensors) to your own embedded systems means telling the OS the particulars about that hardware, like max speed and SPI mode. There are three ways to handle this but the Device Tree is the preferred method for modern systems. This paves the way for the controller driver which implements an API set that the Linux SPI subsystem will use to work with your new hardware.
Protocol drivers follow the standard Linux driver model and are pretty straight forward. With these two drivers in place the new device is hooked into the OS and opens up common SPI API calls: spi_async(), spi_sync(), spi_write(), and spi_read(), and a few others.
Continue reading “SPI On Embedded Linux”