Raspberry Pi Pico Gets A Tiny Keyboard On Its Back

With hackers and makers building custom computing devices that don’t necessarily follow conventional design paradigms, there’s been a growing demand for smaller and smaller keyboards. Many of the cyberdecks we’ve seen over the last couple of years have used so-called 60% or even 40% keyboards, and there’s been a trend towards repurposing BlackBerry keyboards for wearables and other pocket-sized gadgets. But what if you need something even smaller?

Enter this incredibly diminutive keyboard created by [TEC.IST]. With 59 keys crammed into an area scarcely larger than three US pennies, it may well be the smallest keyboard ever made. The PCB has been designed to mount directly onto the back of a Raspberry Pi Pico, which is running some CircuitPython code to read the switch matrix and act as a standard USB Human Interface Device. The board design files as well as the source code for the Pico have been released on the project’s Hackaday.io page, giving you everything you need to spin up your own teeny tiny input device.

The Pi Pico’s castellated pads make attaching the PCB a snap.

Of course, you probably won’t be breaking any speed records when banging out text on this thing. We know from past Hackaday badges that an array of microswitches make for a functional, if somewhat unpleasant, method of text entry.

25 thoughts on “Raspberry Pi Pico Gets A Tiny Keyboard On Its Back

      1. All my keyboards come with one. Its located directly above the left shift key. Unfortunately its often misconfigured as a sort of shift toggle, really annoying when you hit it by accident.

  1. This is so tiny, it’s probably completely useless.

    A simple solution would be to use a chorded keyboard. A Braille keyboard to be exact. That’s seven keys, including spacebar. Add Shift, Ctrl, Alt, Enter and Backspace and you end up with 12-key multi-function keyboard that can be used for many different projects. On a side note I learned to read Braille by hand in six months. After another six months I forgot most of it.

  2. I’m looking for a method of reading 80+ switches closed simultaneously, to control as many neopixels as there are switches. Scanning or polling the switch matrix to setup an array controlling the neopixels would work. If it needs an Arduino or RPi reading the switches and another controlling the neopixels, that would work, if they can communicate over a simple cable.

    1. True NKRO like that will require N inputs – a switch matrix won’t get you there. On the upside, there are high pin count (e.g. 42) I2C and SPI I/O expanders. Most of which have programmable pull-ups included. So, for ~80 keys, you’ll need ~2 expanders ICs. Pretty straightforward solution, really.

      An FPGA is also an surprisingly cost-effective option for 80+ keys – and they have other advantages, such as highly customizable debounce – but they’re almost certainly overkill for a low performance keyboard.

      1. With a diode per switch a switch matrix will absolutely give you true NKRO. You don’t need an input per switch, that’s just madness. You put a diode between either the rows or the columns and your switches, that means adjacent pressed keys don’t conduct during incorrect parts of the scan.

        1. Hey, Shannon – I appreciate your reply, and I concur. I see now that I fell victim to having both too much and too little experience.

          In a previous (commercial) design, I had the need to handle a great multitude of discrete inputs, with a heterogeneous mix of characteristics and moderate speed (high kHz * n inputs) – a situation that genuinely called for dedicated hardware to handle well. And so, that was top of mind.

          However, although I was familiar with the diode matrix scheme on an academic level, I’ve never actually designed/built a keyboard per se. So, yeah, . Clearly both the requirements and the solution are much simpler.

          For _completeness alone_, I’ll mention that the design/s of “madness” (totally agree) do have the benefit of particularly low latency – since most, if not all of the ICs mentioned are able to fire interrupts on level change. Some even have programmable, per-key debounce. (I thought that was completely common sense and yet cool when I first noticed that available option.) How important these features are, vs active scanning and debounce, naturally depends on the application.

          Obviously this is just one of a zillion pages on the subject, but I found it to be succinct and helpful when trying to rejigger my thoughts on keyboard matrices:


          Again, thanks for the feedback and the recommendation. Cheers.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.