CONTENT

Once upon a time, a friend of mine, has got her hands on a cheap batch of the lovely HCMS-2904 display modules. And so the search for their applications began.

Since we didn’t get many of them, it would be ideal to have something where a single display per device could plausibly be used.

A tiny panel voltmeter came to mind as a possible, albeit a bit lame, option.

Minivolt in its natural habitat

This project was originally undertaken some time in mid-to-late 2021.

These HCMS-2904 display modules are extremely easy to use - they simply contain a shift register containing the state of all pixels to be displayed! This means, one can display arbitrary graphics on these!

(But, beware, not all HCMS/HDSP LED display modules are this flexible - even those that look quite similar!)

Some prototypes have been quickly whipped up to showcase the display’s capabilities:

PCB Design

A circuit board has been designed for the panel voltmeter application, featuring an ATTINY44A microcontroller, featuring a modest 10-bit ADC. This allos for some 4 mV resolution with a 4.096 V reference voltage.

The PCB is very simple, even too simple, since there is no integrated voltage regulator. It simply hosts the microcontroller, input voltage dividers for main and auxilliary input channels, a voltage reference, and… that’s all.

Here is a schematic for the current PCB version.

Yay, circuit boards

Power Supply

Minivolt is meant to be fed regulated +5V, directly powering all its components.

There was an intention of Eventually™ creating a “piggyback” voltage regulator board, tailored for the individual usecase for this panel meter. Since no such usecase has come yet, neither did this board :)

I really should have added at least a footprint for some 7805-style voltage regulator, even if it doesn’t end up being used in some cases.

Voltage Reference

The voltage reference that was designed in was an LM4040. However, at the time of PCB assembly, none of my preferred component suppliers had any! Annoyingly, the LM4040 is a shunt-style 2-terminal device, and it is pin-incompatible with the (oddly more common) 3-terminal voltage references…

I had to improvise, and ended up using an MCP1541 instead.

The usual footprint hacks

A 4.096V reference has been selected, as by the display specs, the LED supply voltage range is 4.0~5.5 V. This limited the supply voltage to 5V, and picking the highest appliccable reference voltage was thought to improve noise immunity.

A power-of-two value also seemed helpful, possibly eliminating some costly non-integer conversion factors in software. (= no floats necessary)

Display Socket

The HCMS-2904 display is socketed, as I wouldn’t dare “irreversibly” soldering down such a beautiful display if I could at all avoid it. :)

But, that is not the only reason for a socket: The MCU used here is fairly limited in its pin count, and so I had to use some of its programming pins to drive the display, too.

So, to flash new firmware, one now has to unsocket the display, plug in a programming “jig” (another socket with the programming cable already wired onto the correct spots), and upload. Then remove this jig, put the display back on, and test :) Somewhat inconvenient.

However, care seems to have been taken to connect the programming pins to those lines of the display that would likely not be damaged, should one dare to reprogram the MCU while the display was connected. However, this has not been tried yet.

Firmware

A “simple” driver code for the HCMS-2904 displays has been written and originally tested with an Arduino Micro.

However, since I have been a rather stupid Java dev by trade, I did not at all optimize anything quite enough for the available memory size on the smaller ATTINY44A device…

So, while the current software is “working”, it is only working by chance when the firmware size is “just right”, leading to some unexpected weirdness/touchiness whenever some miniscule code changes occur, leading to some unrelated “ghost hunts” instead of tackling the real problem…

I shall optimize it some day. There really is no need to store a frame buffer on the microcontroller itself, taking up most of the available memory, for instance.

But, until I do so, the firmware sources will remain unpublished, left as an exercise to a keen reader.

Lessons learned