atomic14

Any Google Font on Your ESP32 Display

Sun, 12 Jul 2026 00:00:00 +0000

Every time I put text on a TFT display with TFT_eSPI I end up staring at the same built-in fonts: chunky, jagged, and very 1980s. Which is a shame, because the library has been able to draw beautiful anti-aliased “smooth fonts” for years. The rendering was never the problem, the tooling was. The official way to make a smooth font involves installing the Processing IDE, editing a Java sketch, and running it again for every font at every size. The result is that most projects never bother.

So I built something to fix that.

fonts.atomic14.com is a free browser tool that turns any of 1,900+ Google Fonts (or your own TTF file) into fonts ready to use with TFT_eSPI, M5Stack/M5GFX or LVGL, with a pixel-exact preview of how they’ll look on your panel. Everything runs in your browser; no font ever gets uploaded anywhere.

The rest of this post is about what’s actually inside these font files, and the handful of things worth knowing before you use them.

What a “smooth font” actually is

TFT_eSPI’s smooth fonts are VLW files, a format inherited from the Processing project. A VLW is gloriously simple: a small header (glyph count, size, ascent, descent), a table of per-glyph metrics, and then raw 8-bit alpha bitmaps, one byte per pixel. No vector outlines, no hinting, no kerning. The font was rasterized on a desktop, and the microcontroller just blits pixels.

The “smooth” part is that alpha channel. Each pixel stores how much of the glyph covers it (0 to 255), and at draw time the library blends between your text colour and background colour in RGB565 space:

pixel = (fg × alpha + bg × (255 − alpha)) / 256

This is why tft.setTextColor(TFT_WHITE, TFT_BLACK) needs both colours for smooth fonts: there’s no transparency, only blending toward a known background. Draw over a photo and you’ll get fringes around the letters. That’s not a bug in your font, it’s how the format works.

PROGMEM or LittleFS?

You have two ways to get a VLW onto the chip, and the tool exports both:

A .h header with the font as a PROGMEM byte array. Easiest by far: #include it, call tft.loadFont(MyFont28);, done. The font lives in flash alongside your code.
A .vlw file on LittleFS or SD, loaded with tft.loadFont("MyFont28", LittleFS);. Better when you have several fonts or want to swap them without recompiling, at the cost of the filesystem-upload dance.

Either way, remember to add #define SMOOTH_FONT to your User_Setup.h. Forgetting it is the number one cause of “why doesn’t loadFont exist” compile errors.

Keeping the files small

A glyph costs 28 bytes of metadata plus width × height bytes of bitmap. At 28 px, a full Basic Latin set lands around 25-30 KB; a digits-only font for a sensor readout can be under 2 KB. Every character you leave out is flash you keep. The tool shows a live byte count as you change the character set, and you can click individual characters out of the grid. If all you need is °C and ten digits, ship °C and ten digits.

Quirks the preview will save you from

Two behaviours surprise almost everyone. I made sure the preview reproduces both, because it renders with a port of TFT_eSPI’s own drawing code rather than the browser’s font engine:

Text wraps at the right edge. When a glyph won’t fit, smooth-font drawing jumps back to x=0 on the next line. It doesn’t clip.
Spaces don’t use the font’s real space width. The library guesses (ascent + descent) × 2/7 pixels instead. Word spacing on the device will never quite match your desktop’s rendering of the same font, but the preview matches the device, which is the thing that counts.

And if a character shows up blank on the display, it’s almost always because it wasn’t in your subset. The degree sign is the classic victim: it’s not in Basic Latin, so a temperature readout quietly comes out as “23.5C”. Adding it to the extra characters box fixes it, and the preview will show you the gap before your display does.

Try it without any hardware

Every font you make can be tested on a simulated ESP32 and ILI9341 display in Wokwi: one click copies a complete test sketch with the font embedded and opens a pre-wired template project. Paste it in, press play, and you’re looking at your font rendered by the real TFT_eSPI library on an emulated panel.

The download also includes a ready-to-flash Arduino test project if you’d rather see it on real hardware.

LVGL too

The same subsetting and rasterization pipeline exports LVGL fonts: C arrays compatible with what lv_font_conv produces, at 1, 2, 4 or 8 bits per pixel. If your project uses LVGL or SquareLine Studio, grab that file instead.

Under the hood, for the curious

The VLW writer is byte-for-byte compatible with Processing’s PFont.save (verified against golden files), the renderer is checked against TFT_eSPI running in an emulator, and the LVGL writer is calibrated against real lv_font_conv output. The whole thing is client-side: opentype.js parses the font, a Web Worker rasterizes the glyphs to alpha bitmaps, and TypeScript writers produce the output bytes.

Go and make something less 1980s: fonts.atomic14.com. And if you’re still choosing a display to pair it with, the ESP32 display boards database has every popular board in one filterable table. I’d love to hear how you get on.

Every Espressif Module in One Place

Tue, 09 Jun 2026 00:00:00 +0000

Every time I start a new project the first question is the same: which module should I use? Picking an Espressif chip means pulling up datasheets, hunting for pinout diagrams, checking which pins are safe, and ending up with a dozen browser tabs open.

So I built something to fix that.

www.atomic14.com/esp32 is a free, community-maintained database of Espressif modules. Every module in one place, with the specs, pinouts and 3D models you actually need to make a decision.

What’s in there

Right now it covers 24 modules across 11 SoCs, from the classic ESP32 through to the ESP32-S3, ESP32-C3 and ESP32-H2. For each one you get:

Searchable specs pulled straight from the official datasheets: cores, clock speed, RAM, flash and PSRAM options, Wi-Fi and Bluetooth support.
Colour-coded pinouts with the strapping pins and “don’t use these” warnings called out, so you don’t get caught by a pin that fights you at boot.
Interactive 3D models so you can see the actual footprint and dimensions before you commit to a board layout.
Side-by-side comparison to put two or three modules next to each other and see exactly what changes.
Getting-started pointers for Arduino, ESP-IDF and MicroPython, plus links back to the source datasheets and reference designs.

Update: now with boards and sensors too

Since launch it’s grown well beyond bare modules:

Every popular ESP32 display board in one filterable table — the Cheap Yellow Display and its successors, the 7” wall-panel boards, AMOLED and e-paper, filterable by size, touch type and ESPHome support. Plus guides like which display board for Home Assistant and why big cheap screens feel slow.
A sensor module database — mmWave radars, temperature, CO2, energy and more, each with its ESPHome support status and a counterfeit-risk rating. If you’ve ever received a “BME280” with no humidity readout or a batch of fake DS18B20 probes, start with the fake sensor problem.

Goodbye to the old ESP32-S3 pinout

This replaces my old ESP32-S3 pinout post. That started life as a single GitHub image, which was useful but hard to keep current and only covered one module. The new ESP32-S3-WROOM-1 page does everything that did and a lot more, and the same treatment is there for the rest of the family.

It’s a living document

Datasheets get revised, mistakes creep in, and there are always edge cases worth flagging. Every page has a built-in way to report errors, and corrections are very welcome. The more eyes on it, the more accurate it stays.

Go and have a poke around: www.atomic14.com/esp32. I’d love to hear what’s missing.

Did I Actually Make It Worse?

Sun, 17 May 2026 00:00:00 +0000

A little while back I ripped the PIR and mystery chip out of one of these cheap night lights and dropped a microwave radar module in its place. It worked beautifully: much better sensitivity, sensible timeout, the whole thing tucked back into the original case like nothing had happened.

But I had a sneaking suspicion I might have improved one thing and quietly ruined another. The radar module is always on. The PIR-and-mystery-chip combo, on the other hand, looked like it was doing something clever with sleep. So before I get smug about my mod, let’s actually measure what each version is pulling from the battery.

Out comes the Nordic Power Profiler Kit II.

The Original: LEDs On

Power the supply on, start logging, and the LEDs immediately come up to greet me. It takes a moment to actually trigger because I’ve taped over the LDR (the night light flatly refuses to light up unless it thinks it’s dark), but once it triggers we’re sitting at about 80 mA, which matches the last time I measured this on the bench.

That’s the easy bit. The interesting question is what the board does when it’s not lighting up.

The Original: Waiting Mode

Wait long enough for the LEDs to time out and the trace drops off a cliff. The board settles into a “waiting for movement” mode at roughly 700-800 µA. Fine, that’s basically what a comparator and a small MCU sipping at the PIR signal ought to look like.

But then something weird starts happening. Every so often the trace drops down to a tiny fraction of that. Not lower-by-a-bit. Much lower, about 30 µA.

It sits down there for a while, then briefly pops back up to a few hundred microamps, then drops again. It’s clearly a sleep-and-poke pattern: the chip is mostly asleep and only briefly waking up to look at the PIR. As long as I don’t move, it stays in this ultra-low-power mode pretty much indefinitely.

That’s actually really impressive for a chip with all its identifying marks sanded off.

Doing the Maths on the Original

Scroll back to a chunk of the ultra-low-power section, drag a selection across it, and the PPK helpfully spits out the average: 72 µA.

And during the noisier “actively monitoring” segments it’s averaging more like 700-800 µA. So depending on what mood it’s in, the original is sipping between 72 µA and around 0.8 mA. Whichever number we pick, on its 350 mAh cell that’s a lot of standby time. In theory the 72 µA figure puts it at something like 200 days. In practice it definitely doesn’t last that long, but the cell is almost certainly not really 350 mAh either.

The really annoying thing is that I already know from living with these things that the original barely triggers. So all that lovely low power gets wasted because the night light isn’t actually on when you want it to be. Which is, you know, the entire point of a night light.

My Mod: On the PPK

Swap the leads onto the radar version. There’s a current limit resistor in series with the indicator LED here so I don’t have to worry about the LED itself drawing a lot.

Wait the ~40 seconds for the radar’s extended timeout to expire (that big cap on the CTM pad is doing its job) and then we get to see the real story.

My Mod: Idle Current

LED out, no movement, just sitting there waiting. The trace settles into a fairly fat band of noise centred around 2.85-2.9 mA.

I tried covering and uncovering the LDR to see whether the radar module was doing anything clever with it. Does it actually shut down in daylight, or just gate the output? Spoiler: it just gates the output. The module itself draws the same ~2.86 mA whether the LDR thinks it’s bright or dark. The LDR is purely there to stop the LEDs lighting up during the day, not to save power.

Honestly, 2.8 mA isn’t that bad for a radar module that’s continuously transmitting and listening. It’s just a lot more than 72 µA.

So… Did I Make It Worse?

Time to be honest with the numbers.

On paper, the original on its sad little 350 mAh cell at 72 µA average should run for around 200 days. My “improved” version at 2.8 mA on the 820 mAh cell I fitted comes out at… about 12 days.

Ouch.

In fairness, the original definitely doesn’t get anywhere near 200 days in real life, partly because the cell is optimistic and partly because every actual trigger spends time at 80 mA. And my mod actually triggers reliably, which the original conspicuously does not. But still, twelve days between charges is rubbish for something that’s supposed to live on a wall.

Salvaging It

All is not lost. I’ve got a stash of much beefier 2000 mAh cells that physically fit inside the case if I’m a bit careful about packaging.

Swapping that in gets the modded version to roughly 30 days between charges, which is much more like it. Not as flashy as “charge it four times a year”, but I’ll actually believe 30 days from a thing that genuinely turns on when I walk past.

So yes: strictly on standby current, I made it considerably worse. But factor in “does it actually do its job”, and a bigger cell, and I think I’m still ahead. Just.

The bit that’s still nagging at me is the original. Whatever that mystery chip is doing in its sleep mode is really nicely done; 72 µA average is properly low. If I could find a way to make the original trigger reliably, I’d have basically the perfect night light. That’s probably a project for another day.

If you want to watch the meters in motion (including the satisfying moment when the trace drops to a pancake-flat 30 µA), it’s all on YouTube.

ESP-IDF v6 in VS Code: Blink (and debug) on the ESP32-S3

Sun, 10 May 2026 00:00:00 +0000

ESP-IDF v6 dropped back in March and the GitHub releases page is already showing v6.0.1 - so I figured it was time to stop hiding in the v5.x cave and actually try it out.

This is a nice gentle introduction. We’ll install the IDF, wire it up to VS Code, build the classic Blink example for an ESP32-S3, then start poking at menuconfig to do the things you can’t easily do from the Arduino IDE.

Prerequisites

If you’re new to the ESP-IDF there are a couple of prerequisites to install before anything else. I’m on a Mac so for me it’s a quick brew install ... from the official setup page. Windows and Linux instructions are on the same page - just pick your platform.

If you don’t already have Homebrew, grab that first.

VS Code and the ESP-IDF extension

You don’t have to use VS Code, but the ESP-IDF extension is genuinely nice and makes everything much less painful, so that’s what I’m going to use.

In VS Code, open the Extensions panel, search for ESP-IDF and install the official Espressif one.

Once it’s installed you’ll get a little ESP-IDF Explorer icon in the side bar.

Running the Installation Manager

Click the ESP-IDF icon, go to Advanced and pick Open ESP-IDF Installation Manager. The first time round it’ll tell you the EIM executable can’t be found and ask you to choose a download mirror. Unless you’re in China, GitHub is the right answer (if you are in China, the Espressif mirror is likely faster).

That fires up the actual installation manager:

There are four options here but really only two you’re likely to care about:

Easy Installation - sensible defaults, downloads everything, just works.
Offline Installation - you download a 3-4 GB archive from the Espressif site separately and point the installer at it. Worth doing if your internet is flaky - you can put the archive on an SD card and avoid endless mid-install retries.

I went with Easy Installation. Espressif say it can take 10-45 minutes depending on your connection, which feels about right - it has to clone the whole IDF from GitHub, then download 10 toolchain bundles, then set up Python.

The progress bar is… let’s say creative. It cheerfully ticked back up to 39 seconds at one point.

After a quick “12 seconds left” stand-off, the dashboard finally shows ESP-IDF v6.0.1 as an installed version:

Creating a project

Back in VS Code, the ESP-IDF Explorer has a little + icon for the New Project Wizard. It asks which IDF version to use (we just installed 6.0.1, easy) and then offers a list of templates - I’m going for the classic Blink.

A few things to be careful with on the wizard:

Path case matters. macOS file systems aren’t case-sensitive by default but the IDF tools are. My Work folder is capital-W, so if I type work here I’ll get a mountain of weird errors later. Match the actual case.
IDF target - I’m using an ESP32-S3 so I picked that.
Serial port - leave it on detect and it usually works out which port the board is on.

Looking at the code

If you’re coming from the Arduino IDE, the layout is going to look intimidating - lots of folders, CMake files, build directories. It’s not actually that bad once you know where to look. The interesting bit lives in main/blink_example_main.c and the entry point is app_main():

The other thing that’s very different from Arduino is menuconfig. Most of the build is configured through it rather than by editing files. From the ESP-IDF Explorer side panel pick SDK Configuration Editor (menuconfig).

Configuring the LED

The Blink example has its own little Example Configuration section in menuconfig. By default it’s set up for an addressable LED strip - I just have a regular LED on a GPIO pin, so I need to switch the type to GPIO and tell it which pin to use.

A quick peek at the KiCad schematic for my dev board:

GPIO 21 is driving the LED (it’s actually green on this board because I just grabbed random LEDs out of the bin). So in menuconfig I set:

Blink LED type: GPIO
Blink GPIO number: 21
Blink period in ms: 500

Save and we’re good to go.

Build and flash (the bit that goes wrong)

The ESP-IDF Explorer has buttons for Build Project and Flash Device (and the spanner / lightning icons in the bottom status bar do the same). Build was clean, but flashing failed.

I tried it again with the board held in programming mode (boot + reset) - still no good. The default flash method on the dev board is USB JTAG and it just wasn’t co-operating.

Easy fix: change the flash method.

Pick Select Flash Method, switch from JTAG to UART, and try again. Flash succeeds, and the LED starts cheerfully blinking on the bench.

Reading the monitor

With the board running, Monitor Device opens a serial monitor and prints the boot log. Two things jumped out:

cpu_start: Pro cpu start user code
cpu_start: cpu freq: 160000000 Hz
...
spi_flash: Detected size (16384k) larger than the size in the binary image header (2048k).
Using the size in the binary image header.

So:

The CPU is running at 160 MHz but the ESP32-S3 will happily do 240 MHz.
The chip has 16 MB of flash but the binary image header says 2 MB, so the IDF is using the smaller of the two and politely warning us about it.

Both of these are easy menuconfig fixes.

Squeezing more out of the chip

Back into the SDK config editor:

Search for CPU and change the CPU frequency to 240 MHz.
Search for flash and change the flash size to 16 MB.

While we’re in there, this board also has PSRAM, so might as well turn that on:

Search for PSRAM, enable Support for external SPI-connected RAM, set the mode to octal (mine is octal PSRAM), and bump the speed to 80 MHz for good measure.

Save, build, flash, monitor. Now the boot log looks rather more pleased with itself:

MSPI Timing: Enter psram timing tuning
esp_psram: Found 8MB PSRAM device
esp_psram: Speed: 80MHz
esp_psram: SPI SRAM memory test OK
...
cpu_start: cpu freq: 240000000 Hz

8 MB of PSRAM, the full 16 MB of flash, and 240 MHz of CPU. Lovely.

Bonus round: JTAG debugging

The other thing the ESP-IDF brings to the party that you don’t really get with the Arduino IDE is proper on-chip debugging. The S3 has a built-in USB JTAG, OpenOCD comes with the toolchain, and VS Code already speaks the GDB protocol - so it should “just work”.

Should.

When I tried to start the OpenOCD server it complained that something was already listening - I had a stale OpenOCD from a previous session hanging around. A quick ps and kill in the terminal and the server started cleanly. With the flash method back on JTAG, the board flashed without complaint.

Now the fun bit - drop a breakpoint in blink_led() and hit Launch Debug:

The IDF stops you at the start of app_main first; hit continue and you sail straight into the breakpoint. Step over the line, watch the GPIO state flip, then Turning the LED off and Turning the LED on appear in the serial monitor. Step again, the LED physically turns off on the bench. That’s very satisfying compared to sprinkling Serial.println everywhere.

(Tiny gotcha: the serial monitor latched onto the wrong port the first time - just pick the right one and you’re back in business.)

So… ESP-IDF or Arduino?

The blink code itself isn’t hugely different from the Arduino version - it’s still mostly gpio_set_level(BLINK_GPIO, s_led_state) - but you get the menuconfig system, proper logging, a real debugger, and access to all the bits of the chip that the Arduino layer hides from you.

Honestly, it’s a lot less scary than it looks. If you’ve been putting off trying the IDF, v6 in VS Code is a really nice place to start.

Let me know in the comments - ESP-IDF or Arduino, which do you prefer?

Useful links

Hacking a Cheap PIR Night Light Into Something Actually Useful

Sat, 11 Apr 2026 00:00:00 +0000

I’ve been picking up a whole bunch of these motion sensitive night lights and, let’s just say, they haven’t been great. The range is poor, the battery life is nowhere near the advertised “charge it four times a year”, and the timeout is so short it’s not even enough time to get to the toilet.

I thought it might be interesting to crack one open and see if I could improve it.

I’ve got both flavours — round ones and oval ones — and internally they’re basically identical, so whatever I do to one should work for both. (Those are affiliate links — if you pick a pair up through them, I get a few pennies at no extra cost to you.)

The Plan

I’ve got a drawer full of these nice little RC-WL0516 microwave radar sensors. They’re much more sensitive than a PIR, they see through plastic, and you can tweak the sensitivity and timeout with a couple of passives. The idea is to rip the original motion sensing front end out of one of these night lights and drop the radar module in instead.

Going down the radar rabbit hole? The modern mmWave modules (HLK-LD2410 and friends) can detect you sitting still, not just moving — I've compared the whole family plus PIRs in my presence sensor guide, and there's a filterable table of all the sensors people wire to ESP32s.

Cracking One Open

The top just pops off with a bit of a squeeze. Inside, there’s a PIR sensor, an eight pin mystery chip with all the identifying marks sanded off, a light dependent resistor, and some charging circuitry.

Popping the single screw out releases the board. Underneath is a tiny 350 mAh lithium cell — and no sign of a protection board on it, which is always reassuring.

With the board out, the layout is pretty clear. PIR sensor dead centre, ring of LEDs around it, mystery chip off to one side next to the LDR, and the charging circuitry tucked down by the micro USB port.

Doing a Big Clive

Time to do my best Big Clive impression and reverse engineer the circuit. It’s a single layer board, so it’s all quite tractable — the positive side of every LED is tied straight to battery plus, and the negative side goes through the mystery chip down to battery minus.

The PIR plus and PIR minus pins go straight into the mystery chip. The LDR is part of a potential divider with R5 feeding another pin on the chip, with a decoupling cap on the rail. Over on the charging side there’s a TP4054 with a 3.3k programming resistor — that’s about 300 mA of charge current — and an LED to show the state. That’s it. Highly optimised BOM, one big mystery IC doing all the work.

What’s interesting is there’s no current limiting on the LEDs. Nothing at all. The chip is clearly driving them directly, and presumably there’s some limit built in to the chip itself.

How Much Current?

Before doing anything else, I wanted to know how hard this thing is actually driving the LEDs. Desolder the battery, hook the pads up to a bench supply with the current limit set to 100 mA, and trigger the PIR.

68 mA. So there is some built-in limiting on the mystery chip after all. This mystery IC is doing a lot of heavy lifting.

Playing with the Radar Module

These RC-WL0516 modules are lovely. They have pads for a light dependent resistor so they only trigger in the dark, and a space to solder on a capacitor to extend the timeout.

I wired one up on a breadboard, hung an LED off the output through a current limit resistor, and fed it 5 V.

Stand still, the LED goes off. Move, it comes back on. The default timeout is about three seconds. As I mentioned, three seconds is nowhere near enough time to get to the toilet, so I soldered a 0.22 µF capacitor to the CTM pad to extend it.

Much better. I also wired up an LDR so it only triggers in the dark, and confirmed the motion detection works really nicely — much more sensitive than the original PIR ever was.

The Modification

Here’s the plan. Strip the PIR sensor, the mystery chip, and its supporting passives off the original board. Sit the radar module on top where there’s a nice flat empty space. Drive the LEDs through a current limiting resistor and a small MOSFET controlled by the radar module’s output pin. Power everything from the existing battery pads.

Microscope out, and with a bit of soldering the whole thing came together more neatly than I expected. I took the opportunity to upgrade the battery too — swapping the tiny 350 mAh cell for a much more generous 820 mAh one.

The board slides back into its case, the battery tucks in alongside, the USB port still lines up with the hole in the shell, the screw goes back in, the diffuser clips in, and… good as new. You’d never know anything had happened.

Does It Actually Work?

Stuck it on the stairs, turned the lights off, and waited. Walk past — it lights up. Stand still — it goes out after a sensible amount of time. Sensitivity is miles better than it was, the battery should last a lot longer, and the timeout is long enough to be useful.

It works. Now I just need to do the rest of them…

If you want to see the whole thing in motion — the teardown, the reverse engineering, the soldering, and the moment it finally lights up on the stairs — go and watch it on YouTube. Likes and subscribes are always appreciated.

I learned to solve a Rubik's cube and it was incredibly disappointing

Sun, 05 Apr 2026 00:00:00 +0000

I recently decided to learn how to solve the Rubik’s cube. As a self-confessed geek, it felt like something I should be able to do.

I found a pretty good website that breaks it down into eight steps, from “the Daisy” all the way through to “Finish Him!”. I memorised the moves. Pretty soon I could solve it without looking at the website.

It was incredibly disappointing.

I was just mechanically following “algorithms” I’d memorised. No skill, no insight. Pattern match, apply algorithm, repeat.

So I thought, this can’t be how speed cubers do it. Steps 1-3 are painfully tedious. There must be a faster way.

This led me to F2L, solving the first two layers simultaneously. The first resource I found suggested memorising 42 algorithms - my response - yeah, I’m not doign that…

Then I found a few suggestions on solving F2L “intuitively”, which sounded more my style. Maybe this approach would actually involve some thinking.

It’s definitely faster and requires a bit more brainpower, but ultimately? Still pattern matching. I wanted to understand why the algorithms work, not just memorise better ones.

Frustrated, I did what everyone does now. I asked ChatGPT.

After the obligatory “That’s a brilliant insight!” it gave me this analogy:

Beginner: following GPS directions
Intermediate: memorised routes
Advanced: understand the map
Expert: improvise new routes instantly

I keep coming back to this because it maps so well onto the junior-to-senior engineer journey.

You start out following instructions. At some point you start pattern matching. This problem looks like that problem I solved last year. Eventually the memorised playbook isn’t enough and you start synthesising new solutions from first principles. You develop taste. Judgment. The ability to look at a system you’ve never seen and know where the problems are going to be.

That last part is what I find interesting about coding agents right now. They’re very good at levels one and two. Following instructions, applying known patterns at scale, faster and more consistently (well, most of the time…) than any person could.

And sometimes watching an agent churn out code gives me that same Rubik’s cube feeling. It works. It passes the tests. But I’m just sitting here approving it. What am I even doing here?

But then you hit a problem where the agent can’t see what you see. It solves the ticket but puts the logic in the wrong place. It writes code that works today but will be a nightmare in six months. And you remember what you’re doing here. That’s the difference between mechanically producing a solution and deeply understanding the solution.

For now, experienced engineers are the ones providing the taste and judgment that makes the difference between code that works and code that works well.

I’m never going to be a speed cuber. But maybe, with the help of agents, I might end up being a speed coder…

Why Won't My Board Reset?

Sat, 04 Apr 2026 00:00:00 +0000

I’ve got a slightly annoying problem with one of my dev boards. The reset button does absolutely nothing.

These are the boards I got made by PCBWay — they did the PCBs and they came out really nice. I did the assembly myself. But somewhere along the way, something went wrong on one of them.

A Tale of Two Boards

I loaded both boards with a fast blink sketch to make the problem obvious. On the working board, hitting the reset button stops the flashing immediately — exactly what you’d expect. On the broken board? Nothing. The LED just keeps happily blinking away.

This is more than just a minor annoyance. To get an ESP32 into programming mode, you hold down the boot button and then press reset. Without a working reset button, I’m constantly having to unplug and re-plug the USB cable. Not ideal.

Checking the Schematic and PCB

First things first — let’s make sure the design is actually correct.

The schematic looks fine: the reset switch is connected to the EN (enable) pin through the standard RC circuit — a resistor and a capacitor. Nothing unusual there.

The PCB layout checks out too. Tracing the path from the reset switch down to ground, up through the RC network, and all the way to the EN pin — everything is routed correctly.

So the design isn’t the problem. Time to get the multimeter out.

Buzzing Out the Circuit

I started probing the connections on the board. The EN pin to the resistor — good. EN pin to the capacitor — good. The trace from the RC network to the switch — also good.

Then I put the probes across the switch itself and pressed the button.

Nothing. No continuity at all.

The boot button on the same board? Works perfectly. But the reset button is completely dead.

Under the Microscope

Time for a closer look. Under the microscope, the soldering on the ESP32’s EN pin looks fine — which the continuity test already confirmed. The RC components look good too.

The button itself? It looks solidly soldered. Visually, I couldn’t see any obvious problems. Comparing it with the boot button, the boot button’s joints were a bit shinier, but nothing that would explain a total failure.

It’s funny how boards look under the microscope — from a distance, this board looks perfectly clean, but zoom in and there’s all sorts of hairs and disgusting stuff.

Reflow and Test

With no obvious visual fault, I decided to reflow the solder joints on the reset button. Applied some flux, heated up each joint, and could feel solid connections on both sides of the switch.

Buzzed it out again. Still nothing. The button clicks mechanically, but there’s no electrical continuity when pressed.

At this point, it’s clear: the button itself is the problem.

The Fix: Just Add Alcohol

Looking more closely, the inside of the button seemed to be full of flux residue. On a whim, I soaked the board in IPA (isopropyl alcohol) to try and clean it out.

After a good soak, I probed the button again — and it worked perfectly. Every press gave clean, reliable continuity.

Plugging the board back in, the blink sketch was running. Hit the reset button and… the flashing stopped. Success!

Lesson Learned

The whole problem was flux residue inside the tactile switch, preventing the internal contacts from making a clean connection. The solder joints were fine, the traces were fine, the schematic was fine — it was just a dirty button.

A remarkably simple fix in the end. A bit of cleaning was all it needed.

The lesson? Use more alcohol — that’s the conclusion I’m taking from this…

Is SOT666 Really Standard?

Sun, 15 Mar 2026 00:00:00 +0000

Is SOT666 Really Standard? Spoiler: Not Really

I’ve been investigating some quality assurance failures on my ESP32 rainbow boards and tracked a few issues down to a USBLC6 ESD protection IC in a SOT666 package. Under the microscope, it looked like the footprint didn’t quite match the package — like it had missed alignment and hadn’t soldered on properly.

I fixed the immediate problem by reflowing the solder and pushing the device into place. But this should be automatic — the pick and place machine puts the component down and solder tension should pull it into alignment. So I started wondering: is the footprint actually correct?

The Problem: Footprint vs Datasheet

Opening up the schematic in KiCad, the USBLC6 is assigned a SOT666 footprint. That’s the correct package — so far so good.

But when I compared the KiCad footprint against the recommended footprint in the USBLC6 datasheet, things looked pretty different.

The KiCad footprint for SOT666 is completely different from the footprint in the datasheet — even though they’re both supposed to be SOT666.

So Is KiCad Wrong?

Maybe. But it’s not that simple.

If you Google “SOT666” you’ll find all sorts of different footprints from different manufacturers. Here’s how they stack up:

Nexperia’s SOT666 definition — looks very similar to KiCad’s version. In fact, I think KiCad’s footprint is based on this one.
ST’s USBLC6 datasheet — has its own recommended footprint with quite different dimensions.
Diodes Incorporated’s SOT666 — yet another completely different suggested pad layout.

So you’ve got a “standard” package name — SOT666 — but every manufacturer seems to have their own opinion about what the footprint should look like.

Checking EasyEDA for Comparison

I thought it might be instructive to check another EDA package. In EasyEDA, the SOT666 footprint for the USBLC6-2P6 is different again:

Pad width (PW1): 0.3 mm — this actually matches the ST datasheet
Pad length (PL1): 0.85 mm — the ST datasheet says 0.99 mm, so still different

Three different tools, three different footprints, all for the same “standard” package. Not exactly confidence-inspiring.

The Lesson: Always Follow the Datasheet

The basic conclusion is that although these packages share the same name, the footprints are not really standardised. Everything is randomly different.

The advice: look in the datasheet and use what’s in the datasheet. Don’t rely on the standard package names because they might not quite match up with your specific component.

Creating a Custom Footprint in KiCad

Fortunately, it’s really easy to create footprints in KiCad. Using the footprint wizard with the SOIC template, I just needed to plug in the values from the ST datasheet:

Pad count: 6 (two rows of 3)
Pitch: 0.5 mm
Pad width: 0.3 mm
Pad length: 0.99 mm
Row spacing: 1.61 mm (0.62 mm gap + 0.99 mm pad length)

A quick sanity check with the ruler confirmed everything matched the datasheet — the 0.62 mm gap between rows and 2.6 mm overall dimensions were spot on.

Updating the PCB

It took a bit of finagling — I had to make some traces slightly thinner so they didn’t collide — but the new footprint dropped into the design nicely.

The 3D preview looks good. Obviously the proof of the pudding will be the next production run, but it matches the datasheet now — so fingers crossed it will eliminate this class of QA errors.

Wrapping Up

If you’re designing PCBs, don’t assume that a standard package name means a standard footprint. Always cross-reference with your specific component’s datasheet. It only takes a few minutes to create a custom footprint in KiCad, and it could save you from chasing down mysterious assembly failures.

MAX30102 $3 Heart Rate Monitor

Sun, 15 Mar 2026 00:00:00 +0000

Building a Heart Rate Monitor with an ESP32-C3 and MAX30102

You know how it is. You buy one cute little module from AliExpress and then think “it looks lonely, I’ll get another”. Before you know it, you’ve got a drawer full of cute little modules. So it’s time to put one of them to work.

The ESP32-C3 Board

I’ve got a bunch of these tiny ESP32-C3 boards kicking around. Let’s take a look at one under the microscope.

The brains of the operation is an ESP32-C3 with built-in flash — four megabytes of it, which is pretty decent.

There’s a 3.3 volt regulator on board, and the soldering looks nicely done. It’s a pretty clean, well-designed little board. The antenna is a ceramic one on the side — though I’ve read a few people saying that on these tiny compact boards you don’t get much Wi-Fi signal due to the antenna placement being a bit too close to the buttons and other components. So we’ll avoid Wi-Fi for this project.

The MAX30102 Heart Rate and Blood Oxygen Sensor

For the actual sensor, I’m using a MAX30102 module — a heart rate and blood oxygen monitoring board that I picked up in a recent AliExpress order.

The board has a 3.3 volt boost regulator and a 1.8 volt regulator. Some people have reported finding a 2.8 volt regulator instead of 1.8 on some boards — it’s worth checking yours is correct. Mine was fine.

How the Sensor Works

The really interesting part is the sensor itself. Under the microscope you can see:

Two LEDs behind a window — a red LED and an infrared LED
A photodetector with a bunch of DSP processing built in

The outputs from this device are just the value of the red channel and the value of the infrared channel. You stick your finger on top and it detects pulse rate using the red LED and blood oxygen levels using the infrared LED.

When you power it up, you can easily see the red LED. If you cover it up and move the lights away, you can even see a slight glow from the infrared LED — the camera on the microscope picks it up nicely.

Wiring It Up

The wiring is pretty simple — it’s just I2C plus power:

const byte oxiInt = 2; // pin connected to MAX30102 INT
const int SENSOR_I2C_SDA_PIN = 5;
const int SENSOR_I2C_SCL_PIN = 6;

Pin 6 → SCL
Pin 5 → SDA
Pin 2 → Interrupt (tells us when data is ready)
5V → Vin (the board has its own 3.3V regulator)
GND → GND

A quick I2C scan confirms everything is connected properly — two devices show up: the I2C display and the heart rate monitor.

The Code

The main loop reads samples from the MAX30102 into a ring buffer, then runs the heart rate and SpO2 algorithms once the buffer is full:

void loop() {
  float n_spo2, ratio, correl;
  int8_t ch_spo2_valid;
  int32_t n_heart_rate;
  int8_t ch_hr_valid;

  // Read UPDATE_STEP new samples into the ring buffer
  for(int32_t n = 0; n < UPDATE_STEP; ++n) {
    readNextSampleIntoRing(data_ready_timeout_us);
  }

  // Need a full buffer before we can calculate
  if(sample_count < BUFFER_SIZE) return;
  buildOrderedWindow();

  // Calculate heart rate and SpO2
  rf_heart_rate_and_oxygen_saturation(
    ordered_ir_buffer, BUFFER_SIZE, ordered_red_buffer,
    &n_spo2, &ch_spo2_valid,
    &n_heart_rate, &ch_hr_valid,
    &ratio, &correl);

  // Median filter smooths out noisy readings
  hr_filter.push(ch_hr_valid ? n_heart_rate : INVALID_HR);
  spo2_filter.push(ch_spo2_valid ? n_spo2 : INVALID_SPO2);

  updateDisplay(filtered_heart_rate, (int32_t)filtered_spo2);
}

The display code is pretty straightforward — just show the heart rate and oxygen percentage on the tiny OLED, or dashes if we don’t have a valid reading:

static void updateDisplay(int32_t hr, int32_t spo2) {
  u8g2.clearBuffer();
  u8g2.setFont(u8g2_font_10x20_mr);
  u8g2.setCursor(0, 19);
  if (hr >= 30 && hr <= 250) {
    u8g2.printf("HR: %d", (int)hr);
  } else {
    u8g2.print("HR: --");
  }
  u8g2.setCursor(0, 39);
  if (spo2 >= 0 && spo2 <= 100) {
    u8g2.printf("O2: %d%%", (int)spo2);
  } else {
    u8g2.print("O2: --");
  }
  u8g2.sendBuffer();
}

There’s also a nice touch — the on-board LED flashes in time with your heartbeat.

Getting Readings

With the sketch uploaded and the OLED display showing results, it’s time to test.

It can be a bit finicky about finger placement — you need to keep it very still. But once it settles, it starts producing results: heart rate and SpO2 percentage.

Comparing to a Commercial Device

The real test — how does it compare to a proper pulse oximeter?

With both running side by side:

Heart rate: around 70 BPM on the ESP32-C3, matching the commercial monitor
Blood oxygen: 99% on both devices

Not bad at all. The main challenge is keeping your finger positioned accurately without squishing it on — it’s quite easy to lose the reading. But when you get a good contact, the results match up well.

Wrapping Up

The full code is on GitHub. Grab yourself one of these ESP32-C3 modules, a MAX30102 sensor, and a little OLED display, and you can build something equivalent to a commercial pulse oximeter for very little money. It’s a fun project — why not try it out?

I Made My ESP32-S3 Faster by Optimizing for SIZE — Not Speed

Fri, 06 Mar 2026 00:00:00 +0000

Optimizing ESP32-S3 Performance: Why Smaller Code Can Ran Faster

I’ve been tuning the performance of some code recently on an ESP32-S3 project,

There was a slightly counter-intuitive result that might surprise some people: optimizing for code size produced faster runtime performance than optimizing for performance.

There’s a full video here - but you can skim this post for most of the information.

The Benchmark

This is just some code that I pulled out of my latest project. It’s not an official piece of benchmarking code. So your mileage will definitely vary and you shohld do your own tests on your own code.

I kept my test case was deliberately simple and pulled out the most performance critical part of my code.

The code, input data, and hardware stayed constant throughout. Only ESP-IDF configuration options were changed between runs.

Baseline Results

Starting from a stock ESP-IDF configuration (I used their hello_world starter app), the decode took roughly 1.4 seconds.

From there, I explored a few of the usual performance levers:

CPU frequency (an obvious one!)
Compiler optimization level
Flash SPI mode
Cache configuration

CPU Frequency: The Obvious Win

Unsurprisingly, increasing the CPU frequency from 160 MHz to 240 MHz produced an immediate improvement.

The result was roughly the 1.5× speed-up thst you woulld hope for (it was actually around 1.46 - but close enough).

Compiler Optimizations: Size vs Speed

ESP-IDF menu config offers two commonly used optimization modes:

Optimize for size (-Os)
Optimize for performance (-O2)

Weirdly, in my first job (many years ago!), this was discussed in quite detail.

You naively expect that -O2 should be faster than -Os. In this case, it wasn’t.

With this workload, -Os outperformed -O2 quite significantly. They both beat the debug build - but -Os improved it the most.

Why Would Smaller Code Be Faster?

On the ESP32-S3, application code normally runs from flash memory with an instruction cache (you can actually copy code into PSRAM if it’s available which can be faster than flash).

Flash is pretty slow which means the CPU caches can have a significant impact.

instruction cache size
cache line fetches
cache miss penalties

Optimizing for performance often:

increases inlining
unrolls loops
duplicates code paths

All of this increases code size, which can lead to more instruction cache misses and more reads from the flash.

Optimizing for size does the opposite: it produces tighter code that is more likely to stay resident in the cache, reducing stalls caused by flash fetches.

In this workload, that effect outweighed the benefits of more aggressive instruction-level optimizations.

Flash Mode and Cache Configuration

Because the GIF was embedded in flash and accessed frequently, flash bandwidth also mattered.

Two changes helped further:

Switching the flash SPI mode from DIO to QIO (chack that your module supports this!)
Increasing instruction and data cache sizes to their maximum values

These changes reduced the cost of cache refills and improved overall throughput.

Interestingly, once the caches were enlarged, -O2 did improve — but it still didn’t beat the -Os configuration with the same cache settings.

The Winning Configuration

For this benchmark, the fastest setup was:

CPU frequency: 240 MHz
Compiler optimization: Optimize for size (-Os)
Instruction & data cache: maximum (turn it up to 11!)
Flash SPI mode: QIO

This combination produced the lowest overall decode time.

This is the case for my specific workload!

It’s important to be clear about the limits of this result.

You may not see the same behaviour if:

Your hot code runs entirely from the instruction cache or IRAM
Your workload is dominated by tight math loops on small datasets
You’re memory-bandwidth bound on internal RAM rather than flash

In those cases, -O2 or even more aggressive optimization may still win.

Full Results Table

Build type	usecs	ms	% of baseline
Baseline	1425476	1425.48	100
240MHz	965408	965.4	67.72
240MHz + Os	872495	872.5	61.21
240MHz + O2	962329	962.3	67.50
240MHz + Os + QIO	861859	861.9	60.46
240MHz + Os + QIO + caches	843286	843.3	59.16
240MHz + O2 + QIO + caches	933093	933.1	65.46

Conclusions

Performance is often limited by memory and caching, not raw CPU execution.

Smaller code can mean fewer cache misses - and fewer cache misses can mean faster code.

If you’re working on performance-critical ESP-IDF projects, it’s worth benchmarking -Os alongside -O2.

If you’ve tried similar experiments on other ESP32 variants, I’d love to hear what you found.