Tiny Mechanical Keyboard, Powered By Pi Pico

For some applications, smaller is better and that is precisely the thinking behind a diminutive keyboard like the PiPi Gherkin, which is designed to use the Raspberry Pi Pico as its controller. This keyboard may have only 30 keys in total, but they are full-sized for comfort and don’t let the scant layout mislead you. It has more functionality than it would seem to at first glance; the entire bottom row acts as dual function tap/hold keys, allowing the keyboard to shift layers on the fly.

This keyboard definitely has a a thoughtful layout, and we’re not just talking about the tap/shift functionality. We especially like the way the Pi Pico is tucked neatly underneath the main PCB, taking up very little room while exposing its USB connector between two standoffs for easy access without requiring an adapter, or wiring a separate plug.

If the Gherkin sounds familiar, we’ve seen it before as part of this lunchbox cyberdeck build, where the small size allowed it to take up impressively little room. The shifting might take a little getting used to, but it’s a clean design that uses full sized keys, so when it comes to small keyboards one could certainly do worse.

Custom Num Pad Does Double Duty As Macro Pad

Why buy a num pad or a macropad when you can build something new and beautiful, open source that bad boy, and be a hero to the community? We think that should be all the justification you ever need to build instead of buy, even if you think your thing is Just Another Keypad [JAnK] as [Clewsy] claims.

At first glance, JAnK appears to be a standard number pad with four macro keys across the top. But when you roll your own ‘board, all the keys are programmable. [Clewsy] took advantage of this by adding a second layer that’s accessible with (what else?) the Num Lock key. This switches JAnK over to 21-key macro pad mode.

[Clewsy] rolled their own PCB for this and used the venerable ATMega32u4 because of its HID and USB host capabilities. Every key is backlit, and these LEDs are driven by an MP3202 LED driver and PWM from the AVR. [Clewsy] was able to build a prototype by sawing the num pad off of a stainless steel key switch plate from another build, but eventually ordered JAnK its own custom, laser-cut, stainless steel plate. The lovely enclosure is made of spotted gum wood and an acrylic base.

Putting it all together proved to be a bit problematic. [Clewsy] soldered up the minimum viable components for testing and discovered that the ATMega’s VCC and GND pins were both shorted. This killed the AVR programmer, but not the chip itself, and [Clewsy] happened to have a spare. To add insult to injury, the Num Lock light didn’t work, but [Clewsy] was able to simply reverse the LED instead of ordering a new pile of boards. Check out the detailed write-up with code and tons of pictures over on [Clewsy]’s personal site.

One of the awesome things about this build is that [Clewsy] was able to re-use the code from macr0, which began life as a proof of concept for scanning key matrices, and retired to become a music and media controller.

Gdbdiff: Diff-ing A Real RP2040 MCU Against An Emulated MCU

What to do when developing an RP2040 emulator but validating the emulator instruction by instruction is a slow and tedious process? Why, automatically compare it against the real hardware if you’re [Uri Shaked], of course. This is the purpose of gdbdiff. This project uses the GDB remote serial protocol via OpenOCD to run test firmware step by step.

During a livestream (video linked via the above link), this allowed [Uri] to find a number of instruction bugs in the emulator this way. These issues involved issues such as incorrect flags in the APSR register and an edge case in the LSRS register. This gdbdiff livestream is part of an entire series of live-coding sessions during which [Uri] writes an RP2040 emulator from scratch.

We applaud [Uri] for creative thinking here, and assume that this way the livestream was probably more entertaining to watch than when doing instruction-level debugging purely by hand :)

New Part Day: RP2040 Chips In Single Unit Quantities

Since the launch of the Raspberry Pi Pico back in January the little board with its newly-designed RP2040 microcontroller has really caught the imagination of makers everywhere, and we have seen an extremely impressive array of projects using it. So far the RP2040 has only been available on a ready-made PCB module, but we have news today direct from Eben Upton himself that with around 600k units already shipped, single-unit sales of the chip are commencing via the network of Raspberry Pi Approved Resellers.

This news will doubtless result in a fresh explosion of clever projects using the chip, but perhaps more intriguingly it will inevitably result in its appearance at the heart of a new crop of niche products that go beyond simple clones of the Pico in different form factors. The special ingredient of those two PIO programmable state machines to take the load of repetitive tasks away from the cores raises it above being merely yet another microcontroller chip, and we look forward to that feature being at their heart.

The Broadcom systems-on-chip that power Raspberry Pi’s existing range of Linux-capable boards have famously remained unavailable on their own, meaning that this move to being a chip vendor breaks further new ground for the Cambridge-based company. It’s best not to think of it in terms of their entering into competition with the giants of the microcontroller market though, because a relative minnow such as the RP2040 will be of little immediate concern to the likes of Microchip, ST, or TI. A better comparison when evaluating the RP2040’s chances in the market is probably Parallax with their Propeller chip, in that here is a company with a very solid existing presence in the education and maker markets seeking to capitalise on that experience by providing a microcontroller with that niche in mind. We look forward to seeing where this will take them, and we’d hope to eventually see a family of RP2040-like chips with different package and on-board peripheral options.

Put APIs To Work Wth This ArduinoJson Walkthrough

One of the things this community is famous for is the degree to which people will pitch in to fill an obvious need. Look at the vast array of libraries available for Arduino as an example of how people are willing to devote their time to making difficult tasks easier, often for little more than a virtual pat on the back.

One level up from the library writers are those who go through the trouble of explaining how all these libraries work in real-world applications. [Brian Lough] recently rose to that challenge with a thorough explanation of the use of the ArduinoJSON library, a very useful but often confusing library that makes IoT projects easier.

The need for an ArduinoJSON explainer no knock on its author, [BenoĆ®t Blanchon], who has done excellent work documenting the library; it’s more of a realization that the nature of JSON itself means a library that works with it is going to be complex. [Brian]’s contribution here is sharing his insights into getting ArduinoJSON up and running in a real-world ESP32 example, and dealing with the potential pitfalls of parsing a human-readable text file that can be used to represent almost any data object using the limited resources of a microcontroller. Along with the basics, we found the warning about how pointers refer back to the dynamic JSON document object particularly helpful; the bit about using filters to winnow down a large data set was useful too.

Thanks to [Brian] for taking the time to put this valuable information out there. Here’s hoping this encourages others to share the wealth of hard-earned knowledge in a similarly clear and concise manner.

Continue reading “Put APIs To Work Wth This ArduinoJson Walkthrough”

ESP8266 Adds WiFi To A 433 MHz Weather Station

There’s no shortage of cheap weather stations on the market that pull in data from several wireless sensors running in the 433 to 900 MHz range and present you with a slick little desktop display, but that’s usually where the flow of information stops. Looking to bridge the gap and bring all that local climate data onto the Internet, [Jonathan Diamond] decided to reverse engineer how his weather station worked.

The first phase of this project involved an RTL-SDR receiver, GNURadio, and a sprinkling of Python. [Jonathan] was able to lock onto the signal and piece together the data packets that reported variables such as temperature, wind speed, and rainfall. Each one of these was a small puzzle in itself, and in the end, there’s still a few bits which he hasn’t quite figured out. But he at least had enough to move onto the next step.

Tapping into the radio module.

Now at this point, he could have pulled the data right out of the air with his RTL-SDR. But looking to push his skills to the next level, [Jonathan] decided to open up the base station and isolate its receiver. Since he already decoded the packets on the RF side, he knew exactly what he was looking for with his oscilloscope and logic analyzer. Once he was tapped into the feed coming from the radio, the final step was writing some code for the ESP8266 that could listen on the line, interpret the data packets, and push the resulting variables out over the network.

In this case, [Jonathan] decided to funnel all the data into Weather Underground by way of the Personal Weather Station API. This not only let him view the data through their web interface and smartphone application, but brought their hyperlocal forecasting technology into the mix at no extra charge. If you’re not interested in sharing your info with the public, it would be a trivial matter to change the firmware so the data is published to a local MQTT broker, or whatever else floats your proverbial boat.

If you’re really lucky, your own weather station may already have an ESP8266 onboard and is dumping all its collected data to the serial port. But if not, projects like this one that break down how to reverse engineer a wireless signal can be a great source of inspiration and guidance should you decide to try and crack the code.

Python Runs Through A Zombified 8-Bit AVR

As amazing as CircuitPython is, it hasn’t yet been ported to any 8-bit microcontrollers. [Chris Heo] was unsatisfied with his inability to use Python on his 8-bit ATmega4808 AVR, so he worked out a way to zombify it and bend it to his will using Python on his PC.

The trick to making this all work is the UPDI interface: a single-wire UART interface for programming and debugging Microchip’s newer 8-bit AVR microcontrollers. UPDI reaches deep into the microcontroller’s core, allowing you to stop and start execution of microcontroller code and access all of the onboard data and I/O. [Chris] realized this could be used to stop execution of any code running on the AVR and directly control the output pins using the pyupdi library. Since UPDI lets him modify the AVR’s I/O registers, he was also able to blink an LED and use the microcontrollers UART to send a message back to his PC without compiling a single line of code.

This may seem like an entirely unnecessary hack, but for devices too small or basic to have a JTAG interface for debugging this could be the best way to test and debug peripherals in an assembled circuit. We hope this catches on and would love to see how much of the chip can be controlled in this way. Maybe this will make it easy to experiment with the programmable logic that’s on some of the newer AVRs.