When Clever Hardware Hacks Bite Back: A Password Keeper Device Autopsy

https://fed.brid.gy/r/https://hackaday.com/2026/02/07/when-clever-hardware-hacks-bite-back-a-password-keeper-device-autopsy/

MiniDexed Raspberry Pi IO Board

I’ve been toying with the idea of some kind of IO board for my MiniDexed experiments for use with a Raspberry Pi.  I initially wanted something fully self-contained – i.e. just pop it on a Raspberry Pi and you’re good to go.  But then it was pointed out that having all the IO connections on one side is much more friendly from a “putting it all in a case” point of view.

• Update: There is now a newer version of this design for the SSD1306: MiniDexed Raspberry Pi IO Board V2 Design.

In the end, I used many of the same circuit elements and came up with two designs.

Update: Here are links to the build guides for these PCBs:

• MiniDexed Raspberry Pi IO Board – SSD1306 Version
• MiniDexed Raspberry Pi IO Board – HD44780 Version

There is a version for the Raspberry Pi V1 here: MiniDexed Raspberry Pi V1 IO Board and my pseudo TX816 can be found here: MiniDexed TX816.

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

These are the key tutorials for the main concepts used in this project:

• My first experiments in KiCad: Arduino Uno Dual Merge MIDI “Shield” – Part 2
• MiniDexed: “Bare Metal” Raspberry Pi MiniDexed DX7

If you are new to microcontrollers and single board computers, see the Getting Started pages.

Basic Requirements

I wanted a board to do the following:

• Include a screen or display.
• Have MIDI IN.
• Optionally include MIDI OUT and THRU.
• Have a rotary encoder for input.
• Incorporate a PCM5102 DAC for audio output.
• Optionally include a couple of buttons.

As I mention above, I was initially after something that would fit within a normal “HAT” type footprint for a Raspberry Pi, which is pretty constraining, but following on from the Clumsy MIDI board, should be possible with a small SSD1306 OLED display.

But I was also keen to try to build something that would allow all the IO to line up along the back, so I’ve also designed a larger board that overhangs the Pi and allows for a full three MIDI din sockets.  This larger board can accommodate a HD44780 LCD display as used in the original MiniDexed setup.

I’m happy for the whole thing to receive power via the Pi and of course USB and ethernet connections are also available on one side.

MiniDexed RPi IO Board (SSD1306 Version)

Starting a new project in KiCad, there is already a “Raspberry Pi 40-pin Extension Board” template which provides the basic outline, PCB footprint for the GPIO, and cut-outs for the display and camera.

Here is the schematic I’m working to.

Points worthy of note:

• A H11L1 based MIDI IN circuit connected to RX0.
• A rotary encoder (not a KY-040 module) is used with 10pF capacitors for debouncing the connections.
• A PCM5102 in the “GY module” format (as used by Clumsy MIDI).
• Two optional button push-switches which are also broken out to headers, also with debouncing capacitors.
• I’ve included the header for the SSD1306 in SDA-SCL-VCC-GND format.

This is the GPIO map used:

If the rotary encoder seems to be “backwards” then swap RE_A and RE_B in the configuration.  Note that at the time of writing, I2C SSD1306 displays are in development but hopefully will be available in MiniDexed by the time you read this.

Here is the board that has been sent off for manufacturing.

Design notes:

• I used the GY-PCM5102 symbol and footprint library from the Clumsy MIDI GitHub repository.
• The H11L1 is upside down as that made routing easier.
• I’ve included footprints for two push-buttons (the very common “through hole” type used in many maker projects) but also included two sets of header pins so these could be wired off to something else if required.
• I’m using a 32×128 OLED (again the same one used with Clumsy MIDI).  As I say, MiniDexed doesn’t support this directly at the time of writing, but I’ve submitted a PR for support that is waiting to be accepted, so hopefully it will be fully supported soon.
• Unlike my previous boards, I used a filled zone to create a link to the GND net and provided a ground plane on the rear copper layer of the board.
• Both the SSD1306 and PCM5102 modules I’m using have a built-in regulator to take 5V down to 3V3.  This is particularly critical for the SSD1306 as it includes pull-ups for the I2C connection to the 3V3 level (not 5V).  But this is why they are hooked up to 5V yet I’m not using level-shifters to interface to the (3V3 logic) Pi.

Here is an early “space test” (without the buttons) with a paper printout to give you an idea of what I’m aiming for.

And an image of the Gerbers as sent off for manufacture:

MiniDexed RPi IO Board (HD44780 Version)

Again starting a new KiCad project from the Raspberry Pi 40-pin extension board template, this is the circuit I’m working with for this one.

Schematic Notes:

• This is using the same PCM5102, rotary encoder, and switches as above (although I’ve just realised I never swapped the schematic and pcb over to use the GY-PCM5102 module symbol and footprint – oh well, for this board it is a 6-way set of headers!).
• This uses the “data interface” version of the HD44780. I did think about using the I2C version, but thought this would be the simplest case to build if it could be made to work.
• There is MIDI IN, OUT and (optional) THRU.
• The MIDI circuit borrows heavily from Clumsy MIDI and includes a 74HCT14 hex inverter as an output buffer for OUT and THRU (although it is labelled as a 74HC14 on the schematic and pcb).
• THRU is optional, in which case the unused inputs to the 74HCT14 should go to GND instead (selected by solder jumpers).
• OUT can optionally be changed to a(nother) THRU rather than an OUT, in which case it can be switched via solder jumpers to be connected to RX0 rather than TX0.

To simplify the routing of the PCB, the pinouts for the various components have changed.  Here is the pinout being used (this is now quite different to the original MiniDexed pinout).

So this is the design for the pcb that has been sent off for manufacture:

Design notes:

• The PCB is designed to be used with a Raspberry Pi “upside down”.  That is, with the connectors at the top, and GPIO at the bottom.  This means the USB/RJ45 ports will be on the left hand side, as shown.
• The MIDI THRU section is optional.  If only two MIDI sockets are required that part of the board can be cut off along the line indicated.  If that is done then the solder jumpers beneath the 74HC14 must be changed as follows:
  • Cut the “THRU” jumper (this disconnects the 74HC14 from RX0).
  • Solder the “NO THRU” jumper (this connects the unused 74HC14 port to GND).
• The MIDI OUT port can be changed to a THRU too.  If the original THRU is removed, this means you can just have MIDI IN and THRU instead of IN and OUT if you wish. If the original THRU is retained, then you can have a MIDI IN and two THRUs. To turn the OUT into a THRU change the two solder jumpers near the H11L1 as follows:
  • Cut the “OUT” jumper (this disconnects the OUT circuit from TX0).
  • Solder the “THRU” jumper (this connects the OUT circuit to RX0 to make it a THRU).
• Whilst on the subject of MIDI sockets, all three sockets are oriented to go underneath the board so they will go alongside the RPi.
• The optional buttons are not provided on the PCB, but via two sets of headers on the left hand side of the board.
• As mentioned above, annoyingly I forgot to change the PCM5102 footprint to that of a GY-PCM5102 module, so there are no holes for the additional 9-way header.  These are not used electrically, but they would have provided some additional physical support.  Instead I might solder some header pins and use the plastic pin spacer as a support under the board (but I’ll look into that when I get the boards back).
• I’ve included a simple “preset” pot to control the contrast for the LCD.
• Once again I used a filled zone to create a link to the GND net and provide a ground plane on the rear copper layer of the board.  Note that I left a cut-out under the traces to the THRU part of the circuit, to reduce the chance of a short if the board is cut off at this point.
• Most LCD1602/HD44780 modules are 5V parts, with 5V required to ensure the LCD actually illuminates successfully. However, as described here, it is usually ok for a 3V3 output to drive a 5V input, so as long as the LCD isn’t attempting to drive the IO pins for the Pi, the Pi should be fine talking 3V3 to the LCD. So that is the approach I’m taking. It does mean that this won’t accept a 3V3 LCD module. But in all this, remember my level of electronics experience, and make up your own mind…

Manufacturing

Both boards should be built using the standard, cheapest manufacturing options.  Both are fine with a 6/6 mil constraint on track width and separation.

The second board is somewhat larger than the common “cheap” tier.  For me, all my other boards were $4.60 plus postage for 10 boards, but the larger one has jumped up to around $27 plus postage.

On the back of my first blog post, having used Seeed Fusion to produce my first boards, they sent me some money off vouchers, so I’ve used them once again here.  That was particularly welcome given the increased cost of the larger board!

I still don’t really have a space to store these designs.  But I’ll update this post when I do!

Closing Thoughts

Although either of these designs could potentially be used in a case to make a nice, small, self-contained unit, I can’t guarantee that the spacing of connectors and components will really allow it.  I’m also not sure what will be required in terms of cooling for the Pi, so I’ll have to see how I get on.  It may be that I’ll need more spacing between the Pi and the IO board.

I’m still learning with KiCad, so am fully expecting continued mistakes or odd design choices, but I think both of these will be interesting to try.

Update: mistakes already spotted since sending them off:

• The afore-mentioned GY-PCM5102 footprint error.
• Labelling on the board states 74HC14 and it really has to be a 74HCT14.

So that is the walk-through of the design of these boards.  Of course I won’t really know if they are successful until I get the boards back from manufacturing!

Kevin

#hd44780 #midi #minidexed #pcb #pcm5102 #raspberryPi #ssd1306

Small Microcontroller Displays

I found myself wanting several small displays connected to a microcontroller, so was doing a bit of a trade-off between various options, and was starting to lose track, so this post collects some of those thoughts together.

It is not meant to be a comprehensive discussion of choosing small displays for projects, but more of a reflection on the displays I already have kicking around in my parts boxes!

Most displays tend to be categorised by the driver chip they use. And then by the bus type used for their connection. So that is how I’ve grouped them here.

A really good reference for many of the displays shown here is: https://www.lcdwiki.com/Main_Page

I2C SSD1306 OLED

This is usually my “go to” set of small displays. They are generally well supported and pretty easy to use.

I generally have two variants to choose from:

On the left is the 0.91″ 128×32 OLED SSD1306 and on the right is the 0.96″ 128×54 OLED SSD1306. Common properties of both displays:

• Monochrome – white or blue.
• I2C interface.
• Usually 5V powered, but some include level shifters to allow 3V3 logic.
• Usually includes I2C pull-ups. Might be to VCC level so be wary if using a 3V3 MCU but powering from 5V – always check the voltage level prior to connecting.
• 128×32 usually a fixed I2C address (0x3C). 128×64 usually allows selection between 0x3C and 0x3D.
• There are variants with VCC and GND swapped, and other variants with SDA and SCL swapped.

Software support:

• The “go to” library for Arduino is the Adafruit_SSD1306 library, which assumes the use of the Adafruit_GFX library too.
• But there are lots of alternative libraries too, for example u8glib.
• Well supported in Circuitpython or Micropython.
• More here: Arduino Nano Every I2C and SPI Displays.

Typical Connections:

• VCC/GND (see note below re VCC vs logic levels).
• SCL/SDA – I2C pins on the MCU.

Known “gotchas”:

• Requires a chunk of memory allocated on start-up on Arduino, which can fail if there isn’t enough dynamic memory left and make a sketch hang.
• Can’t be written to from an interrupt routine (e.g. a timer).
• Low-level I2C Wire library on Arduino is blocking.
• Can sometimes be a little slow compared to alternatives.
• Limited I2C address options, so multiple display use is limited (and also increase the memory issues).
• As already mentioned, any I2C pull-ups may be pulled up to the VCC level or might be level shifted, so it is always worth checking if planning to use with a 3V3 microcontroller.

Summary:

• Cheap, pretty easy to use, and fairly universal if you want a single, small, monochrome display for simple outputs.

Other I2C Variants

There are some variants of the SSD1306 that sometimes pops up too for slightly larger displays:

• SSD1315 – apparently can simply be treated as a SSD1306 and mostly it works ok.
• SH1106 – very similar niche to SSD1306 but requires it owns driver support.

SPI ST7735/89/96 TFT

Whereas the SSD1306 I2C is pretty ubiquitous for monochrome displays, I’ve tended to find that SPI ST77xx displays fill a similar niche for small, full colour, non-touch, TFT displays. And there are loads of variations on the theme when it comes to these displays.

The 7735 supports lower resolution, smaller displays, typically up to 170×320, with the 7789 for those of 240×240 or 240×320 and similar. There is also a ST7796 which I believe uses the same driver libraries for a higher 320×480 display.

Two 7735 Displays:

These two ST7735 displays that I have are labelled:

• TFT 0.96″ 80×160 SPI ST7735
• TFT 1.8″ 128×160 SPI ST7735

These ST7789 display I have is labelled:

• TFT 1.3″ 240×240 SPI ST7789

I also have a display that was bought as a ST7789 labelled “TFT 2.8″ 240×320 SPI” which comes with a touch screen, but I can’t get this to work.

Common properties:

• SPI interface: data (SDA/MOSI/COPI), clock (SCK/SCLK), chip select (CS), data/command (SR/DC), possibly a reset.
• Typically 65536 colours, usually encoded as 5-6-5 bit RGB patterns.
• Have to check for 3V3 or 5V operation depending on the datasheet of the driver chip and design of the module.

Software support:

• Adafruit SST77x Library supports ST7735 and ST7789, once again also requiring Adafruit_GFX.
• Arduino_GFX Library supports a whole range of displays and microcontrollers, including the ST77xx devices.
• TFT_eSPI for Raspberry Pi Pico, ESP32 and others.
• MCUFRIEND_kbv for Arduino and “MCUFRIEND” type displays. Wide range of TFT display drivers supported.
• Tiny TFT Library for ATTiny85 and Compact TFT Library for a range of MCUs by David Johnson-Davies (technoblogy)
• https://github.com/bitbank2/bb_spi_lcd. Standalone library for ST7735, ST7789 and others, with a set of pre-configured “named” displays.
• More here: Arduino and a Cheap TFT Display.

Typical Connections:

• VCC/GND
• CLK/SDA – SPI Clock and Data (Data OUT from MCU – i.e. MOSI/COPI)
• RES – Reset
• DC, RS – Data/Command Register Select
• CS – Chip Select

Known Gotchas:

• Working out if RS means reset of the data/command pin; and not mixing up SCL/SDA with I2C!
• Some might include a backlight control pin too for dimming or turning it off. With this not connected the display was a maximum brightness.
• I’ve also seen talk that many of these modules themselves run at 3V3, so whilst they may include a regulator for 5V to 3V3 for power, they don’t always include level shifting for the signal pins. It seems unclear (to me at least at the moment) if it is ok to use these with a 5V microcontroller (although I have done…).
• Some of these displays are “inverted” colour wise. The use 16-bit 5-6-5 format colours, but some are RGB, some are BGR and there might be other variants too.
• Sometimes the initialiser for the library requires a SPI_MODE setting. My ST7789 240×240 required the Adafruit ST7789 initialisation as follows:

Note, unlike the monochrome displays, these have their own pixel framebuffer so memory use is much more efficient, even when used as a full colour display.

Summary:

• Cheap, pretty easy to use once the voltage levels and the pin labelling are worked out. Well supported by a number of libraries; but does require more pins for 4-wire SPI. Might need some messing around to get the right colour definitions. Otherwise a good choice if you just want a cheap, colour display with no touch.

OLED SH1122 SPI

There are actually both I2C and SPI versions of SH1122 displays, but I’m considering the SPI version here. The display I have is a 256×64, monochrome OLED display.

Software Support:

• U8G2 library:https://github.com/olikraus/u8g2
• Use the SH1122 constructors: https://github.com/olikraus/u8g2/wiki/u8g2setupcpp#sh1122-256×64

Example:

Typical Connections:

• VCC/GND – mine states it can support either 3V or 5V power
• CLK/SDA – SPI Clock and Data (Data OUT from MCU – i.e. MOSI/COPI)
• RES – Reset
• DC, RS – Data/Command Register Select
• CS – Chip Select

The _F_ constructor requires a full frame-buffer so is unlikely to work on resource constrained devices (e.g. the Arduino Uno/Nano). The _1_ constructor provides a pageable interface which allows for the updating of the display in pages, which takes longer but allows it to be used with more devices.

There are also software SPI versions that allow the use of any GPIO pins.

Summary:

• A pretty neat board if these physical dimensions match what is required.
• There are a whole pile of example sketches in the U8G2/page_buffer directory.

ILI9341/9488 TFT

Cheap larger displays are often driven by one of the ILI9341 or ILI9488 chips. The former supports 240×320 in full (16-bit) colour whereas the 9488 tends to support larger displays of up to 320×480 in full (24-bit) colour. Both support either a parallel (at least 8, 9, 16-bit) or serial (3 or 4 wire SPI) bus interface.

I don’t have a lot of detailed information for this post yet, but instead will refer to:

• Cheap ILI9488 TFT LCD Displays
• https://github.com/bitbank2/bb_spi_lcd

The ILI9341 is well supported by the Adafruit graphic libraries, but the ILI9488 is likely to require something else, as described in the above post.

These displays are often used with touch support and will often expect to run at 3V3 logic levels.

LCD 1602 HD44780

This is another very common monochrome, but text only, display. They have a 4 or 8-bit parallel interface, but it is also quite common to use the with an I2C “backpack” based on the PCF8574 I2C IO expander. Boards can be cheaply bought with or without a backpack, and the backpacks are available separately too for retro fitting to displays without them.

They are often called “1602” displays as they are two rows of 16 characters. By using custom blocks it is possible to have some simple graphics. There are LCD2004 modules too with four rows of 20 characters.

They often come with a choice of backlight colours. White or red are particularly striking! There are some variants that come with an additional I2C controller chip built in to control the backlight and some even come with a full RGB backlight capability.

Typical Connections:

• VCC/GND
• Data – either 4 or 8 bit modes support
• E, RW, RS – enable, read/write, register select.
• Backlight V+/GND – level is often fixed using a resistor.

There are core Arduino libraries to support the most basic versions of these displays:

• LiquidCrystal
• LiquidCrystal_I2C

Typical Gotchas:

• The I2C backpacks often include pull-ups to VCC, yet many of these displays require 5V even if used with a 3V3 microcontroller. One option is to remove the pull-ups and add external pull-ups to 3V3.
• If there are only blocks on the display then the communications isn’t working properly – check SDA/SCL or the control lines.
• If there is nothing on the display or the text is obscured by blocks behind it, then the contrast is either too low or too high. I2C backpacks have a potentiometer to adjust the contrast.
• More complex versions require an additional I2C setup phase, e.g. to turn on the backlight, which isn’t supported by the standard libraries.

Summary:

• Very useful if a large, high/adjustable contrast, text-only display is required.

Others

So I don’t forget when considering the above, I also have:

• GC9A01 based 240×240 1.28″ circular SPI display like this one: https://www.waveshare.com/wiki/1.28inch_LCD_Module. Note: cheaper versions of this won’t include level shifting and will expect to run at 3V3.
• ESP32 boards with built-in displays: ESP32-C3 0.42 OLED
• ESP32 “Cheap Yellow Display” boards, details here: https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display
• Range of small displays from Pimoroni, Waveshare and others for use with the Raspberry Pi Pico.
• Waveshare small HDMI displays for use with a Raspberry Pi.

I’ll add to the list for my own reference as I remember other odds and ends.

Kevin

#hd44780 #ili9341 #ili9488 #include #lcd1602 #oled #ssd1306 #st7735 #st7789 #tft

I really hate breadboards and the most, the wires - they are everywhere!
So after it seemed to worked on breadboard, I now soldered my first prototype of my idea having a #ESP01 with a #HD44780 as network display.
It was kind of difficult to get the right #LiquidCrystal_I2C, since its years old and doesnt work with later modules. And now: lets do some coding!

#IoT #ESP8266 #tinkering