Software Hacks

1064 Articles

Rust-y Firmware For Waveshare Smartwatch

April 11, 2026 by 3 Comments

Waveshare makes a nifty little ESP32-S3 based smartwatch product, but its firmware is apparently not to everyone’s liking. Specifically, it’s not to [infiniton] a.k.a [Bright_Warning_8406]’s liking, as they rewrote the entire code base in Rust. No_std Rust, to be specific, but perhaps that doesn’t need to be specified when dealing with ESP32.

On the Reddit thread about the project, he lists some of the advantages. For one thing, the size of the binary has dropped from 1.2 MB to 579 kB while maintaining the same functionality. More interesting is that he’s been able to eliminate polling entirely: the firmware is purely event-driven. The CPU is not just idle but parked until a timer or GPIO event wakes it up. For this form factor, that’s a big deal — you can’t fit a very large battery in a watch, after all.

Getting drivers for the AMOLED display, touch sensor, audio, and RTC modules written from scratch is an impressive accomplishment. Apparently the screen driver in particular was “a nightmare” and we believe it. There’s a reason most people go for existing libraries for this stuff. [Bright_Warning] did not post screenshots or video, but claims his version of the watch watch can make HTTP calls to Smart Home, play MP3s, play the old phone games– Snake, 2048, Tetris, Flappy Bird, Maze– and even comes with a T9 keyboard for text input.

If you’re looking to get closer to bare metal, and don’t mind it being Rust-y, take a look at the code on GitHub in the first link above. This author isn’t enough of a rustacean to say if the code is as good as it sounds at a glance, but nothing egregious jumps out. The documentation describing exactly what’s going on under the hood isn’t half-bad, either. If you aren’t into Waveshare products, you could easily adapt this code into a more DIY ESP32 watch, too.

If you’re not into Rust, uh… washing soda and electric current can get it off of steel, and probably microcontrollers too. We can’t say that the chip will work after that, but hey — no rust.

USB, Abstracted

April 9, 2026 by 16 Comments

Modern technology builds on abstractions. Most application programmers today don’t know what a non-maskable interrupt is, nor should they have to. Even fewer understand register coloring or reservation stations for instruction scheduling, and fewer still can explain the physics behind the transistors in the CPU. Sometimes tech starts out where you need to know everything (programming a bare-metal microprocessor, for example) and then evolves to abstraction. That’s where [WerWolv] wants to get you for writing USB code using the recent post USB for Software Developers.

Many USB tutorials assume you want to know about the intricacies of protocol negotiation, information about the hardware layer, and that you are willing to write a Linux kernel module to provide a driver. But thanks to abstraction, none of this has been absolutely necessary for many use cases for a long time.

While the post focuses on Linux, there is libusb for Windows. We presume the same principles would apply, more or less.

Continue reading “USB, Abstracted” →

WolfIP Doesn’t Allocate

April 9, 2026 by 30 Comments

For some types of embedded systems — especially those that are safety-critical — it’s considered bad form to dynamically allocate memory during operation. While you can usually arrange for your own code to behave, it’s the libraries that get you. In particular, it is hard to find a TCP/IP stack that doesn’t allocate and free memory all over the place. Unless you’ve found wolfIP.

The library supports a BSD-like non-blocking socket API. It can act as an endpoint, but can also support multiple interfaces and forwarding if you were building something like a router. It doesn’t appear to be bare-bones either. In addition to the normal things you’d expect for IPv4, there’s also ICMP, IPSEC, ARP, DHCP, DNS, and HTTP with or without SSL TLS. There is also a FIPS-compliant implementation of WireGuard for VPN, although it is not directly compatible with standard WireGuard, only with other instances of itself (known as wolfGuard). There is a Linux kernel module for WolfGuard, though.

The code should be fairly easy to port, and it includes a binding for FreeRTOS already. If you’ve used wolfIP, let us know in the comments.

If you want to really get down to the low-level, try this project. Of, if you want a refresher on basics, we can help with that, too.

Turning A Bluetooth Caliper Into A FreeCAD Input Device

April 5, 2026 by 22 Comments

It’s a common ritual: whipping out those calipers or similar measuring devices to measure part of a physical object that we’re trying to transfer into a digital model in an application like FreeCAD. Wouldn’t it be nice if said measurements were to be transferred instantaneously into the model’s sketch, including appropriate units of measurement? That’s essentially what [stv0g] has done by merging a Sylvac Bluetooth-enabled caliper and FreeCAD using a plugin.

Key to the whole operation is a Bluetooth-enabled caliper like the Sylvac S_Cal EVO that [stv0g] managed to score on EBay for a mere €90 when it normally goes for multiple times that amount. This has BLE built in, using BLE’s standard GATT profiles for device communications specifications. Along with the provided Sylvac developer tools, this made it relatively easy to develop the InstrumentInput addon for FreeCAD.

Continue reading “Turning A Bluetooth Caliper Into A FreeCAD Input Device” →

Writing An Open-World Engine For The Nintendo 64

March 29, 2026 by 7 Comments

Anyone who has ever played Nintendo 64 games is probably familiar with the ways that large worlds in these games got split up, with many loading zones. Another noticeable aspect is that of the limited drawing distance, which is why even a large open area such as in Ocarina of Time‘s Hyrule Field has many features that limit how far you can actually see, such as hills and a big farming homestead in the center. Yet as [James Lambert] demonstrates in a recent video, it’s actually possible to create an open world on the N64, including large drawing distances.

As explained in the video, the drawing distance is something that the developer controls, and thus may want to restrict to hit certain performance goals. In effect he developer sets where the far clipping plane is set, beyond which items are no longer rendered. Of course, there are issues with just ramping up the distance to the far clipping plane, as the N64 only has a 15-bit Z-buffer, after which you get ‘Z fighting’, where render order becomes an issue as it’s no longer clear what is in front of what.

One fix is to push the near clipping plane further away from the player, but this comes with its own share of issues. Ergo [James] fixed it by doing two render passes: first all the far-away objects with Z-buffer disabled, and then all the nearby objects. These far-away objects can be rendered back-to-front with low level-of-detail (LoD), so this is relatively fast and also saves a lot of RAM, as the N64 is scraping by in this department at the best of times.

In the video the full details of this rendering approach, as well as a new fog rendering method, are explained, with the code and such available on GitHub for those who wish to tinker with it themselves. [James] and friends intend to develop a full game using this engine as well, so that’s definitely something to look forward to.

Continue reading “Writing An Open-World Engine For The Nintendo 64” →

A screenshot of the inkjet simulator project

Understand Your Printer Better With The Interactive Inkjet Simulator

March 27, 2026 by 17 Comments

Love them or hate them, inkjets are still a very popular technology for putting text and images on paper, and with good reason. They work and are inexpensive, or would be, if not for the cartridge racket. There’s a bit of mystery about exactly what’s going on inside the humble inkjet that can be difficult to describe in words, though, which is why [Dennis Kuppens] recently released his Interactive Printing Simulator.

[Dennis] would likely object to that introduction, however, as the simulator targets functional inkjet printing, not graphical. Think traces of conductive ink, or light masks where even a single droplet out-of-place can lead to a non-functional result. If you’re just playing with this simulator to get an idea of what the different parameters are, and the effects of changing them, you might not care. There are some things you can get away with in graphics printing you really cannot with functional printing, however, so this simulator may seem a bit limited in its options to those coming from the artistic side of things.

You can edit parameters of the nozzle head manually, or select a number of industrial printers that come pre-configured. Likewise there are pre-prepared patterns, or you can try and draw the Jolly Wrencher as the author clearly failed to do. Then hit ‘start printing’ and watch the dots get laid down.

[Dennis] has released it under an AGPL-3.0 license, but notes that he doesn’t plan on developing the project further. If anyone else wants to run with this, they are apparently more than welcome to, and the license enables that.

Did you know that there’s an inkjet in space? Hopefully NASA got a deal on cartridges. If not, maybe they could try hacking the printer for continuous ink flow. Of course that’s all graphics stuff; functional printing is more like this inkjet 3D printer.

Two test towers, showing the palette potential of three (R, B, Y) filaments.

FullSpectrum Is Like HueForge For 3D Models, But Bring Your Toolchanger

March 17, 2026 by 20 Comments

Full-color 3D printing is something of a holy grail, if nothing else, just because of how much it impresses the normies. We’ve seen a lot of multi-material units in the past few years, and with Snapmaker’s U1 and the Prusa XL, it looks like tool changers are coming back into vogue. Just in time, [Ratdoux] has a fork of OrcaSlicer called FullSpectrum that brings HueForge-like color mixing to tool-changing printers.

The hook behind FullSpectrum is very simple: stacking thin layers of colors, preferably with semi-translucent filament, allows for a surprising degree of mixing. The towers in the image above have only three colors: red, blue, and yellow. It’s not literally full-spectrum, but you can generate surprisingly large palettes this way. You aren’t limited to single-layer mixes, either: A-A-B repeats, and even arbitrary patterns of four colors are possible, assuming you have a four-head tool-changing printer like the Snapmaker U1 this is being developed for.

FullSpectrum is, in fact, a fork of Snapmaker’s fork of OrcaSlicer, which is itself forked from Bambu Slicer, which forked off of PrusaSlicer, which originated as a fork of Slic3r. Some complain about the open-source chaos of endless forking, but you can see in that chain how much innovation it gets us — including this technique of color mixing by alternating layers.

Continue reading “FullSpectrum Is Like HueForge For 3D Models, But Bring Your Toolchanger” →