Recreating A Popular Faux-Nixie Clock

There’s a good chance you’ve seen “Nixie clocks” on the Internet that replace the classic cold cathode tubes with similarly sized LCD panels. The hook is that the LCDs can show pictures and animations of Nixie tubes — or pretty much anything else for that matter — to recreate the look of the real thing, while being far cheaper and easier to produce. It’s a hack for sure, and that’s the way we like it.

[Trung Tran] liked the idea, but didn’t just want to buy a turn-key clock. So he’s decided to build his own version based on the ESP32-S3. The WiFi-enabled microcontroller syncs up to the latest time via NTP, then uses a PCF8563 real-time clock (RTC) module to keep from drifting too far off the mark. The six displays, which plug into the custom PCB backplane, can then show the appropriate digits for the time. Since they’re showing image files, you can use any sort of font or style you wish. Or you could show something else entirely — the demo video below shows off each panel running the Matrix “digital rain” effect.

Continue reading “Recreating A Popular Faux-Nixie Clock”

Microsoft Sculpt Keyboard Lives Again With RP2040

Hackaday readers are likely the kind of folks that have a favorite keyboard, so you can probably imagine how devastating it would be to find out that the board you’ve sworn by for years is going out of production. Even worse, the board has some internal gremlins that show up after a few years of use, so functional ones in the second-hand market are becoming increasingly rare. So what do you do?

This is the position [TechBeret] recently found himself in with his beloved Sculpt keyboard. When Microsoft decided to step back from the peripheral market last year, he started looking at alternatives. Finding none of them appealing, he decided instead to breathe new life into the ergonomic keyboard with the RP2040. Every aspect of the resurrection is covered in a phenomenally detailed write-up on his blog, making this a valuable case study in modernizing peripherals with the popular microcontroller.

Continue reading “Microsoft Sculpt Keyboard Lives Again With RP2040”

I2C For Hackers: Digging Deeper

Last time, I gave you an overview of what you get from I2C, basics like addressing, interface speeds, and a breakdown of pullups. Today, let’s continue looking into I2C capabilities and requirements – level shifting, transfer types, and quirks like combined transfers or clock stretching.

Level Shifting

Continue reading “I2C For Hackers: Digging Deeper”

The Worsening Raspberry Pi RP2350 E9 Erratum Situation

There’s currently a significant amount of confusion around the full extent of the GPIO hardware issue in the Raspberry Pi RP2350 microcontroller, with [Ian] over at [Dangerous Prototypes] of Bus Pirate fame mentioning that deliveries of the RP2350-based Bus Pirate 5XL and 6 have been put on hold while the issue is further being investigated. Recorded in the MCU’s datasheet as erratum RP2350-E9, it was originally reported as only being related to the use of internal pull-downs, but [Ian] has since demonstrated in the primary issue ticket on GitHub that the same soft latching behavior on GPIO pins occurs also without pull-downs enabled.

Ian from Dangerous Prototypes demonstrating the RP2350-E9 issue in a Bus Pirate prototype without pull-ups.
Ian from Dangerous Prototypes demonstrating the RP2350-E9 issue in a Bus Pirate prototype without pull-ups.

When we first reported on this hardware bug in the RP2350’s A2 (and likely preceding) stepping there was still a lot of confusion about what this issue meant, but so far we have seen the Bus Pirate delay and projects like [Agustín Gimenez Bernad]’s LogicAnalyzer have opted for taking the RP2350 port out back. There are also indications that the ADC and PIO peripherals are affected by this issue, with workarounds only partially able to circumvent the hardware issue.

In the case of the Bus Pirate a potential workaround is the addition of 4.7 kOhm external pull-downs, but at the cost of 0.7 mA continuous load on the GPIO when pulled high and part of that when pulled low. It’s an ugly hack, but at the very least it might save existing boards. It also shows how serious a bug this is.

Meanwhile there are lively discussions about the issue on the Raspberry Pi forums, both on the E9 erratum as well as the question of when there will be a new stepping. The official statement by Raspberry Pi is still that ‘they are investigating’. Presumably there will be a Bx stepping at some point, but for now it is clear that the RP2350’s A2 stepping is probably best avoided.

Dual-Port RAM For A Simple VGA Card

Making microcontrollers produce video has long been a staple of hardware hacking, but as the resolution goes up, it becomes a struggle for less capable silicon. To get higher resolution VGA from an Arduino, [Marcin Chwedczuk] has produced perhaps the most bulletproof solution, to create dual-port RAM with the help of a static RAM chip and a set of 74-series bus transceivers, and let a hardware VGA interface take care of the display. Yes, it’s not a microcontroller doing VGA, but standalone VGA for microcontrollers.

Dual-port memory is a special type of memory with two interfaces than can independently be used to access the contents. It’s not cheap when bought in integrated form, so seeing someone making a substitute with off-the-shelf parts is certainly worth a second look. The bus transceivers are in effect bus-width latches, and each one hangs on to the state while the RAM chip services each in turn. The video card part is relatively straightforward, a set of 74 chips which produce the timings and step through the addresses, and a shift register to push out simple black or white pixel data as a rudimentary video stream. We remember these types of circuits being used back in the days of home made video terminals, and here in 2024 they still work fine.

The display this thing produces isn’t the most impressive picture, but it is VGA, and it does work. We can see this circuit being of interest to plenty of other projects having less capable processing power, in fact we’d say the challenge should lie in how low you can go if all you need is the capacity to talk 74-series logic levels.

Interested in 74-series VGA cards? This isn’t the first we’ve seen.

Hands hold a set of white, 3D printed connectors above a wooden table. They look like a cross between a ballpoint pen tip and a spider. The shorter one on the right has yellow, green, black, purple, and white wires coming out the top.

SWD Interface Simplifies Debugging

The proliferation of microcontrollers has made it easier than ever to add some smarts to a project, but sometimes there just isn’t enough space for headers on a board, or you feel a little silly soldering something that will get used to flash a program then languish inside your build. [Dima] wanted to make his boards easier to flash, and developed a PCB footprint and flashing tool pair that makes use of the mounting holes on his boards.

While some debugging tools might use a clamp or tape, [Dima] discovered that using sprung pins only on one side of the connector wedged his fixed locator pin (originally a 1 mm drill bit) into the hole removing the need for any other holding mechanism.

His original prototype worked so well that it took him some time to get back around to making a more reproducible design that didn’t involve fine soldering and superglue. After enlarging the contact pads and several iterations of 3D printing, he developed an interface connector that uses standard jumper wires and a steel rod to provide a sturdy and reliable connection for flashing boards with the corresponding footprint. He’s currently a little disappointed with the overall size of the connector though, and is soliciting feedback on how to make it smaller.

While [Dima]’s MCU of choice is the STM32, but this design should be applicable to any other microcontrollers using a five wire system, or you could take one off for USB. Having trouble finding the SWD points on an existing device? Try this method.

Thanks to [DjBiohazard] for the tip!

Continue reading “SWD Interface Simplifies Debugging”

Hardware Bug In Raspberry Pi’s RP2350 Causes Faulty Pull-Down Behavior

Erratum RP2350-E9 in the RP2350 datasheet, detailing the issue.
Erratum RP2350-E9 in the RP2350 datasheet, detailing the issue.

The newly released RP2350 microcontroller has a confirmed new bug in the current A2 stepping, affecting GPIO pull-down behavior. Listed in the Raspberry Pi RP2350 datasheet (page 1340) as erratum RP2350-E9, it involves a situation where a GPIO pin is configured as a pull-down with input buffer enabled. After this pin is then driven to Vdd (e.g. 3.3V) and then disconnected, it will stay at around 2.1 – 2.2 V for a Vdd of 3.3V. This issue was discovered by [Ian Lesnet] of [Dangerous Prototypes] while working on an early hardware design using this MCU.

The suggested workaround by Raspberry Pi is to enable the input buffer before a read, and disable it again immediately afterwards. Naturally, this is far from ideal workaround, and the solution that [Ian] picked was to add external pull-down resistors. Although this negates the benefits of internal pull-down resistors, it does fix the issue, albeit with a slightly increased board size and BOM part count.

As for the cause of the issue, Raspberry Pi engineer [Luke Wren] puts the blame on an external IP block vendor. With hindsight perhaps running some GPIO validation tests involving pull-up and pull-down configurations with and without input buffer set could have been useful, but we’re guessing they may be performed on future Pi chips. Maybe treating the RP2350 A0 stepping as an ‘engineering sample’ is a good idea for the time being, with A3 (or B0) being the one you may want to use in actual production.

In some ways this feels like déjà vu, as the Raspberry Pi 4 and previous SBCs had their own share of issues that perhaps might have been caught before production.

(Note: original text listed A0 as current stepping, which is incorrect. Text has been updated correspondingly)