Quick Build: House Number Sign

Sun, 01 Nov 2026 00:00:00 +0200

A Party!

I’m coming up, so you better get this party started
— P!nk

Friends of mine recently moved house and were kind enough to invite me to their house warming party. I figured that I ought to show some proper house warming party etiquette and bring a gift. It would be inappropriate not to. Certainly now that they have so much extra space to stash away all those gifts.

But what to bring?

I decided to go for something that’s becoming a bit of a speciality of mine: a colorful, illuminated object. This time said object took the shape of my friends’ house number. In 3D!

Quick Build, Long Read

I tried a new concept with this project. I normally adhere to longer-running projects that take much preparation. As the title suggests, this was to be a quick project. The kind of build that can ideally be completed within a weekend, but no more than two, with minimal preparation beforehand. You’ll find out in due course whether or not I succeeded in meeting that timeline. The length of this article might give away the answer already…

So, a quick build. The idea is: collect the materials, grab the tools, start making and see what it brings. To some people this is second nature. To me, it’s very far from. I crave a detailed plan and prefer a near perfect result. That puts the whole concept firmly outside my comfort zone. Also, as anyone who has ever worked with me will attest: I’m a nightmare at planning.

The reporting for this one will also be of a different kind. Not a multi-part blog series, but a single write-up that covers everything. That does mean it will be longer than what I usually write. I tried not to be too long-winded, but I did want to put in enough details and some background information. If you have a short attention span, this one may not be for you. On a positive note: there are lots of pictures here!

The Plan

The plan was to make an oversized house number sign, with 3D-printed numbers and addressable LEDs. I wanted my friends (or their kids) to be able to change the colors of the LED at their leisure. That meant a microcontroller and some good old push buttons.

Given the intended time span of four days max, I figured I shouldn’t put to much time in devising a software driver for the LEDs. I downloaded an open source driver for that. Having the driver taken care of would allow me to focus on the application for changing the colors. As for the electronics: a piece of perf board with four push buttons and a low cost microcontroller would do.

Can’t be too hard.

Or can it?

The Tools

A quick work on the tools used.

For the 3D-design I used FreeCAD¹ and the software was developed using the Code::Blocks² IDE. Both are free and open source tool that I highly recommend.

There were of course some physical tools involved as well, but not many. First of all a 3D-printer (I use an Ender 3 V2 Neo) and some woodworking tools (a router and a table saw). That, and a soldering iron, naturally.

Bright LEDs

The LEDs used here are the well known WS2812³ addressable RGB LEDs. Also known as Neo-pixels. I had never worked with them before, but after I studied the datasheet I decided that I liked them.

The WS2812 are LEDs with an integrated driver. They are controlled by a pulse width modulated signal on a single input pin. PWM is often used as low-cost way to control the brightness of LEDs. However, with the WS2812 the PWM is actually used to modulate the data. What I like about this approach, is that it allows for a brilliantly simple way to send a self-clocked data stream over a single wire. The PWM frequency is approximately 800kHz. A low bit is represented by a short pulse (220 to 380ns), a high bit by a long pulse (580 to 1000ns).

The datasheet isn’t very clear about how the actual brightness control of the LEDs is achieved. However, there is some information in the datasheet of the integrated driver, the WS2811⁴. It’s not specified very clearly, but it mentions a constant current driver.

Getting Into Characters

Now lets discuss the project.

The first stage of the operation was to quickly start 3D-printing. Printing takes time but I can work on other things while it’s happening. However, the printer won’t do anything without a sliced 3D model. So, drafting the models had to take priority.

I used the Draft workbench as well as the Part workbench in FreeCAD to design the 3D numbers. I had never worked with text shapes before but I found a useful tutorial⁵ by Mango Jelly Solutions⁶ at YouTube that demonstrates nicely how it can be done.

Showing the numbers

The 3D numbers needed a semi-transparent cover to diffuse the light. I wanted to print these covers with a rim that would fit snugly into the lower part of the assembly. That way both parts would self-align, making them easier to assemble.

Unfortunately this didn’t work out the way I envisioned it. I printed the covers from a different material than I used for the numbers. Since I didn’t do a flow tuning for this material, the covers turned out to be slightly larger than the numbers themselves and wouldn’t fit. I tried scaling the models in the slicer, but TrueType fonts don’t scale linearly so that didn’t work. I settled with flat covers instead. They were a bit harder to install but worked well enough.

It’s hard to tell which one is best

A Problem To Address

To control the LEDs, I picked the Light WS2812 library⁷ (link below). It’s a lightweight C library to send an array of RGB data to a string of LEDs. I was quite impressed to read that this library supposedly works on hardware as low-end as an Attiny at 4MHz. The Light WS2812 library uses GPIO - rather than a PWM peripheral - to generate the PWM data. In order to make this work, it disables all interrupts during data transmission. The timing is critical and the data transfer should not be, well, interrupted.

For the hardware I opted for a minimalist setup with an Attiny85⁸, running at its internal 8MHz RC oscillator. Given the short timeline for this built I soldered everything (the MCU and some buttons) on a piece of perf board. This took me a surprisingly long time to solder. And the result was… rather ugly.

I hate perf board

Then came the time to test the library. I had some reservations about an 8MHz Attiny being able to accurately send out an 800kHz data signal. 800kHz May not sound like a lot, but at 8MHz the MCU only gets 10 clock cycles to process one data bit. That’s not much. To encode a low bit, the processing time is even less: about two clock cycles.

For a quick test I modified the demo code that came with the library to turn the first 4 LEDs of my test setup red. This is what I got.

It’s like red, but not quite

Not exactly what I wanted to see.

So what went wrong here? Lets have a look at the signal below. The low bit pulse is an order of magnitude longer than the nominal 300ns. It is also far beyond the pulse length that the WS2812 interprets as a high bit. This means that every pulse is interpreted as a high bit, so the LEDs actually receive RGB data that looks like 0xffffff. If you’re not that adept at converting hexadecimal to color: that’s white. The LEDs worked perfectly fine, but the data was off.

Attiny bit too slow…

The 10x factor between the expected pulse time and the actual signal is odd to say the least. I checked the timing of the microcontroller beforehand (albeit at a lower frequency) and everything seemed in order. The CPU prescaler was also configured to 1x (i.e., running on an undivided clock). I was unable to satisfactorily explain the difference but it fits in my hypothesis that the MCU is simply too slow. But that may be confirmation bias.

I decided to move on and try a different approach to control the LEDs. In hindsight however, I realized that I could have tried compiling the code with speed optimization enabled. The library documentation does not mention the necessity to speed optimize, though.

Another Problem To Address

If the microcontroller is too slow, than a faster one should solve the problem. I happened to have just such a controller sitting on my workbench: an STM32G030⁹ that I’m using for another project. I also decided to drop the off-the-shelf library all together. The STM32G030 runs at 64MHz, that’s an 8x speed increase from the Attiny85.

To test the concept, I created a test program that generated a signal to represent one green LED. It worked perfectly fine.

We have green light!

I went on to write another test program that takes the RGB data as an array and then sets the pulse length for each bit in an ISR. (The STM controller can generate an interrupt each time the output compare event occurs, i.e., when the pulse transitions from high to low. The interrupt handler can then calculate the length of the next pulse and write it into the output compare register for the next cycle).

Like the Attiny program, this one also did not work as expected. It didn’t give me white LEDs, but a more or less random color pattern. Very decorative, but not quite what I wanted.

Time to hook up the oscilloscope once more.

Scrambling (the data) to keep up

The plot above was supposed to show a pattern of alternating low and high bits (or, short and long pulses). But that’s not what the oscilloscope tells us. If you look at the plot closely, you’ll notice that a short pulse is followed by a long pulse, as expected. After the first long pulse however, comes another long pulse. What I expect happens here is this: the controller starts determining the pulse length of the next pulse at the falling edge of the signal. This data has to be written to the output compare register before the next rising edge. This means that the controller has a lot less processing time available to work out the next value after a high bit has been sent.

To confirm this theory, I increased the Timer prescaler. This results in the timer (and thereby the PWM generator) running at a lower frequency while the CPU remains at the same clock speed.

Good data, in slow-mo

That’s that theory confirmed: another speed issue. The time that’s available between pulses is insufficient to calculate the pulse length for the next bit.

Conclusion: the second approach also failed. Although in hindsight, I should have tried speed optimization.

Just Ram That Data Into Place

With my brilliant (overly optimistic) plan falling to pieces before my eyes, I tried yet another approach: DMA.

Processing each data bit in an interrupt handler adds some overhead to the code execution. For each bit, the CPU has to push its current state to the stack, jump to the ISR, handle the interrupt, clear the interrupt flag, restore the previous state from the stack and then continue from where it was. It would be faster to do the processing first and store the pulse lengths in memory. Then the Timer peripheral can fetch the data when it feels up to it.

Direct Memory Access is just the thing for that. Each time the output compare register needs updating, it reads the new pulse length directly from memory without making a demand on the CPU. No interrupt handling needed.

I tested this concept with yet another test program: It worked like a charm. I was so impressed that I forgot to take a picture of the result.

There was just this one ramification (pun intended): this takes a lot of RAM. One byte for every bit. That’s 24 bytes for each LED. There will be 80 LEDs in my build, so 1920 bytes. That’s a lot of memory. But I had another concern first.

Where Did The PWM Go?

The board I tested the DMA trick on was intended to be used for something else. Luckily, I had a spare board from my Party Lights project and also the microcontroller that lives on it. By a happy coincidence, the IO pin that controls the serial transmitter in that design can also be used as a PWM output. What’s more, It has a level translator. That’s fortunate, because the WS2812 is a 5V device while the MCU runs on 3.3V.

The board needed some small modifications, like jumpers and a series termination resistor for the output signal.

The light controller rides again!

I made a few modification to make the code work on the new MCU, an STM32F042¹⁰. That involved changing the IO configuration, Timer settings and DMA setup. Then I reconnected the LED strip and powered up.

Nothing happened whatsoever.

It looked like a classic case of ‘It worked on my machine’. But where did it go wrong?

In search of the culprit I figured I should start with the basics: does it do any PWM at all? It turned out it didn’t. But why? The timer appeared to be set up correctly and was running (it triggered an interrupt). But no PWM.

The reason, it turned out, was in the type of Timer peripheral. STM32 MCUs have different Timer/Counter peripherals and there are some distinctions between those. I tested my program on a General Purpose timer. When I migrated to the STM32F42 however, the timer associated with my IO pin of choice was an Advanced timer. And those need some extra configuration.

Advanced Timers on the STM32 family have extra features that allow them to be used in motor controllers. This involves some safety features like the ability to disable the PWM outputs when a safety signal (or Break Input) is received. This can be used to implement an emergency stop.

It so happens that the PWM outputs on an Advanced Timer peripheral are disabled by default. To enable them, the Master Output Enable (or MOE) bit has to be set. This is frustratingly hard to find in the reference manual and STMicroelectronics don’t feel like emphasizing the importance of this single control bit. I read about it in a blog post at EmbeddedExpert.io¹¹.

With the Master Output Enable bit set, the pulse width modulation was alive again.

Speed Is Everything

Software engineers always warn against a thing called early optimization. The idea is not to optimize anything until everything works and there is time to spare. And also not to optimize unless you completely understand what you’re doing.

I however, am not a software engineer. And that data buffer just shy of 2kb felt horrendously inefficient. I wanted to fix that. Surely that couldn’t be too hard.

The DMA controller in an STM32 can generate an interrupt twice every transfer: one when the transmission is half way, and another upon completion. This way a circular buffer can be implemented. I choose a 48 byte buffer to store the pulse lengths for two LEDs. While the data for one LED gets transmitted, the data for the next gets calculated. The CPU works while the DMA controller takes care of the transmission. This skips the overhead for the interrupt handler.

In the next version of the software I implemented this method.

It didn’t work.

What I got instead was the same garbled frame that I got with my earlier STM32 test. Probably a timing problem, again. Apparently the processing time to generate the pulse lengths for one LED takes more time than transmitting the data. Even without the interrupt handling overhead.

One PWM pulse takes 1.25us. So, transmitting 24 bits takes 30us. The processing time is hard to estimate, but can be measured externally. I toggled a spare IO pin at the beginning and end of the data processing routine. This way the oscilloscope can show the time in between. It’s the green curve in the plot below.

Just too late delivery

That’s approximately 50us. Or 20us too long.

And then I remembered speed optimization.

-O my!

Nailed it at last! The humble -O3 flag brought a stunning 2.5x improvement in processing time. Seriously though, is my programming that bad?

Customizing The Colors

With communication now in place, I was able to whip up an application that allows the user to set the colors of the individual LEDs.

The final version of the hardware got 3 buttons. An OK button to enter edit mode or confirm a setting, and up/down buttons to select a value.

In edit mode the user can first select a region of consecutive LEDs that they want to edit. After confirming their selection they can select one of 32 preset colors. The drill repeats until all the LEDs are set.

When not in edit mode, pushing the up/down buttons sets the brightness of the LEDs.

There was only this one inconvenience: power cycling the controller would revert everything to the default color.

Not a Storage Problem, Too!

The Attiny MCU that I initially wanted to use comes with non-volatile data storage in the form of an on-chip EEPROM. EEPROM is of course a bit old-fashioned and flashy microcontrollers like the STM32F042 don’t have that anymore. So where to store the beautiful color sequence that the user so elaborately entered with just those three buttons?

The good news is that we don’t need a dedicated storage device. The Flash memory that holds the program is self-writable. This means that the program can make modifications to it while it runs. This is often used to allow the firmware to install updates. The program can also use any excess storage space to store data. This is of course provided that the memory location in question does not hold the program code.

As I had at this point already overrun my targeted completion date, I didn’t feel like reinventing the wheel for data storage. I had after all already reinvented the wheel for LED control. Luckily the developers of the LibopenCM3¹² HAL that I use for STM32 microcontrollers offered a helping hand. They provide numerous code examples for their library. Among which is a flash storage example¹³ that was ready to use.

I implemented the flash storage for the color pattern and brightness, reloaded the application and changed some colors. Then I power cycled the controller and I got this:

One stoically unchanged pixel

The very last LED of the sequence kept returning to its default color (which is red, in case you missed it). But why?

I checked for bugs in my application and found none. Then I checked for bugs in the Flash store and recall functions that I got from LibOpenCM3. Found no bugs there either. But it did provide an important hint as to what I was doing wrong: it works with 32 bit words. This is kind of obvious because the STM32 is a 32 bit microcontroller so the registers are 32 bits wide. The data that I tried to store however, were a bunch of 8 bit integers. In order to store those, they have to align in 32 bit blocks.

What I tried to do was store eighty color values (8 bits each; just the hue for each pixel), plus one 8 bit integer for the brightness. That’s eighty-one bytes, or twenty 32 bit words plus that remaining byte. The storage function fetches four 8 bit chunks each and writes them to Flash. The remaining one byte, however, gets ignored. Since that final byte represents the color of the last LED (the brightness value is in the first element of the array), that data was not being saved.

The solution was to simply increase the length of the data array so that it wholly consists of 32 bit blocks (i.e., a number of bytes that’s divisible by 4).

All Aboard!

Right. On to the easy part!

The 3D-printed numbers needed to be mounted to something rigid, and that something also had to hide all the wiring. I choose two sheets of 9mm plywood, glued together to form - you guessed it - an 18mm board. To hide the wires to the LEDs, I routed a groove into one of the sheets. Masking tape kept the wiring in position during construction. After that I hoped the universe would not present me with any broken wires once the glue dried.

Groovy!

After applying a layer of varnish, the numbers were ready to be mounted.

No quick build without duct tape

The addressable LEDs were mounted with doubled sided adhesive tape. I also added some aluminium tape opposite the LEDs to act as a reflector. The LED strips also got a small (1uF) capacitor to stabilize their supply voltage.

Upon reflection, the aluminium does improve the light quality

The last remaining step of the assembly was an enclosure for the controller. It’s a simple box that’s screwed onto the back of the plywood board. A spacer holds the circuit board in place after assembly. The push buttons just stick out of the front on the box. Power is provided by an off-the-shelf USB-C receptacle that slides into a slot at the side of the box.

No quick build without hot glue

To prevent the whole assembly from only being used face down, I printed a stand for the panel as well.

The project as it stands

And with that, I had my present ready at last!

Wrap It Up

Time to wrap up. Literally.

I have to say it was quite the journey to get this quick build built. In hindsight the goal of making the whole thing in one weekend sounds ludicrously over optimistic. But then again, I’m a nightmare at planning so, what should I have expected?

How long did the project end up taking? About 6 six days in total. That’s not including any documentation or this blog post. It could definitely have been done in two weekends, had I not run into so many issues.

On the other hand, the build not being all smooth sailing made it all the more educative. I learned how control the WS2812 LEDs and discovered the DMA controller on the STM32 microcontroller. I also learned that those software developers who are reluctant to optimize prematurely may have a point after all…

Repository

The firmware for this project is available from my Codeberg repository as always. I also included a reference design for the hardware. The printed numbers and the controller enclosure are not included as they are too specific to be of any relevance for others.

WS2812 on project392.net