How To Use Those Cute But Slightly Odd 7-Segment LCDs

If you’re not aware, there is such a thing as adorable little three digit LCD 7-segment displays. They come in a ten-pin DIP package and are just begging to be integrated into a project. The catch is they are just a tiny bit weird. Luckily for us all, [Nagy Krisztián] spells out exactly how to use them.

The first odd thing about these ten-pin LCD displays is that they have a footprint that doesn’t quite mesh with standard 0.1 inch spacing, meaning they will not cleanly fit into a breadboard. Luckily, one can solve this with a bit of force. It’s a small part, and the pins don’t seem to mind.

These little LCDs are adorable, but a bit unusual to interface with.

The second odd thing is wrapping one’s head around the pin mapping. Figuring out the table of which pins activate which segments in the digits is easier if one keeps in mind that each segment of each digit is the product of two different pins. For example, “2A” is digit two, segment A, and is the product of pins 3 and COM4.

That’s not all. Electrically speaking, driving this LCD isn’t nearly as straightforward as an LED.

With an LED display, the COM pins are either common anode or common cathode, which tells one whether lighting up a segment means holding the COM pin at GND with voltage applied to the segment pin, or the other way around. But in the case of this LCD display, the polarity applied is swapped every cycle. Oh, and inactive COM pins need to held at half-voltage. Neat!

[Nagy] drives the whole thing with little more than an ATtiny84 microcontroller and a few resistors. A switchable half-voltage signal is cleverly created by combining a simple voltage divider and taking advantage of the fact that the ATtiny84’s pins can be in one of three different states depending on how they are configured: high, low, or high-impedance (pin configured as an input). Each COM pin on the display gets connected to both an ATtiny84 pin, and to the supply voltage via two resistors forming a voltage divider. When the ATtiny drives the pin high, the LCD pin sees about 3 V. When the pin is driven LOW, the LCD pin sees 0 V. When the ATtiny configures the pin as an input, the LCD pin receives about 1.5 V.

The bulk of the software is defining which pins and states equal which digits, and cycling the LCD at a rate of vaguely 60 Hz which delivers flicker-free results.

We appreciate the clever combination of voltage divider with pin configuration to create three switchable voltage levels. If you liked that and want to see more serious leveraging of pin configuration on a microcontroller, check out how to drive seven LEDs with only two pins.

Browser-Based Image Inpainting Runs Locally, If One Doesn’t Mind A Big Download

[Simon Willison] ported the Moebuis 0.2B image inpainting model to run locally in a web browser.  The web tool simply requires a user to provide an image, mark a section of it to be removed, and the model will do it’s best to patch up the missing area. The project was handled by Claude Code as an experiment in how things in the AI coding world have evolved, but more on that in a moment.

The existence of this tool shows that it’s possible for this kind of image editing to be done on the client side, running entirely locally with no reliance on remote services or server-side GPU resources. The online demo (GitHub repository here) is available if you want to try it out, but be warned it triggers a 1.27 gigabyte download of the required model on the first run.

What’s also interesting is [Simon]’s write-up, because he used the project as an opportunity to learn what has changed in the realm of AI coding agents. [Simon] is a software developer but in this project he didn’t personally write any of the code. One may think that means he didn’t learn anything other than how to use the tools, but that’s not quite true.

He learned it’s possible to convert a PyTorch-based model to ONXX, that the converted model can run in supported browsers using local WebGPU acceleration, and that the CacheStorage API will work on large files. Last but not least, he learned Claude Opus 4.8 is capable of handling such a project pretty much autonomously, and even created an informative document explaining the underlying architecture.

One may consider AI coding agents to be disasters waiting to happen, but it’s also true that the landscape is changing quickly, and write-ups like [Simon]’s give a helpful peek at those developments.

Three Different Digital Counters To Remind Us How Good We Have It

Integrated electronic modules like counters and displays are convenient and space-saving, which may also make them easy to take for granted. [Nagy Krisztián] demonstrates this by making three very different digital counter designs, each breadboarded with a 7-segment LED display. Push a button, and the displayed number increments by one for each press. It was a personal project that ended up educational in more ways than one.

The progressively-integrated designs shrink in part count and board space, but the complexity doesn’t disappear. It just moves into software.

The first version uses discrete components only, and even though it handles the counting with CD4026B decade counter ICs instead of building counters from scratch with NAND gates, it’s still by far the largest of the three. The second version simplifies driving the display with an AT28C64B EEPROM acting as a sort of hardware lookup table translating binary counts into 7-segment digit display patterns. The third uses an ATtiny24A microcontroller, and unsurprisingly has the smallest footprint.

All of this highlights two things. One is that implementing even a simple counter and 7-segment LED readout is a nontrivial affair when one gets right down to it, even when taking advantage of purpose-built ICs. The second is that the complexity that is on full display in the first version doesn’t simply disappear as the footprint and component count goes down. Rather, it moves into software and other infrastructure, like the need for compilers and chip programmers.

The whole thing is both educational and a reminder of how good the average hardware hacker has it today. There are so many effective electronic assemblies, available to just about anyone at low cost, that it can be very easy to take it all for granted and forget just how much breadboard space and wires were needed for even simple-seeming things.

[Nagy] is certainly no stranger to dealing with a lot of wires, as we’ve seen when he fooled a 286 processor into thinking it was plugged into a functioning vintage motherboard.

Make A DIY E-ink Faceplate For Valve’s Steam Machine

Valve has always designed hacker-friendly hardware, and in that spirit, [NaKyle Wright] released Inkterface, a design for an E-ink faceplate to fit the recently released Steam Machine. As far as projects go, this one is meticulously documented, so give it a peek.

The system uses a selection of components that include a 5.83″ E-ink panel and driver board, a small lithium-polymer battery, and an ESP32-based controller board.  A cleverly-designed 3D printed frame and bezel hold everything just so, creating a snug assembly with minimal wiring hassles.

A small service can be easily configured to control how the display updates.

The faceplate is wireless and self-contained, attaching with the help of four magnets. On the software side, the host machine communicates over Bluetooth, and a service takes care of pushing updates. An app for configuring and talking to the display will be available on Steam eventually, but in the meantime one can install that part manually.

[NaKyle]’s bill of materials calls for specific components, but the underlying design is very modular. Should one wish to make hardware or component changes, alterations to the 3D printed parts might be needed as well. Fortunately, [NaKyle] includes the .step files alongside the .stl models. We love to see that, because it makes tweaking or customizing so much more accessible. A homebrewed version of this E-ink panel might be just the thing to complement a homebrewed Steam machine.

Be sure to also check out the repository of Steam hardware, which contains drawings and 3D models of the Steam Deck and Steam Controller, useful for designing holders or custom brackets or whatever else one may need.

Chain-of-Thought Spoofing Targets Reasoning AI Models

Researchers [Charles Ye], [Jasmine Cui], and [Dylan Hadfield-Menell] have shown that AI Large Language Models (LLMs) can fail to correctly distinguish between different instruction sources because they prioritize writing style over metadata tags, and this role confusion leads to a powerful attack called CoT (Chain of Thought) Forgery. We’ll explain exactly how it works after a bit of background review.

Prompt injection was where “getting an LLM to do something it shouldn’t” started by exploiting the fact that LLMs communicate like people, but are much more obedient. For a while, simply telling an LLM “ignore all previous instructions and <do something funny>” yielded results no matter how transparently dumb the instructions were, and the reason it worked at all was because LLMs do not have separate data and instruction streams; it’s all one big lump of input. It’s up to the model to sort legit instructions from untrusted, user-provided data. One step towards mitigating this was the addition of roles. Continue reading “Chain-of-Thought Spoofing Targets Reasoning AI Models”

GPU-Accelerated Autorouter Handles Monstrous PCB Designs

[Brian] had an absolute monster of a PCB with thousands of nets to be routed, the kind of design that stopped traditional routers in their tracks. It would take months to route by hand, likely trying the patience of a saint in the process. To solve this specific problem he created OrthoRoute, a GPU-accelerated autorouter that he cautions is no more trustworthy than any other autorouter, but at least it’s fast!

A closeup of an extremely high-density board routed by OrthoRoute.

A KiCad plugin, OrthoRoute is so named because traces are laid down in a Manhattan lattice, a grid of orthogonal segments. All components (surface-mount only, no through-hole stuff) go on the top layer of the PCB, and all lower levels contain a grid of traces, connected as needed with blind and buried vias to route everything. OrthoRoute takes a structured and iterative approach, eventually converging on a satisfactory layout.

How does OrthoRouter actually decide how to connect things? [Brian] adapted PathFinder, an algorithm designed for routing FPGAs. Laying out a grid of orthogonal traces and punching down through them with vias to make connections has a lot in common, conceptually, with routing FPGAs. GPU acceleration makes the whole thing far more efficient than pipelining the calculations through a CPU.

OrthoRoute was built to solve a very specific problem, but in the process showed that GPU-accelerated routing is definitely feasible. Check it out in the videos, embedded below the page break.

[Brian] cautions that as-is, OrthoRoute is useful to maybe a handful of people at best, but as a KiCad plugin it’s highly modular and the hard parts are all done. If you want a closer look, or have some ideas about how to repurpose or extend it, check out the GitHub repository.

We’ve seen some nifty KiCad plugins for all kinds of purposes, from breadboarding to giving PCB traces an old-timey look, and even one specifically for designing custom keyboards. It’s not every day we see a plugin aimed at handling high-density boards with thousands of nets, though.

Continue reading “GPU-Accelerated Autorouter Handles Monstrous PCB Designs”