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.

According to [TechBeret], the biggest problem with the Sculpt was its wonky wireless hardware. It was bad enough that the board was permanently paired to its USB dongle, but apparently, the RF side of things would degrade over time, leading to an ever shorter range. So he decided the best course of action was to simply give the board a brain transplant. Since he didn’t really want it to be wireless anyway, he figured it wouldn’t be too difficult to create a replacement PCB that reads the keyboard matrix and speaks USB Human Interface Device (HID).

In fact, he was able to find a couple of projects that did that exactly. Instead of copying them, he took them as inspiration to help direct his own effort. His primary goal was to develop a drop-in replacement for the original PCB — specifically, he didn’t want to have to take a Dremel to his keyboard just to get it working again. He also wanted to use components he knew would be available for the foreseeable future, as well as bring USB-C support to the party. Finally, he didn’t want to get bogged down in writing code, so the replacement board had to be able to run the popular QMK firmware.

By his own admission, [TechBeret] is no expert in such matters. But that makes the write-up all the more compelling. Rather than seeing a perfect result on the first attempt, we get to learn along through his trials and tribulations. Even if you’ve done this kind of thing before, we bet you’ll pick up some interesting tricks along the way. We particularly liked his tip about test-fitting your PCB by exporting it as a STEP file and 3D printing a replica.

It might seem like a lot of work to save a keyboard, but then, those who’ve come to love it — like our very own [Lewin Day] — will tell you the Sculpt isn’t just any keyboard. QMK might even make it better.

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

Today, the overwhelming majority of I2C devices are 3.3 V logic. but this wasn’t always the case. If you work with old tech or with I2C on VGA/DVI/HDMI ports, you will see 5 V I2C networks, and if you work with very new tech, you will see 1.8 V I2C networks; rarely, you might even see 2.5 V networks!

Interfacing 5 V devices with a 3. 3V controller, it might not be necessary to level shift. You need to a) wire pullups to 3.3 V, and b) win the device input tolerance lottery. Same goes interfacing 3.3 V devices with 1.8 V hosts – wire up pullups to 1.8 V and pray to the stars. It can work in production – here’s Adafruit taking the 3.3 V-pulled-up Raspberry Pi I2C bus, and connecting it to a 5 V-powered MCP23017 chip that drives a 5 V-connected HD44780 display.

If your arrangement is different, or you’re experiencing a problem, you will want a level shifter circuit. At their simplest, two N-FETs like 2N7002 will do wonders. If you want smaller PCB footprint, better parameters, or more channels, there are level shifter chips, with many of them wonderfully suited for I2C (read the datasheet!). As we’ve featured before, some shifter ICs are too smart for their own good, while others will do just fine – if in doubt, remember to use your logic analyzer judiciously.

Two Ways To Talk

There are two kinds of I2C transfers you could expect to perform – I’d call them “simple transfers” and “register transfers”. With simple transfers, you send an address, and after the device ACKs, you either send or receive a single byte – it’s just like working with a shift register. With register transfers, you send an address, then a register number, and the device sends you the “contents” of that register – it’s more like working with an SPI display.

The PCF8574 is an I2C GPIO expander that does simple transfers. It has eight GPIO pins, and it only does simple transfers. How does that work, given it does both input and output? Well, the PCF8574 has only three possible states for all pin, with two of them combined together. The “Low” state (writing 0) is a hard pull down to GND. The “High” state (writing 1) is a weak pull to VCC – which also makes the pin work as an input with a pullup enabled. To check the input state, just read the expander state, and see if any of the pins you’ve set to 1 are now reading as 0. You can’t do a lot of high-side driving, sure, but you can still drive LEDs and check buttons, plus, this scheme is dead simple and covers a ton of use cases.

A good few I2C devices use simple transfers – the LM75 temperature sensor, for instance, only has to return temperature. You can read out multiple bytes at once, of course – simple transfers aren’t inherently limited to a single byte! PCF8575, the 16-bit sister of the PCF8574, has 16 GPIOs, I’ve used simple transfers with an ATMega328P keypard controller I created at some point – it would return keycodes, taken from a ring buffer. However, at some point, I decided to add more features to it, like ADC reading to help out a Pi Zero it was connected to, and had to upgrade it to register transfers.

The MCP23017 is a GPIO expander that uses register transfers. It has 16 GPIO pins, and a ton of features, each with their own register. Since one register contains 8 bits and we have 16 GPIOs, there are two registers per feature, and as such, there are two registers for pin directions, two for enabling integrated pullups, two for reading out input states, two for setting pins as outputs, and so on. They can even be arranged in two different ways, one backwards compatible with a different chip, by changing a bit in the status register! It’s a fair bit more complex chip than the PCF8574, but the complexity pays off where you need it.

I2C EEPROMs work with register transfers, too – some use 8-bit addresses, which allows for up to 256 bytes of storage. Higher-capacity EEPROMs use 16-bit (two-byte) addresses, where you’re expected to send in two bytes before you can read data out; if you try to read from such an EEPROM using two-byte addresses, you will just read back zeroes, so beware!

Quirks

But what if the device can’t keep up with the multi-byte transactions that your microcontroller is asking for? Maybe you have an EEPROM that needs time before it can read out a value from its internal memory so that it your MCU can receive it, maybe it’s a sensor that needs to average some values quickly and it just can’t catch up with even the lax timing requirements of 100 kHz I2C.

There’s a solution – it’s called clock stretching, and it’s basically an I2C device holding SCL low after receiving a byte, extending ACK state for a long time, until it can actually return meaningful data. As long as SCL is low, the controller should wait for the device. It’s essentially a way for a device to say “wait, not yet, I need some time before I can give you what you’re looking for”.

Raspberry Pi didn’t support clock stretching for the longest time due to a silicon bug. Every single Pi version before Pi 4 couldn’t handle clock stretching, including all of the Pi Zero versions released at the time of writing this article. The workaround, if you need one – use software I2C. It consumes more CPU since you have to use a kernel driver that bitbangs the bus, but it does have functional clock stretching. And of course the Raspberry Pi isn’t alone: if you are likely to need clock stretching, make sure that the microcontroller hardware peripheral supports it properly.

Next time, we dive into the physical layer, look at logic analyzer traces, understand how communication happens, and the ways it can break despite our best intentions.

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.

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.

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.

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!

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 as errata 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)

When we think of programmable hardware, we think of FPGAs. But they’re not the only option. [Oliver Schmidt] has been exploring how the Raspberry Pi Pico can serve in such a role for the classic Apple II. The talk was presented at the KansasFest event this year, and it’s well worth diving into!

[Oliver] has developed A2Pico. It’s a series of Apple II peripheral cards that are based around the Raspberry Pi Pico, as you might have guessed. [Oliver] has been working in the area since 2021 with one [Glenn Jones], with the duo experimenting with connecting the versatile microcontroller directly to the slot bus of the Apple II. [Ralle Palaveev] then chimed in, developing the A2Pico hardware with solely through-hole components for ease of assembly.

A number of cards have been developed based on A2Pico, including a storage device, a Z80 CP/M card, and a specialized card to play Bad Apple on the IIGS. It’s all thanks to the versatility of the programmable I/O (PIO) peripheral inside the Raspberry Pi Pico. This device enables the Pico to be reprogrammed to handle all sorts of complicated tasks at great speed. This is particularly useful when using it to bit-bang a protocol or talk with another machine, and it serves perfectly well in this role. Basically, by reprogramming the Pico and its PIO, the A2Pico design can become any one of a number of different add-on cards.

It’s well worth diving into this stuff if you’ve ever contemplated building your own peripheral cards for 8-bit and 16-bit machines. We’ve seen some other great add-on cards for vintage machines before, too.

[Marius Taciuc’s] latest endeavor, the B4 Thinker, offers a captivating glimpse into microcontroller architecture through a modular approach. This proof-of-concept project is meticulously documented, with a detailed, step-by-step guide to each component and its function.

Launched in 2014, the B4 Thinker project began with the ambitious goal of building a microcontroller from scratch. The resulting design features a modular CPU architecture, including a base motherboard that can be expanded with various functional modules, such as an 8-LED port card. This setup enables practical experimentation, such as writing simple assembly programs to control dynamic light patterns. Each instruction within this system requires four clock pulses to execute, and the modular design allows for ongoing development and troubleshooting.

While still in its draft phase with some incomplete components, the B4 Thinker project stands out for its educational value and the thorough documentation provided. This modular approach not only supports incremental improvements but also serves as a valuable learning resource for those interested in computer architecture and design.

It seems like four bits is the sweet spot of not to complicated, but not too simple. So we see a lot of 4-bit CPUs. Some even use discrete transistors.

[Mellow_Labs] wanted an Everything Presence Lite kite but found it was always out of stock. Therefore, he decided to create his own. The kit uses a millimeter wave sensor as a super-sensitive motion tracker for up to three people. It can even read your heart rate remotely. You can see a video of the project below.

There are a few differences from the original kit. Both use the C4001 24 GHz human presence detection sensor. However, the homebrew version also includes a BME680 environmental sensor.

If you haven’t seen a millimeter wave sensor—often written mmwave—before, it is essentially a tiny radar that can measure movement, acceleration, and angles very accurately. They are available at different microwave wavelengths and have onboard processing to easily provide useful information for a processor like the one in this project. The processor on board is an ESP32, which works well with [Mellow_Labs’] home automation system.

A 3D-printed case rounds everything out. Circuit-wise, there isn’t much going on since everything is on a module PCB. You essentially just have to connect everything together.

These sensors can do a lot of things. For example, inspecting pipelines. Another common way to detect people is to use a specialized camera.