In case you haven’t heard, about a month ago MicroPython has celebrated its 11th birthday. I was lucky that I was able to start hacking with it soon after pyboards have shipped – the first tech talk I remember giving was about MicroPython, and that talk was how I got into the hackerspace I subsequently spent years in. Since then, MicroPython been a staple in my projects, workshops, and hacking forays.

If you’re friends with Python or you’re willing to learn, you might just enjoy it a lot too. What’s more, MicroPython is an invaluable addition to a hacker’s toolkit, and I’d like to show you why.

Hacking At Keypress Speed

Got a MicroPython-capable chip? Chances are, MicroPython will serve you well in a number of ways that you wouldn’t expect. Here’s a shining example of what you can do. Flash MicroPython onto your board – I’ll use a RP2040 board like a Pi Pico. For a Pico, connect an I2C device to your board with SDA on pin 0 and SCL on pin 1, open a serial terminal of your choice and type this in:

>>> from machine import I2C, Pin
>>> i2c = I2C(0, sda=Pin(0), scl=Pin(1))
>>> i2c.scan()

This interactivity is known as REPL – Read, Evaluate, Print, Loop. The REPL alone makes MicroPython amazing for board bringup, building devices quickly, reverse-engineering, debugging device library problems and code, prototyping code snippets, writing test code and a good few other things. You can explore your MCU and its peripherals at lightning speed, from inside the MCU.

When I get a new I2C device to play with, the first thing I tend to do is wiring it up to a MicroPython-powered board, and poking at its registers. It’s as simple as this:

>>> for i in range(16):
>>>     # read out registers 0-15
>>>     # print "address value" for each
>>>     print(hex(i), i2c.readfrom_mem(0x22, i))
>>> # write something to a second (0x01) register
>>> i2c.writeto_mem(0x22, 0x01, bytes([0x01]) )

That i2c.scan() line alone replaces an I2C scanner program you’d otherwise have to upload into your MCU of choice, and you can run it within three to five seconds. Got Micropython running? Use serial terminal, Ctrl+C, and that will drop you into a REPL, just type i2c.scan() and press Enter. What’s more, you can inspect your code’s variables from the REPL, and if you structure your code well, even restart your code from where it left off! This is simply amazing for debugging code crashes, rare problems, and bugs like “it stops running after 20 days of uptime”. In many important ways, this removes the need for a debugger – you can now use your MCU to debug your code from the inside.

Oh, again, that i2c.scan()? You can quickly modify it if you need to add features on the fly. Want addresses printed in hex? (hex(addr) for addr in i2c.scan()). Want to scan your bus while you’re poking your cabling looking for a faulty wire? Put the scan into a while True: and Ctrl+C when you’re done. When using a typical compiled language, this sort of tinkering requires an edit-compile-flash-connect-repeat cycle, taking about a dozen seconds each time you make a tiny change. MicroPython lets you hack at the speed of your keyboard typing. Confused the pins? Press the `up` button, edit the line and run the i2c = line anew.

To be clear, all of code is running on your microcontroller, you just type it into your chip’s RAM and it is executed by your MCU. Here’s how you check GPIOs on your Pi Pico, in case you’re worried that some of them have burnt out:

>>> from machine import Pin
>>> from time import sleep
>>> pin_nums = range(30) # 0 to 29
>>> # all pins by default - remove the ones connected to something else if needed
>>> pins = [Pin(num, Pin.OUT) for num in pin_nums]
>>> 
>>> while True:
>>>   # turn all pins on
>>>   for i in range(len(pins)):
>>>     pins[i].value(True)
>>>   sleep(1)
>>>   # turn all pins off
>>>   for i in range(len(pins)):
>>>     pins[i].value(False)
>>>   sleep(1)
>>>   # probe each pin with your multimeter and check that each pin changes its state

There’s many things that make MicroPython a killer interpreter for your MCU. It’s not just the hardware abstraction layer (HAL), but it’s also the HAL because moving your code from board to board is generally as simple as changing pin definitions. But it’s all the other libraries that you get for free that make Python awesome on a microcontroller.

Batteries Included

It really is about the batteries – all the libraries that the stock interpreter brings you, and many more that you can download. Only an import away are time, socket, json, requests, select, re and many more, and overwhelmingly, they work the same as CPython. You can do the same r = requests.get("https://retro.hackaday.com"); print(r.text)[:1024] as you would do on desktop Python, as long as you got a network connection going on. There will be a few changes – for instance, time.time() is an integer, not a float, so if you need to keep track of time very granularly, there are different functions you can use.

Say, you want to parse JSON from a web endpoint. If you’re doing that in an Arduino environment, chances are, you will be limited in what you can do, and you will get triangle bracket errors if you mis-use the JSON library constructs because somehow the library uses templates; runtime error messages are up to you to implement. If you parse JSON on MicroPython and you expect a dict but get a list in runtime, it prints a readable error message. If you run out of memory, you get a very readable MemoryError printed out, you can expect it and protect yourself from it, even fix things from REPL and re-run the code if needed.

The user-supplied code is pretty good, too. If you want PIO or USB-HID on the RP2040, or ESP-CPU-specific functions on the ESP family, they are exposed in handy libraries. If you want a library to drive a display, it likely already has been implemented by someone and put on GitHub. And, if that doesn’t exist, you port one from Arduino and publish it; chances are, it will be shorter and easier to read. Of course, MicroPython has problems. In fact, I’ve encountered a good few problems myself, and I would be amiss not mentioning them.

Mind The Scope

In my experience, the single biggest problem with MicroPython is that writing out `MicroPython` requires more of my attention span than I can afford. I personally shorten it to uPy or just upy, informally. Another problem is that the new, modernized MicroPython logo has no sources or high-res images available, so I can’t print my own stickers of it, and MicroPython didn’t visit FOSDEM this year, so I couldn’t replenish my sticker stock.

On a more serious note, MicroPython as a language has a wide scope of where you can use it; sometimes, it won’t work for you. An ATMega328P can’t handle it – but an ESP8266 or ESP32 will easily, without a worry in the world, and you get WiFi for free. If you want to exactly control what your hardware does, counting clock cycles or hitting performance issues, MicroPython might not work for you – unless you write some Viper code.

If you want to have an extremely-low-power MCU that runs off something like energy harvesting, MicroPython might not work – probably. If you need your code run instantly once your MCU gets power, mind the interpreter takes a small bit of time to initialize – about one second, in my experience. If you want to do HDMI output on a RP2040, perhaps stick to C – though you can still do PIO code, there are some nice libraries for it.

Some amount of clock cycles will be spent on niceties that Python brings. Need more performance? There are things you can do. For instance, if you have a color display connected over SPI and you want to reduce frame rendering time, you might want to drop down to C, but you don’t have to ditch MicroPython – just put more of your intensive code into C-written device drivers or modules you compile, and, prototype it in MicroPython before you write it.

As Seen On Hackaday

If you’ve followed the USB-C PD talking series, you must’ve seen that the code was written in MicroPython, and I’ve added features like PD sniffing, DisplayPort handling and PSU mode as if effortlessly; it was just that easy to add them and more. I started with the REPL, a FUSB302 connected to a RP2040, poking at registers and reading the datasheet, and while I needed outside help, the REPL work was so so much fun!

There’s something immensely satisfying about poking at a piece of technology interactively and trying to squeeze features out of it, much more if it ends up working, which it didn’t, but it did many other times! I’ve been hacking on that PD stack, and now I’m slowly reformatting it from a bundle of functions into object-based code – Python makes that a breeze.

Remember the Sony Vaio board? Its EC (embedded controller) is a RP2040, always powered on as long as batteries are inserted, and it’s going to be running MicroPython. The EC tasks include power management, being a HID over I2C peripheral, button and LED control, and possibly forwarding keyboard and trackpoint events to save a USB port from the second RP2040, which will run QMK and server as a keyboard controller. MicroPython allows me to make the firmware quickly, adorn it with a dozen features while I do it, and keep the codebase expandable on a whim. The firmware implementation will be a fun journey, and I hope I can tell about it at some point.

Have you used MicroPython in your projects? What did it bring to your party?

Welcome to the Design Review Central! [VE3SVF] sends us their board, and it’s a HAB (High Altitude Balloon) tracker board. It’s got the venerable ATMega28P on it, a LoRa modem and a GPS module, and it can be powered from a LiIon battery. Stick this board with its battery onto a high-altitude balloon, have it wake up and transmit your coordinates every once in a while, and eventually you’ll find it in a field – if you’re lucky. Oherwise, it will get stuck hanging on a tree branch, and you will have to use a quadcopter to try and get it down, and then, in all likelihood, a second quadcopter so that you can free the first one. Or go get a long ladder.

The ATMega328P is tried and true, and while it’s been rising in price, it’s still available – with even an updated version that sports a few more peripherals; most importantly, you’re sure to find a 328P in your drawer, if not multiple. Apart from that, the board uses two modules from a Chinese manufacturer, G-Nice, for both GPS and Lora. Both of these modules are cheap, making this tracker all that more accessible; I could easily see this project being sold as a “build your own beacon” kit!

Let’s make it maybe a little nicer, maybe a little cheaper, and maybe decrease the power consumption a tad along the way. We’ll use some of the old tricks, a few new ones, and talk about project-specific aspects that might be easy to miss.

The Low Hanging Fruit

This board has four layers, which is nice because you get more ground and more routing space for a tiny price increase these days. This board doesn’t add fills on inner layers, but that is an easy fix – just select one of the GND power planes and tick the In1/In2.Cu boxes in their settings. Another thing to tweak in zone settings is zone clearance and minimum thickness – default KiCad clearances are way too conservative, setting them to something like 0.2 mm / 0.2 mm is a good idea. That improves ground connectivity, and also lets us get rid of ground tracks that would otherwise be necessary to bring ground to different connectors.

The inner layers have ground, and ground on all layers can reach further, too. That said, the inner layers benefit from being completely free – that’s when you get the best return current flow. Remember, each track, whether signal or power, needs its ground return path, and if you don’t provide a direct clean one, electricity will find a way. That, in turn, results in noise, both received and emitted, as well as possible instabilities.

In particular, the ISP flashing header had a lot of low-hanging fruit; tracks that were pulled on inner layers but could as well go on top/bottom layers. Many tracks could be snaked between GPS and LoRa module pads, too – the gaps are wide enough, that even a 0.2 mm track feels comfortable in there, and you could probably pull two if you dropped down to 0.15 mm, which is still safe with most fabs.

And, after a dozen minutes of work, the inner layers are free. A surprising amount of space could be found – for instance, the three DIO tracks nicely went along the right edge of the board. More importantly, capacitors were moved closer to where they work best. In particular, the AREF capacitor is two vias and one long inner track apart, which won’t make for good analog decoupling. That did require moving the ATMega a bit upwards, but a judicious application of Del and Shift+Del on tracks, as well as some track dragging, made that move go quickly.

I could talk about component size choices, but they’re not meaningfully interfering with routing on the board – even the opposite, having one of the diodes be 1206 helps me avoid some vias. On the other hand, rotating the battery divider resistors and power regulators 180 degrees resulted in some good routing space freed up. And, looking at the board, the ATMega328P routing could perhaps use being rotated one turn clockwise, too. That’d make SPI routing cleaner, power tracks and analog pins shorter, and let us put capacitors at the sides, at the low low cost of having GPIO pins snake around a bit. However, here, the benefits aren’t necessarily as clear-cut as in previous articles; instead, it’s a time vs niceness tradeoff.

The Chip Gets Rotated, But Not Necessarily

Here, a conundrum. We could spend maybe a dozen more minutes and rotate the chip, or leave it be? Is the board going to be slightly nicer? Yes. Is this necessary? No. If you want to just order the board and go, it’s completely fair for you to press order and leave improvements of this grade for rev2. On the other hand, if the itch to improve your board is bad enough that the time investment doesn’t scare you out of it, give in and see yourself become better at PCB design. Worked for me.

There are hidden problems for such small redesigns, though. Remember, a redesign might have you reinstate a problem that you’ve successfully avoided with the original iteration, or, it can quickly become infeasible. I’ve had it happen, where a redesign that intended to add features and reduce complexity has become counter-productive midway through, so, I’ve had to stop myself from continuing and just order the board already. You’ll learn to keep track of these, but it does take keeping it in mind. Keep your Ctrl+Z’s ready, keep a copy of the files, or a Git commit, if you are doing something fundamental, and be ready to get a lesson in letting go.

I ended up rotating the chip, and the board did indeed become a bit nicer, but in ways that don’t solve any pressing problems. By the way, have you noticed something this board has done really well from the start? That’s component placement. The ways the LoRa module, GPS module, ATMega328P and the headers are positioned, I wouldn’t change anything about them. Maybe move the pin headers onto a 2.5 4mm grid so that you could expand this board with a perfboard if needed, but that one isn’t a must – this is a low weight board, after all, the headers are more for debugging than anything else.

Last Thoughts: Inner Layers And Antenna Choice

If you have internal layers, use them for ground or power fills, so that power and return currents can flow unrestricted. This is going to reduce both radiated and received emissions, as well as make power rails smoother, which feels mighty helpful considering this design has two radios on it and the GPS radio has a passive antenna.

Also, some fabs don’t want empty inner layers. Last year, JLCPCB started refusing boards with inner or outer layers more than 30% full, in what’s presumably an attempt to decrease the etching process costs, causing some people to redesign perfectly working PCBs with little notice. Combine this with a recent documentation overhaul that just so happened to turn some previously free options into paid ones, and if I were to guess, they are no longer able to keep running at a loss as much as they did, so, the age of golden offers at JLCPCB might soon to be over.

Our improvements ended up providing more than enough copper on top and bottom layers, that you could possibly switch this board to two-layer; again, cheaper ordering, possibly quicker manufacturing time, possibly cheaper PCBA. Isn’t a requirement, but it is nice when you can do it. If you are to keep the two extra layers, remember that on-board antennas need keepouts at least for a wide patch under them, if not for a good amount of space around them, and the keepout has to be on all layers. No tracks, no fills, no copper, do not pass go, do not collect 200.

Thicker tracks for power paths are good whenever you can afford them – and this board has plenty of space! I personally usually add them in last, and it’s not a problem here, but it’s most certainly a smarter decision to draw them thick first so that you don’t have to do a re-layout later.

It also does feel like you could consider an active antenna here. For a high-altitude balloon, sure, you’re way way more likely to get a fix and you’ve got a whole lot more time to do it, but I would guess improving your chances is worthwhile. Plus, I don’t know much about G-Nice’s modules, still yet to try out the one I purchased last year – it might be that this module is perfectly okay, but it concerns me these are meant to be footprint-compatible drop-in replacements for well-established company modules, with this specific module borrowing an U-Blox footprint, and as such, I don’t know how much to expect. An active antenna adds a fair of weight and size footprint, and it might be that everyone’s flying with passive antennas no worries, so I might be completely out of my zone here. Whichever is the case, I would appreciate input!

As usual, if you would like a design review for your board, submit a tip to us with [design review] in the title, linking to your board files. KiCad design files strongly preferred, both repository-stored files (GitHub/GitLab/etc) and shady Google Drive/Dropbox/etc .zip links are accepted.

[Sophia Dai] brings us a project you will definitely like if you’re tired of traditional peripherals like a typical keyboard and mouse combo. This is ErgO, a smart ring you can build out of a few commonly available breakouts, and it keeps a large number of features within a finger’s reach. The project has got an IMU, a Pimoroni trackball, and a good few buttons to perform actions or switch modes, and it’s powered by a tiny Bluetooth-enabled devboard so it can seamlessly perform HID device duty.

While the hardware itself appears to be in a relatively early state, there’s no shortage of features, and the whole experience looks quite polished. Want to lay back in your chair yet keep scrolling the web, clicking through links as you go? This ring lets you do that, no need to hold your mouse anymore, and you can even use it while exercising. Want to do some quick text editing on the fly? That’s also available; the ErgO is designed to be used for day to day tasks, and the UX is thought out well. Want to use it with more than just your computer? There is a device switching feature. The build instructions are quite respectable, too – you can absolutely build one like this yourself, just get a few breakouts, a small battery, some 3D printed parts, and find an evening to solder them all together. All code is on GitHub, just like you would expect from a hack well done.

Looking for a different sort of ring? We’ve recently featured a hackable cheap smart ring usable for fitness tracking – this one is a product that’s still being reverse-engineered, but it’s alright if you’re okay with only having an accelerometer and a few optical sensors.

There’s no shortage of USB-C chargers in all sorts of configurations, but sometimes, you simply need a few more charging ports on the go, and you got a single one. Well then, check out [bluepylons]’s USB-C splitter, which takes a single USB-C 5V/3A port and splits it into three 5V/1A plugs, wonderful for charging a good few devices on the go!

This adapter does things right – it actually checks that 3A is provided, with just a comparator, and uses that to switch power to the three outputs, correctly signalling to the consumer devices that they may consume about 1A from the plugs. This hack’s documentation is super considerate – you get detailed instructions on how to reproduce it, every nuance you might want to keep in mind, and even different case options depending on whether you want to pot the case or instead use a thermal pad for a specific component which might have to dissipate some heat during operation!

This hack has been documented with notable care for whoever might want to walk the journey of building one for themselves, so if you ever need a splitter, this one is a wonderful weekend project you are sure to complete. Wonder what kind of project would be a polar opposite, but in all the best ways? Why, this 2kW USB-PD PSU, most certainly.

If you’ve ever bought a modchip that adds features to your game console, you might have noticed sanded-off IC markings, epoxy blobs, or just obscure chips with unknown source code. It’s ironic – these modchips are a shining example of hacking, and yet they don’t represent hacking culture one bit. Usually, they are more of a black box than the console they’re tapping into. This problem has plagued the original XBOX hacking community, having them rely on inconsistent suppliers of obscure boards that would regularly fall off the radar as each crucial part went to end of life. Now, a group of hackers have come up with a solution, and [Macho Nacho Productions] on YouTube tells us its story – it’s an open-source modchip with an open firmware, ModXO.

Like many modern modchips and adapters, ModXO is based on an RP2040, and it’s got a lot of potential – it already works for feeding a BIOS to your console, it’s quite easy to install, and it’s only going to get better. [Macho Nacho Productions] shows us the modchip install process in the video, tells us about the hackers involved, and gives us a sneak peek at the upcoming features, including, possibly, support for the Prometheos project that equips your Xbox with an entire service menu. Plus, with open-source firmware and hardware, you can add tons more flashy and useful stuff, like small LCD/OLED screens for status display and LED strips of all sorts!

If you’re looking to add a modchip to your OG XBOX, it looks like the proprietary options aren’t much worth considering anymore. XBOX hacking has a strong community behind it for historical reasons and has spawned entire projects like XBMC that outgrew the community. There’s even an amazing book about how its security got hacked. If you would like to read it, it’s free and worth your time. As for open-source modchips, they rule, and it’s not the first one we see [Macho Nacho Productions] tell us about – here’s an open GameCube modchip that shook the scene, also with a RP2040!

Did you know you can get a “smart bed” that tracks your sleep, breathing, heart rate, and even regulates the temperature of the mattress? No? Well, you can get root access to one, too, as [Dillan] shows, and if you’re lucky, find a phone-home backdoor-like connection. The backstory to this hack is pretty interesting, too!

You see, a Sleep Number bed requires a network connection for its smart features, with no local option offered. Not to worry — [Dillan] wrote a Homebridge plugin that’d talk the cloud API, so you could at least meaningfully work with the bed data. However, the plugin got popular, Sleep Number didn’t expect the API to be that popular. When they discovered the plugin, they asked that it be shut down. Tech-inclined customers are not to be discouraged, of course.

Taking a closer look at the hardware, [Dillan] found a UART connection and dumped the flash, then wrote an extensive tutorial on how to tap into your bed’s controller, which runs Linux, and add a service you can use locally to query bed data and control the bed – just like it should have been from the beginning. Aside from that, he’s found a way to connect this hub to a network without using Sleep Number’s tools, enabling fully featured third-party use – something that the company doesn’t seem to like. Another thing he’s found is a reverse SSH tunnel back into the Sleep Number network.

Now, it can be reasonable to have a phone-home tunnel, but that doesn’t mean you want it in your personal network, and it does expose a threat surface that might be exploited in the future, which is why you might want to know about it. Perhaps you’d like to use Bluetooth instead of WiFi. Having this local option is good for several reasons. For example, having your smart devices rely on the manufacturer’s server is a practice that regularly results in perma-bricked smart devices, though we’ve been seeing some examples of dedicated hackers bringing devices back to life. Thanks to this hack, once Sleep Number shutters, is bought out, or just wants to move on, their customers won’t be left with a suddenly dumbed-down bed they can no longer control.

[Header image courtesy of Sleep Number]

There are so many new cool MCUs coming out, and you want to play with all of them, but, initially, they tend to be accessible as bare chips. Devboards might be hard to get, not expose everything, or carry a premium price. [Willmore] has faced this problem with an assortment of new WCH-made MCUs, and brings us all a solution – a universal board for TSSOP20-packaged MCUs, breadboard-friendly and adaptable to any pinout with only a few jumpers on the underside.

The board brings you everything you might want from a typical MCU breakout – an onboard 3.3V regulator, USB series resistors, a 1.5K pullup, decoupling capacitors, and a USB-C port. All GPIOs are broken out, and there’s a separate header you can wire up for all your SWD/UART/USB/whatever needs – just use the “patch panel” on the bottom of the board and pick the test points you want to join. [Willmore] has used these boards for the CH32Vxxx family, and they could, no doubt, be used for more – solder your MCU on, go through the pin table in the datasheet, do a little point-to-point wiring, and you get a pretty functional development board.

Everything is open-source – order a few of these boards from your fab of choice, and you won’t ever worry about a breakout for a TSSOP20 MCU or anything that would fit the same footprint. It could even be used in a pinch for something like an I2C GPIO expander. This is also a technique worth keeping in mind – a step above the generic footprint breakouts. Looking for more universal breakouts to keep? Here’s one for generic LCD/OLED panel breakouts.

If you’re pairing a tiny Linux computer to a few peripherals — perhaps you’re building a reasonably custom Pi-powered device — it’s rightfully tempting to use something like an STM32 for all your low-level tasks, from power management to reading keyboard events.

Now, in case you were wondering how to tie the two together, consider HID over I2C, it’s a standardized protocol with wide software and peripheral support, easily implementable and low-power. What’s more, [benedekkupper] gives you an example STM32 project with a detailed explanation on how you too can benefit from the protocol.

There are several cool things about this project. For a start, its code is generic enough that it will port across the entire STM32 lineup nicely. Just change the pin definitions as needed, compile it, flash it onto your devboard and experiment away. Need to change the descriptors? The hid-rdf library used lets you define a custom descriptor super easily, none of that building a descriptor from scratch stuff, and it even does compile-time verification of the descriptor!

The project has been tested with a Raspberry Pi 400, and [benedekkupper] links a tutorial on quickly adding your I2C-HID device on an Linux platform; all you need is DeviceTree support. Wondering what’s possible with HID? We’ve seen hackers play with HID aplenty here, and hacking on the HID standard isn’t just for building keyboards. It can let you automate your smartphone, reuse a laptop touchpad or even a sizeable Wacom input surface, liberate extra buttons on gamepads, or build your own touchscreen display.

While we are used to USB WiFi adapters, embedded devices typically use SDIO WiFi cards, and for good reasons – they’re way more low-power, don’t take up a USB port, don’t require a power-sipping USB hub, and the SDIO interface is widely available. However, SDIO cards and modules tend to be obscure and proprietary beyond reason. Enter ESP-Hosted – Espressif’s firmware and driver combination for ESP32 (press release)(GitHub), making your ESP32 into a WiFi module for either your Linux computer (ESP-Hosted-NG) or MCU (ESP-Hosted-FG). In particular, ESP-Hosted-NG his turns your SPI- or SDIO-connected ESP32 (including -S2/S3/C2/C3/C6 into a WiFi card, quite speedy and natively supported by the Linux network stack, as opposed to something like an AT command mode.

We’ve seen this done with ESP8266 before – repurposing an ESP8089 driver from sources found online, making an ESP8266 into a $2 WiFi adapter for something like a Pi. The ESP-Hosted project is Espressif-supported, and it works on the entire ESP32 lineup, through an SDIO or even SPI interface! It supports 802.11b/g/n and even Bluetooth, up to BLE5, either over an extra UART channel or the same SDIO/SPI channel; you can even get BT audio over I2S. If you have an SPI/SDIO port free and an ESP32 module handy, this might just be the perfect WiFi card for your Linux project!

There are some limitations – for instance, you can’t do AP mode in the NG (Linux-compatible) version. Also, part of the firmware has blobs in it, but a lot of the firmware and all of the driver are modifiable in case you need your ESP32 to do even more than Espressif has coded in – this is not fully open-source firmware, but it’s definitely way more than the Broadcom’s proprietary onboard Raspberry Pi WiFi chip. There’s plenty of documentation, and even some fun features like raw transport layer access. Also, of note is that this project supports ESP32-C6, which means you can equip your project with a RISC-V-based WiFi adapter.

Title image from [zhichunlee].

This article was prompted by a friend of mine asking for help on a board with an ESP32 heart. The board outputs 2.1 V instead of 3.3 V, and it doesn’t seem like incorrectly calculated feedback resistors are to blame – let’s take a look at the layout. Then, let’s also take a look at a recently sent in design review entry, based on an IC that looks perfect for all your portable Raspberry Pi needs!

What Could Have Gone Wrong?

Here’s the board in all its two-layer glory. This is the kind of board you can use to drive 5 V or 12 V Neopixel strips with a firmware like WLED – exactly the kind of gadget you’ll want to use for LED strip experiments! 3.3 V power is provided by a Texas Instruments TPS54308 IC, and it’s the one misfiring, so let’s take a look.

The design has an ESP32 on the opposite side of the switching regulator. For review purposes, let’s pull the regulator circuit out – disable all front layers (copper, silk, mask, courtyard and paste), hide vias, then box select the regulator circuit and move it out. I’ve also added net labels to the circuit – here’s a screenshot.

There are things done right here, for sure, and a few things that could be the culprit in improper regulation. If you want hints, you can see TPS54308 datasheet, page 22, for layout recommendations. Both SW and FB nodes are pretty long, and the FB trace goes right next to VOUT – before regulation.

Furthermore, from the pinout and also the layout recommendations, it appears this regulator is designed in a way that all switching circuitry can be. Yet, this design has the inductor go all the way to supposedly sensitive side. Thankfully, this is easy to fix.

Refresher – FB and SW traces have to be as short as possible, inductor as close to SW as possible, and the VOUT to FB connection can be a separate tracks on the other layer. With that in mind, let’s move the inductor to the other side of the regulator, move the FB resistors to the FB pin, and see how far we get.

My Take Versus TI’s Recommendation

This is my take. FB resistors moved to one side, switching components to the other, VOUT track on another layer. Add capacitors and vias as necessary, and pull tracks under components to get extra ground connections if needed. Of course, ideally, SW would be a copper polygon, and so would be VOUT. I’m also showing how EN could be pulled out, in case you needed that – in this particular schematic, EN can be safely left floating, but most regulators will want you to pull it either to VIN or to GND.

Since this is a TI chip, it also has a diagram for the layout recommendation! Let’s take a look how far off the mark we are, and it appears we aren’t that far. Curiously, it wants us to put SW onto another layer. Having switching current pass through extra inductance doesn’t sit right with me, personally, but my guess is that they want to minimize switching current flowing under the regulator, as the recommendation suggests.

Another part that’s curious to me, is a suggestion for a Kelvin connection for the FB net’s GND pin. TI also publishes data for evaluation boards, and the TPS54308 has such a board indeed. Seeing on the page 13 of the evaluation board datasheet, I’m not quite seeing a Kelvin connection, unless Kelvin is the name of the engineer involved in designing the board. I do see that GND is tapped with a via far away from the area where switching happens, so it might just be that.

At this point, I’m curious whether my take is a dealbreaker, but since TI’s recommendations are available, I might just end up implementing exactly that and sending the files back. So, we take this circuit, implant it back into the board, order a new revision, and keep our fingers crossed.

A Pi-suited UPS, On A Stamp

A week ago, [Lukilukeskywalker] has shared a board with us, asking for a design review. The board is a stamp that houses a LTC4040 chip, and the chip itself is a treat. It takes 5 V, outputs 5 V, and when connected, it generates 5 V from a battery. It supports both regular LiIon, can do up to 2.5 A, and appears to be a perfect option if you want to power a Raspberry Pi or any other 5 V-powered SBC on the go.

There are a few small nits to pick on this board. For instance, the connector for the battery is JST-SH, 3-pin, with one pin for BATT+. 2.5 A at 5 V means 12.5 W means up to 4 A at 3.5 V battery level, which might just melt a JST-SH connector or the gauge of wire you can attach to a JST-SH-sized metal contact. However, it’s switching regulator time, so let’s take a look at that specifically.

Here’s another thing you might notice immediately – lack of ground path from the IC’s ground connections, all the way under the switching path. In particular, the switching path is broken by a few traces, and it doesn’t appear that these traces must be there! Page 22 in the LTC4040 datasheet, which lists the layout recommendations, also stresses upon this, elaborating that “High frequency currents in the hot loop tend to flow along a mirror path on the ground plane which is directly beneath the incident path on the top plane of the board”.

Well, there are only two tracks that really interrupt the switching path above them, and both could be moved to the left. One of them is for a resistor that sets the charging current limit, and another goes to a castellated pad. Moving the latter is going to break the symmetry, but remember – it’s okay for a stamp to be asymmetric, that helps you ensure it’s mounted on your board correctly!

Sadly, while Linear Tech makes fancy tech, their evaluation board data isn’t as available as TI’s – there’s a PDF with schematics, but no layout data I could find. However, comparing to the pictures, you can see that the general layout of the switching area is correct, our hacker correctly uses polygons, the feedback circuit is pretty nice – it’s just these two tracks that are a bit uncouth when it comes to the switching regulator part of it. As for reviewing the rest of the board, you can read this article!

Towards A Powerful Future

Got switching regulator designs that didn’t quite work right when you put them to test, or that you’re yet to order and feel cautious about? Show them to us down below in the comments, and let’s take a look; your circuits deserve to operate at their best capacity possible.

And, as usual, if you would like a design review for your board, submit a tip to us with [design review] in the title, linking to your board files. KiCad design files strongly preferred, both repository-stored files (GitHub/GitLab/etc) and shady Google Drive/Dropbox/etc .zip links are accepted.

We’ve seen prolific firmware hacker [Aaron Christophel] tackle smart devices of all sorts, and he never fails to deliver. This time, he’s exploring a device that seems like it could have come from the pages of a Cyberpunk RPG manual — a shiny chrome Bluetooth Low Energy (BLE) smart ring that’s packed with sensors, is reasonably hacker friendly, and is currently selling for as little as $20.

The ring’s structure is simple — the outside is polished anodized metal, with the electronics and battery carefully laid out along the inside surface, complete with a magnetic charging port. It has a BLE-enabled MCU, a heartrate sensor, and an accelerometer. It’s not much, but you can do a lot with it, from the usual exercise and sleep tracking, to a tap-sensitive interface for anything you want to control from the palm of your hand. In the video’s comments, someone noted how a custom firmware for the ring could be used to detect seizures; a perfect example of how hacking such gadgets can bring someone a brighter future.

The ring manufacturer’s website provides firmware update images, and it turns out, you can upload your own firmware onto it over-the-air through BLE. There’s no signing, no encryption — this is a dream device for your purposes. Even better, the MCU is somewhat well-known. There’s an SDK, for a start, and a datasheet which describes all you would want to know, save for perhaps the tastiest features. It’s got 200 K of RAM, 512 K of flash, BLE library already in ROM, this ring gives you a lot to wield for how little space it all takes up. You can even get access to the chip’s Serial Wire Debug (SWD) pads, though you’ve got to scrape away some epoxy first.

As we’ve seen in the past, once [Aaron] starts hacking on these sort of devices, their popularity tends to skyrocket. We’d recommend ordering a couple now before sellers get wise and start raising prices. While we’ve seen hackers build their own smart rings before, it’s tricky business, and the end results usually have very limited capability. The potential for creating our own firmware for such an affordable and capable device is very exciting — watch this space!

We thank [linalinn] for sharing this with us!

Some hacks are implemented well enough that they can imitate involved and bespoke parts with barely any tools. [CodeName X]’s Thinkpad X1 Tablet Keyboard to USB adapter is one such hack – it let’s one reuse, with nothing more than a 3D printed part and a spare USB cable, a keyboard intended for the Thinkpad X1 Tablet (2016 or 2017).

The issue is, this keyboard connects through pogo pins and holds onto the tablet by magnets, so naturally, you’d expect reusing it to involve a custom PCB. Do not fret – our hacker’s take on this only needs aluminum foil and two small circular magnets, pressing the foil into the pins with the help of the printed part, having the USB cable pins make contact with the foil pads thanks to nicely laid out wire channels in the adapter. If you want to learn more, just watch the video embedded below.

Of course, this kind of adapter will apply to other similar keyboards too — there’s no shortage of tablets from last decade that had snap-on magnetic keyboards. But watch out; some will need 3.3V, and quite a few of them will use I2C-HID, which would require a MCU-equipped adapter like this wonderful Wacom rebuild did. Not to worry, as we’ve shown you the ropes of I2C-HID hacking.

[endes0] has been hacking with USB HID recently, and a Logitech M185 mouse’s USB receiver has fallen into their hands. Unlike many Logitech mice, this one doesn’t include a Unifying receiver, though it’s capable of pairing to one. Instead, it comes with a pre-paired CU0019 receiver that, it turns out, is based on a fairly obscure TC32 chipset by Telink, the kind we’ve seen in cheap smart wristbands. If you’re dealing with a similarly obscure MCU, how do you even proceed?

In this case, GitHub had a good few tools developed by other hackers earlier — a Ghidra integration, and a tool for working with the MCU using a USB-UART and a single resistor. Unfortunately, dumping memory through the MCU’s interface was unreliable and frustrating. So it was time to celebrate when fuzzing the HID endpoints uncovered a memory dump exploit, with the memory dumper code helpfully shared in the blog post.

From a memory dump, the exploration truly began — [endes0] uncovers a fair bit of dongle’s inner workings, including a guess on which project it was based on, and even a command putting the dongle into a debug mode where a TC32-compatible debugger puts this dongle fully under your control.

Yet another hands-on course on Ghidra, and a wonderful primer on mouse dongle hacking – after all, if you treat your mouse’s dongle as a development platform, you can easily do things like controlling a small quadcopter, or pair the dongle with a SNES gamepad, or build a nifty wearable.

Do you have a 5 V device you want to run 24/7, no matter whether you have electricity? Not to worry – Linear Technology has made a perfect IC for you, the LTC4040; with the perfect assortment of features, except perhaps for the hefty price tag.

[Lukilukeskywalker] has shared a PCB for us to review – a LTC4040-based stamp you can drop onto your PCB whenever you want a LTC4040 design. It’s a really nice module to see designed – things like LiFePO4 support make this IC a perfect solution for many hacker usecases. For instance, are you designing a custom Pi HAT? Drop this module to give your HAT the UPS capability for barely any PCB effort. if your Pi or any other single-board computer needs just a little bit of custom sauce, this module spices it up alright!

This one is a well-designed module! I almost feel like producing a couple of these, just to make sure I have them handy. If you like the LTC4040, given its numerous features and all, this is also not the only board in town – here’s yet another LTC4040 board that has two 18650 holders, and referencing its PCB design will help me today in this review, you can take a look at it too!

Now, having looked at this PCB for a fair bit, it has a few things that we really do want to take care of. Part of today’s review will be connector selection, another would be the module form-factor, some layout, and some suggestions on sizing the passives – the rows of 1206 components are pretty, but they’re also potentially a problem. Let’s waste no time and delve in.

Battery Wireup And Formfactor

The battery connector uses JST-SH, one pin for VBAT and one for GND. The problem with this is that the module is capable of 2.5 A at 5 V = 12 W. At 3.6 V, that’s 4 A if not more and JST-SH is only rated for 1 A per pin. Using this module with a battery as-intended will melt things. You could add a bigger connector like the standard JST-PH, but that’d increase the module size, and my assessment is that this board doesn’t have to be larger than it already is.

Thankfully, this is an open-source module, so we can change its pinout easily enough, adding pins for the battery into the mix. Currently, this board feels breadboardable, but it isn’t quite – it’s pretty wide, so it will take two breadboards to handle, and a breadboard would also probably be disappointed with the pin amount required. With that in mind, adding pins at the top looks convenient enough.

In general, shuffling the pins around will help a fair bit. My hunch is to make the module’s castellations asymmetric, say, do 7-5-5-5 – one side with seven pins, three sides with five pins. It might not look as perfect, but what’s important is that it will be way way harder to mount incorrectly, something I’ve done with a module of my own design – that was not fun to fix. If you are worried about having enough pins to fill the resulting 22-pin combination, it’s always great to just add GND, doubly so for a power-related module!

Adding more castellations also helps us shuffle the pinout around, freeing up the routing – let’s go through the pins and see what that could help with.

Pinout Changes

The schematic is seriously nice looking – every single block is nicely framed and has its description listed neatly. Comparing it with reference schematic, it looks pretty good!

There’s a few nits to pick. For instance, BST_OFF and CHG_OFF need to be grounded for the IC to work – datasheet page 10. You could ground them through a resistor and pull them onto a castellation, but you can’t leave them floating. This is not easy to notice, however, unless you go through the pins one by one and recheck their wiring; I noticed it because I was looking at the board, saw two unconnected pins and decided to check.

My hunch is that, first, all the pins were given power names, and then two of them were missed as not connected anywhere, which is an understandable mistake to make.

Let’s keep with the schematic style – add two more connectors, one 5-pin and one 7-pin, rearrange the pinout, and keep them in their own nicely delineated area. The 7-pin connector gets the battery pins and a healthy dose of ground, and as for the 5 extra pins at the bottom, they’ll serve as extra ground pins, and give us shuffling slots for pins that are best routed southward.

Components And Placement

Having 1206 resistors on such a module is a double-edged sword. On one hand, given the adjustability, you definitely want resistors that you’d be able to replace easily, so 0402 is not a great option. However, 1206 can actually be harder to replace with a soldering iron, since you need to heat up both sides. The writing is more readable on 1206, no doubt, and it’s also nice that this module is optimized by size. Still, for the sake of routability, I will start by replacing the LEDs and LED resistors with 0603 components – those are resistors you will not be expected to replace, anyway.

Also, I have a hunch that a few components need to be moved around. First one is the RProg, no doubt – it’s in the way of the switching path, going right under the SW polygon. Then, I will rotate the Rsense resistor so that it’s oriented vertically – it feels like that should make the VIN track less awkward, and show whether there’s any space to be freed on the left.

Resistors replaced, a few components moved, and here’s where the fun begins. The IGATE track is specifically designated in the datasheet as pretty sensitive, to the point the PDF talks about leakage from this track to the other tracks – it is a FET gate driver output, after all. Having it snake all around power tracks feels uncomfortable I’d like to refactor these FETs a bit, and see if I can make the IGATE track a bit more straightforward, perhaps also make the space usage on the left more optimized. While doing that, I will be shuffling pins between the castellated edges every now and then.

After a bit of shuffling and component rerouting, it felt like I wasn’t getting anywhere. It was time to try and reconstruct the circuit in the way it could make sense, prioritizing the power path and starting with it. For that, I pulled out both FETs, current sense resistor and the feedback divider out of the circuit, and tried rearranging them until it looked like they would work.

Following quite a few attempts at placing the components, I had to settle on the last one. I_GATE took quite a detour, though I did route it via-less in the end; VIN and CLN went on the bottom layer to give room to I_GATE (and be able to cross each other), and all the non-sensitive signals went into vias so that they could be routed outside of the switching area. It turned out the pinout is seriously not conducive to a neat layout; I suppose, some chips are just like that. Perhaps, it was that the gate driver only could’ve had been located on this particular, so that’s why the IGATE pin is on the opposite side of where the FET could be, instead of it, say, being next to V_SYS outputs.

Post-Redesign Clarity

Is the board better now? In many ways, yes; in some ways, no. I don’t know that it’s necessarily prettier, if that makes sense, there were certainly things about the board’s original state that were seriously nice. The package chosen for the FETs definitely didn’t help routing with my I_GATE target in mind, giving no leeway to route things between pins; if I were to change them to DFN8, I could indeed more easily provide a VSYS guard track that the datasheet suggests you use for I_GATE.

I’ve also rearranged the pinout quite a bit. That does mean the STATUS/POWER side distinction of the original board no longer works, but now pins don’t have to go across the board, cutting GND in half. After looking into the datasheet, I didn’t find any use for the CSN pin being broken out, since it’s just a sense resistor net; that space is now occupied by a GND pin, and there’s one less track to route out.

There’s now a good few GND pins on the board – way more than you might feel like you need; the right header feels particularly empty. If you wanted, you could add a Maxim I2C LiIon fuel gauge onto the board, since there’s now enough space in the top right, and quite a few free pins on the right. This would let your UPS-powered device also query the UPS’s status, for one. Of course, such things can always be added onto the actual board that the module would mount onto.

I also removed designators about things that felt too generic – specifically, resistors that only have one possible value and won’t need to be replaced, like LED resistors and pullups for mode selection jumpers. All in all, this board is now a little easier to work with, and perhaps, its ground distribution is a little better.

This module’s idea, and both its authors and my implementation are seriously cool! I hope I’ve helped make it cooler, if at least in the battery connector department. Both the pre-review and post-review versions are open-source, so you can also base your own castellated module off this board if you desire – it’s a good reference design for both LTC4040 and also self-made castellated modules. It’s only 30 mm x 30 mm, too, so it will be very cheap to get made. I hope my input can make this module all that cooler, and, at this point, I want to make a board around this module – stay tuned!

As usual, if you would like a design review for your board, submit a tip to us with [design review] in the title, linking to your board files. KiCad design files strongly preferred, both repository-stored files (GitHub/GitLab/etc) and shady Google Drive/Dropbox/etc .zip links are accepted.

We would not be surprised if DSI screens made up the majority of screens on our planet at this moment in time. If you own a smartphone, there’s a 99.9% chance its screen is DSI. Tablets are likely to use DSI too, unless it’s eDP instead, and a smartwatch of yours definitely will. In a way, DSI displays are inescapable.

This is for a good reason. The DSI interface is a mainstay in SoCs and mobile CPUs worth their salt, it allows for higher speeds and thus higher resolutions than SPI ever could achieve, comparably few pins, an ability to send commands to the display’s controller unlike LVDS or eDP, and staying low power while doing all of it.

There’s money and power in hacking on DSI – an ability to equip your devices with screens that can’t be reused otherwise, building cooler and cooler stuff, tapping into sources of cheap phone displays. What’s more, it’s a comparably underexplored field, too. Let’s waste no time, then!

Decently Similar Internals

DSI is an interface defined by the MIPI Alliance, a group whose standards are not entirely open. Still, nothing is truly new under the sun, and DSI shares a lot of concepts with interfaces we’re used to. For a start, if you remember DisplayPort internals, there are similarities. When it comes to data lanes, DSI can have one, two or four lanes of a high-speed data stream; smaller displays can subsist with a single-lane, while very high resolution displays will want all four. This is where the similarities end. There’s no AUX to talk to the display controller, though – instead, the data lanes switch between two modes.

The first mode is low-speed, used for sending commands to the display, like initialization sequences, tweaking the controller parameters, or entering sleep mode. You can capture this with a logic analyzer. If you’ve ever sniffed communications of an SPI display, you will find that there are many similarities with how DSI commands are sent – in fact, many SPI displays use a command set defined by the MIPI Alliance that DSI displays also use. (If your Sigrok install lists a DSI decoder, don’t celebrate too soon – it’s an entirely different kind of DSI.)

The second mode is high-speed, and it’s the one typically used for pixel transfer. A logic analyzer won’t do here, at least not unless it’s seriously powerful when it comes to capture rate. You will want to use a decent scope for working with high-speed DSI signals, know your way around triggers, and perhaps make a custom PCB tap with a buffer for the the DSI signal so that your probe doesn’t become a giant stub, and figure out a way to work with the impedance discontinuities. Still, it is very much possible to tap into high-speed DSI, like [Wenting Zhang] has recently demonstrated, sometimes an approximation of the high-speed signal is more than enough for reverse-engineering.

Got a datasheet for your panel? Be careful – the initialization sequence in it might be wrong; if your bringup is not successful or your resulting image is weird, this just might be the culprit, so even if you have procured the correct PDF, you might still end up having to capture the init sequence with a logic analyzer. Whether your display’s initialization are well-known, or you end up capturing them from a known-working device, you will need something to drive your display with – a typical Arduino board will no longer do; though, who knows, an RP2040 just might, having seen what you all are capable of.

Ideally, you will want a microcontroller or a CPU that has a DSI peripheral, with decent documentation and/or examples on how to use it – that part is important. Linux-capable Raspberry Pi boards can help you here a surprising amount – you may remember the Raspberry Pi DSI header as being proprietary, but that was only true initially. With developments like the official Raspberry Pi screen and open-source graphics drivers aided by that $10k driver bounty they put out, it became viable to connect custom screens. WaveShare DSI screens are a known alternative if you want to get a DSI display for your Pi. On the regular Pi, you only get two lanes of DSI, but that is good enough for many a display. Funnily enough, you can get a third-party display for your Pi that uses the same panel, with two extra chips that seem to run the display without a driver like the official Pi display (this thread on these displays is fascinating!); the display is still limited to the same resolution, the only advantage is a slightly lower price, and the ability to overload your 3.3V rail is a questionable benefit. It’s not quite clear why this display exists, but you might want to resist the temptation.

If you’re using a Pi Compute Module, you get entire two DSI peripherals to play with, one four-lane and one two-lane, and it doesn’t take long to find a good few examples of Raspberry Pi Compute Module boards with DSI screens. If you have a Compute Module and its devboard somewhere on a shelf, you can do four-lane DSI, with a Linux-exposed interface that works in the same way alternative OSes do on your phone. Given that CMs are typically used for custom stuff and a hacker using one is more likely to have patience for figuring out DSI panel parameters, a Compute Module baseboard is a pretty popular option to hack on that one cheap DSI display from a tablet that caught your eye! Don’t have a baseboard? You can even etch one, here’s a single-layer breakout with a DSI socket. Not that you don’t need a Compute Module if you’re doing two-lane DSI: a regular Pi will do.

So, get out there and hack – there is a ton of unexplored potential in the never-ending supply of aftermarket screens for older iPhone and Samsung models!  Speaking of phones, they are the forefront of DSI hacking, as you might suspect, thanks to all the alternative OS projects and Linux kernel mainlining efforts. You can enjoy fruits of their labour fairly easily, sparing you a logic analyzer foray – reusing a seriously nice DSI display might be as easy as loading a kernel module.

Want A Panel? Linux Is Here To Help

There’s a fun hacker tactic – if you’re looking for an I2C GPIO expander chip, you can scroll through the Linux kernel config file that lists supported GPIO expanders, and find a good few ICs you’ve never known about! What’s great is, you know you’re getting a driver, too.

The same goes for DSI screens, except the payoff is way higher. If you’re on the market for a DSI screen, you can open the list of Linux kernel drivers for various DSI panels. Chances are, all you need is just the physical wireup part, maybe some backlight driving, and a Device Tree snippet.

Want a $20 1920 x 1200 IPS display for your Compute Module? Who doesn’t! Well, wouldn’t you know, the Google Nexus 7 tablet uses one, and the driver for it is in mainline Linux! Just solder together a small FPC-to-bespoke-connector adapter board (or order PCBA), add a Device Tree snippet into your configuration, and off you go; there are even custom boards for using this display with a CM4, it’s that nice.

New displays get added into the kernel all the time; all it takes is someone willing to poke at the original firmware, perhaps load a proprietary kernel module into Ghidra and pull out the initialization sequence, or simply enable the right kind of debug logging in the stock firmware. All of this is thanks to tireless efforts of people trying to make their phones work beyond the bloatware-ridden shackles of the stock Android OS; sometimes, it’s some company doing the right thing and upstreaming a driver for a panel used by hundreds of thousands of devices in the wild.

There are some fun nuances in the display scene, as much as of a “scene” it is – people are just trying to make their devices work for them, then share that work with other people in the same situation, figuring out a display is part of the process. It’s not uncommon that a smartphone will use slightly different screens in the same batch – it’s an uncommon but real issue with alternative OSes like LineageOS, where, say, 10% of your firmware’s users might have their panel malfunction because, despite the phone listing the same model on the lid, their specific phones use a display with a different controller, that only the manufacturer’s firmware properly accounts for.

Our DSI Role Models

These are the basics of what you need to reuse DSI displays as if effortlessly. Now, I’d like to highlight a good few examples of people hacking on DSI, from our coverage and otherwise.

Without a doubt, the first one that springs to mind is [Mike Harrison] aka [mikeselectricstuff], from way back in 2013. I’ve spent a lot of time with the exact iPod Nano being reverse-engineered, and [Mike]’s videos gave me insight into a piece of tech I relied on for a fair bit. For instance, in this video, [Mike] masterfully builds a scoping jig, solders microscoping wires to the tiny PCB, walks us through the entire reverse-engineering process, and successfully reuses the LCD for a project.

Following in [Mike]’s footsteps, we’ve even seen this display reused in an ESP32 project, thanks to a parallel RGB to DSI converter chip!

[Wenting Zhang] reverse-engineering a Macbook Touchbar display is definitely on my favourites list. In this short video, he teaches us DSI fundamentals, and manages to show the entire reverse-engineering process from start to end., no detail spared. Having just checked the video description, the code is open-source, and it’s indeed a RP2040 project – just like I forecasted a good few paragraphs above.

Are mysterious ASICs your vibe, and would you like to poke at some firmware? You should see this HDMI-to-DSI adapter project, then. The creator even turns it into a powerbank with a built-in screen as a demo – that’s a hacker accessory if I’ve ever seen one. More of a gateware fan? Here’s an FPGA board doing the same, and another one, that you can see here driving a Galaxy S4 screen effortlessly. Oh, and if you are friends with a Xilinx+Vivado combination, there are DSI IP cores for you to use with barely any restrictions.

The Year Of DSI Hacking

DSI is an interface that is becoming increasingly hacker-friendly – the economies of scale are simply forcing our hand, and even the microcontroller makers are following suit. The official devboard for Espressif’s ESP32-P4, a pretty beefy RISC-V chip, sports a DPI interface alongside the now-usual CSI for cameras. We will see DSI more and more, and I raise a glass of water for numerous hackers soon to reap the fields of DSI. May your harvest be plentiful.

I thank [timonsku] for help with this article!

Recently, the Ukrainian government has published a database of Western components being used in recently produced Russian armaments, and it’s a fascinating scroll. Just how much does Russia rely on Western manufacturers’ parts? It turns out, a surprising amount. For instance, if you are wondering which ICs are used to build Iran-produced Shahed drones, it seems that it’s a whole bunch of Texas Instruments parts, as well as some Maxim, Intel, and Xilinx ones. Many of the parts in the lists are MCUs and FPGAs, but it’s also surprising how many of the components are jelly bean parts with multiple suppliers.

There appear to be thousands of parts listings, compiled from a good few dozen pieces of equipment that volunteers appear to have taken apart and scrupulously documented – just take a look at the dropdowns at the top of the page. The Ukrainian government is advocating for parts restrictions to be implemented based upon this data – as we all remember, it’s way harder to produce hardware when you can’t buy crucial ICs.

Even for a regular hacker, this database is worth a scroll, if only to marvel at all the regular parts we wouldn’t quite associate with military use. Now, all that’s left is to see whether any of the specific chips pictured have been sold to washing machine manufacturers.

[sdz] of Vogons forum brings us an unexpected device for the 21st century – a 3dfx Voodoo 4 card in MXM format, equipped with 64MB of RAM. This isn’t just a showpiece – this card actually, properly works when installed into our hacker’s Dell Precision M4800, and [sdz] tells us more on how the card came to be.

Equipped with a VSA-100 GPU, this card has a whole lot of support components for adapting old interfaces to modern ones. There’s a PCIe-PCI bridge IC, an FPGA, HDMI muxes, and a Realtek scaler for video conversion. Handling all the MXM interfaces would’ve been downright impossible, so the card also holds an LVDS header for the M4800’s panel. Plus, for testing all of it, [sdz] has developed a PCIe to MXM adapter board with minimal circuitry needed to have the card work – this is a seriously involved hack and it’s executed remarkably well.

The forum post shows a whole lot of the journey, from receiving the PCBs to code and FPGA gateware bringup, as well as videos of VGA and HDMI operation. In the end, our hacker shows us a fully working setup, the 3dfx card inserted into M4800 and driving its display, as well as overclocking experiments; the author has promised to open-source the card files in due time, too. It’s seriously nice to see DIY MXM cards in the wild, and if you ever wanted to build one, we’ve got an article tells you everything you could want to know about the MXM standard.

We thank [Misel] for sharing this with us!

You know the feeling of having just created a perfect setup for your hacker lab? Sometimes, there’s just this missing piece in the puzzle that requires you to do a small hack, and those are the most tempting. [maxime borges] has such a perfect setup that involves a HDMI 4:2 switch, and he brings us a write-up on integrating that HDMI switch into Home Assistant through emulating an infrared receiver’s signals.

The HDMI switch is equipped with an infrared sensor as the only means of controlling it, so naturally, that was the path chosen for interfacing the ESP32 put inside the switch. Fortunately, Home Assistant provides the means to both receive and output IR signals, so after capturing all the codes produced by the IR remote, parsing their meaning, then turning them into a Home Assistant configuration, [maxime] got HDMI input switching to happen from the comfort of his phone.

We get the Home Assistant config snippets right there in the blog post — if you’ve been looking for a HDMI switch for your hacker lair, now you have one model to look out for in particular. Of course, you could roll your own HDMI switch, and if you’re looking for references, we’ve covered a good few hacks doing that as part of building a KVM.

Our PCBs greatly benefit from cases – what’s with all the pins that can be accidentally shorted, connectors that stick out of the outline, and cables pulling the board into different directions. Designing a case for your PCB might feel like a fair bit of effort – but it likely isn’t, thanks to projects like turbocase from [Martijn Braam].

This script generates simple and elegant OpenSCAD cases for your KiCad PCBs – you only need to draw a few extra lines in the PCB Editor, that’s it. It makes connector openings, too – add a “Height” property to your connector footprints to have them be handled automatically. Oh, and there’s a few quality-of-life features – if your project has mounting holes, the script will add threaded-insert-friendly standoffs to the case; yet another argument for adding mounting holes to your boards, in case you needed more.

Installing the script is a single line, running it is merely another, and that will cover an overwhelming majority of boards out there; the code is all open too, of course. Want some more customization? Here’s some general project enclosure tutorials for OpenSCAD, and a KiCad-friendly StepUp tutorial. Oh, and of course, there’s many more ways to enclose PCBs – our own [Bob Baddeley] has written a guide to project enclosures that you are bound to learn new things from.

We thank [adistuder] for sharing this with us!