Forem: Alex Rosito

The Constraint Is Gone. The Discipline Isn't Optional."

Alex Rosito — Sun, 03 May 2026 04:21:50 +0000

This is part three of a series on display consistency in embedded systems. The first two parts were technical. This one is about why the technical parts worked.

The picture:

ATtiny85 thermometer. Neural network inference. QUAD7SHIFT display. Built from datasheets.

"For the skeptics:"


Scanning dependencies...
Dependency Graph
|-- nnetwork
|-- QUAD7SHIFT @ 1.0.7
Building in release mode
Compiling .pio/build/attiny85/src/main.cpp.o
Linking .pio/build/attiny85/firmware.elf
Checking size .pio/build/attiny85/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]  10.9% (used 56 bytes from 512 bytes)
Flash: [======    ]  57.6% (used 4718 bytes from 8192 bytes)
Configuring upload protocol...
AVAILABLE: usbtiny
CURRENT: upload_protocol = usbtiny
Looking for upload port...
Uploading .pio/build/attiny85/firmware.hex

Steve Wozniak Didn't Have a Framework

He had datasheets.

No Stack Overflow. No libraries to install. No AI to generate boilerplate. No tutorials that abstracted away the inconvenient parts. Just component specifications, logic, and the discipline to read until he understood.

The result was an architecture that engineers still study today.

That's not a coincidence. And it's not genius that can't be replicated. It's what happens when you have no choice but to understand the hardware before you write the code.

What Gets Lost When the Abstraction Hides Too Much

Modern embedded development has never been more accessible. Frameworks, package managers, community libraries — you can have a working prototype in an afternoon without understanding a single register.

That's genuinely useful. It lowers the barrier. It lets more people build things.

But it also produces a generation of firmware that works until it doesn't — and when it doesn't, nobody knows why. Because the person who wrote it never read the datasheet. They installed a library, called a function, and assumed the details were handled.

Sometimes they are. Sometimes they aren't. And the difference between those two cases is invisible until something goes wrong.

The Counter That Stayed With Me

There's a specific moment that illustrates this better than any argument.

A teacher handed out breadboards, components, and a schematic. The goal: build a single-digit counter, 0 to 9, triggered by a button press.

No microcontroller. No code. Just logic gates, a flip-flop, a seven-segment display, and the understanding of why each component was there.

When it worked — when pressing the button changed the digit — something became clear that no textbook had made clear before: the hardware responds to principles, not to instructions. If you understand the principles, the hardware does what you expect. If you don't, you're guessing.

That lesson is older than Arduino. It's older than C. It applies today exactly as it did then.

What This Has to Do With QUAD7SHIFT

QUAD7SHIFT is a small Arduino library. It drives a four-digit seven-segment display through two cascaded 74HC595 shift registers. It has zero stars on GitHub from the day it was published until a Chinese technical site cited it as a reference implementation for eliminating display flicker — without being asked, without knowing the author, because they were looking for something that worked correctly and found it.

It works correctly because before writing a single line of code, the 74HC595 datasheet was read. The latch mechanism was understood. The difference between the shift register and the storage register was clear. The decision to transfer 16 bits atomically and pulse the latch once was a direct consequence of that understanding — not a clever optimization, not a trick. Just the obvious thing to do when you know what the hardware does.

The flicker that plagues most 74HC595 display drivers has been showing up in Arduino forums since 2016. Thousands of views. Dozens of threads. The symptom described repeatedly, the root cause never identified — because the root cause is in the code, and the code was written without reading the datasheet.

The Principle Doesn't Age

Processors change. Frameworks come and go. The 74HC595 is a 40-year-old chip that still ships in millions of units per year because the underlying logic — shift data in, latch it out atomically — is correct and has always been correct.

The engineers who understand that logic write drivers that work. The engineers who skip it write drivers that mostly work, until they don't.

This is not an argument against modern tools. Use frameworks. Use libraries. Use AI assistants. They save real time and they solve real problems.

But know what's underneath. Read the datasheet at least once. Understand what the latch does before you decide when to pulse it. Know why shiftOut() is bit-banging and what that means for interrupt safety.

The tools change. The hardware doesn't lie.

The Old School Isn't Obsolete. It's the Foundation.

Wozniak had datasheets. The engineers who built CP/M had datasheets. The people who designed the TI-99/4A had datasheets. They understood their hardware completely because they had no alternative.

That constraint produced discipline. That discipline produced systems that worked correctly for reasons their authors could explain.

The constraint is gone. The discipline is optional now.

But the hardware still responds to principles. And the principles haven't changed.

Alex Rosito — self-taught electronics engineer. ATtiny85 · ESP32 · KiCad · C++

GitHub: AlexRosito67

Frame Consistency in Embedded LED Systems Why hardware drivers like MAX7219 don’t solve the real problem

Alex Rosito — Thu, 30 Apr 2026 17:48:45 +0000

After the 74HC595 flicker article, someone will inevitably ask: "Why not just use a MAX7219? It handles everything in hardware." It's a fair question. The answer is more nuanced than most tutorials admit.

The MAX7219 Is Not a Solution to a Software Problem

The MAX7219 is an excellent chip. It handles multiplexing internally, provides constant current regulation, has its own digit buffer, and communicates over SPI. Compared to two cascaded 74HC595s and hand-rolled multiplexing, it looks like a massive upgrade.

And for hardware reliability, it is.

But here's what nobody tells you: the MAX7219 doesn't know what a valid display state looks like. That's still your job.

What the MAX7219 Actually Takes Off Your Plate

To be fair, let's be specific about what it solves:

Multiplexing timing — handled internally, no refresh loop needed in firmware
Ghosting from latch timing — not a problem because the chip manages its own output stage
Brightness control — built-in PWM, adjustable via SPI command
Constant current — no current-limiting resistors per segment

That's real. That's valuable. If you're moving from bit-banged 74HC595 code to MAX7219, you will see immediate improvement.

What It Doesn't Solve

Here's the part that gets skipped.

Most firmware that drives a multi-digit display still does something like this:

// Update the display with new sensor reading
max7219.setDigit(0, units);
max7219.setDigit(1, tens);
max7219.setDigit(2, hundreds);
max7219.setDigit(3, thousands);

Four separate SPI transactions. Four separate moments where the display is in a partially updated state.

If an interrupt fires between digit 1 and digit 2 — maybe a timer ISR, maybe a sensor read, maybe a UART receive — the display briefly shows a mix of old and new data. The hardware is stable. The frame is not.

The MAX7219 didn't create this problem. It just didn't eliminate it either.

The Real Problem: No Concept of a Frame

The issue is architectural. Most embedded display code has no explicit notion of a complete frame — a moment where all digits are updated atomically and the display shows a coherent state.

Instead, it updates digits one at a time, sequentially, and assumes the whole thing happens fast enough that nobody notices. Usually that's true. Sometimes it isn't — and when it isn't, you get artifacts that look like hardware problems but aren't.

This is the same class of problem as the 74HC595 latch issue, operating at a higher level.

With 74HC595: the problem is at the shift register boundary — partial hardware state during transfer.
With MAX7219: the problem is at the firmware boundary — partial logical state during multi-register update.

Different layer, same root cause.

What QUAD7SHIFT Does That Generalizes

When I built QUAD7SHIFT, I didn't think about any of this explicitly. I just transferred all 16 bits — segments and digit select — in one atomic SPI transaction, then pulsed the latch once. The display never saw a partial state because the design never created one.

That rule — never expose a partial frame to the output stage — turns out to be hardware-independent.

It applies to 74HC595. It applies to MAX7219. It applies to LED matrices driven by MAX7219 chains. It applies anywhere you have a display with more than one register to update.

The implementation changes. The principle doesn't.

A Practical Mental Model

Think of it in two layers:

Layer	What it guarantees
Hardware driver (MAX7219)	stable, flicker-free scanning of whatever is in its buffer
Firmware	that what's in the buffer is always a coherent state

The MAX7219 is excellent at the first layer. It does nothing about the second.

If your firmware never writes partial states — if every update is atomic — then the hardware driver has nothing to hide and everything works cleanly. If your firmware writes partial states, the hardware driver will display them faithfully, partial states and all.

The Next Article

This is part two of a series. The third part steps back from the hardware entirely — and asks why these principles work in the first place.

Alex Rosito — self-taught electronics engineer. ATtiny85 · ESP32 · KiCad · C++

I Built a Useless Data Structure in C++17 and Learned More Than Any Tutorial Taught Me

Alex Rosito — Wed, 29 Apr 2026 05:39:57 +0000

I built this because I was bored. No real use case, no production target — just a C++17 exercise to shake off the rust and explore techniques I knew existed but had never actually used. What I didn't expect was how much the implementation taught me about things I thought I already understood.

The Problem With Homogeneous Lists

Every linked list tutorial shows you the same thing: a list of integers, or a list of strings. The node holds one type, the list holds nodes of that type, done.

That works — until you want a single list to hold an integer, a float, a string, and a custom struct at the same time. Then the standard approach falls apart immediately, because the type is baked into the node at compile time.

The question becomes: how do you build a node that doesn't care what it holds?

The Polymorphic Base — The "Wow" Moment

The answer is a polymorphic base class. Instead of a templated node that holds T directly, you separate the concerns:

// Base class — type-erased, polymorphic
class Object {
public:
    virtual ~Object() = default;
    virtual void print(std::ostream& os) const = 0;
    virtual bool equals(const Object* other) const = 0;
    Object* next = nullptr;
    Object* prev = nullptr;
};

// Derived class — holds the actual value
template <typename T>
class Node : public Object {
public:
    T data;

    explicit Node(T value) : data(value) {}

    void print(std::ostream& os) const override {
        os << data;
    }

    bool equals(const Object* other) const override {
        const Node<T>* otherNode = dynamic_cast<const Node<T>*>(other);
        return otherNode && data == otherNode->data;
    }
};

Object knows nothing about the type it holds — it only defines the interface. Node<T> knows the type, stores the value, and implements the interface.

The list holds Object* pointers. From the list's perspective, every node is an Object. The actual type is invisible at that level — which is exactly what allows the list to be heterogeneous.

When I saw this working for the first time — a single list printing an integer, then a float, then a string, then a struct, all through the same listPrint() call — it was genuinely surprising. Not because it's magic, but because the abstraction is so clean.

`dynamic_cast` — Type-Safe Downcasting at Runtime

This is the part that was completely new to me, and worth documenting carefully.

Once you have a list of Object* pointers, you lose type information at the list level. That's fine for printing — print() is virtual, it dispatches correctly. But what about searching? If I want to find the integer 42 in a mixed list, I need to:

Skip nodes that aren't integers
Compare only against nodes that actually hold int

This is exactly what dynamic_cast does:

template <typename T>
Object* dlList::searchNodeInList(T value) {
    Object* current = head;
    while (current != nullptr) {
        Node<T>* typedNode = dynamic_cast<Node<T>*>(current);
        if (typedNode && typedNode->data == value) {
            return current;
        }
        current = current->next;
    }
    return nullptr;
}

dynamic_cast<Node<T>*>(current) attempts to cast the Object* pointer to a Node<T>*. If the actual runtime type of the object is Node<T> — it succeeds and returns a valid pointer. If the actual type is something else — Node<float>, Node<std::string> — it returns nullptr.

That nullptr check is the type filter. No exceptions, no undefined behavior — just a null pointer when the types don't match.

This is the critical distinction from static_cast: static_cast trusts you at compile time. dynamic_cast verifies at runtime. In a heterogeneous container where you genuinely don't know the runtime type of a node, dynamic_cast is the correct tool — static_cast would be undefined behavior waiting to happen.

One requirement: the base class must have at least one virtual function. Without it, the compiler doesn't generate the runtime type information (RTTI) needed for dynamic_cast to work. The virtual destructor in Object satisfies this.

Operator Overloading for Custom Types — Still Somewhat Esoteric

For built-in types like int, float, and std::string, everything works out of the box — operator<< and operator== are already defined. But for a custom struct, you have to teach the compiler how to handle it.

typedef struct {
    int x;
    float y;
    char z;
} myStruct;

// Teach std::ostream how to print myStruct
std::ostream& operator<<(std::ostream& os, const myStruct& s) {
    os << s.x << " " << s.y << " " << s.z;
    return os;
}

// Teach the compiler how to compare two myStructs
bool operator==(const myStruct& a, const myStruct& b) {
    return a.x == b.x && a.y == b.y && a.z == b.z;
}

The operator<< overload is what allows Node<myStruct>::print() to call os << data without knowing anything about myStruct at compile time — as long as that overload exists, the template resolves correctly.

The stream-based syntax (os << s.x << " " << s.y) still feels somewhat counter-intuitive — you're chaining calls on an object that represents an output stream, returning a reference to itself at each step so the chain can continue. It works, it's idiomatic C++, but it takes some time before it stops feeling like incantation.

The operator== overload is what allows dynamic_cast plus value comparison to work in searchNodeInList. Without it, typedNode->data == value wouldn't compile for custom types.

The requirement is clear: any type you want to store in dllist must implement both. This is enforced at compile time — if you try to store a type that doesn't have them, the compiler tells you exactly which operator is missing.

Memory Management — Clearer Than Its Reputation

Manual memory management in C++ has a reputation for being treacherous. In practice, for a data structure with a clear ownership model, it's straightforward — as long as you follow one rule: whoever allocates, deallocates.

Insertion:

template <typename T>
void dlList::listAppend(T value) {
    Node<T>* newNode = new Node<T>(value);  // heap allocation
    if (head == nullptr) {
        head = tail = newNode;
    } else {
        newNode->prev = tail;
        tail->next = newNode;
        tail = newNode;
    }
}

Deletion of a single node:

void dlList::deleteNode(Object* node) {
    if (node->prev) node->prev->next = node->next;
    else head = node->next;

    if (node->next) node->next->prev = node->prev;
    else tail = node->prev;

    delete node;  // heap deallocation
}

Destructor — cleans up everything:

dlList::~dlList() {
    Object* current = head;
    while (current != nullptr) {
        Object* next = current->next;
        delete current;
        current = next;
    }
}

The key detail in the destructor: save current->next before deleting current. After delete current, that memory is gone — accessing current->next afterward is undefined behavior. One line of discipline prevents the entire class of use-after-free errors.

delete on an Object* that points to a Node<T> calls the correct destructor because ~Object() is virtual. Without the virtual destructor, delete on a base pointer would only call the base destructor — leaking whatever the derived class allocated. This is another reason the virtual destructor in Object is not optional.

What This Exercise Actually Taught Me

Building something redundant — std::list and std::variant already cover this problem more efficiently — turned out to be more instructive than using the standard library version would have been.

The standard library hides the machinery. Building it yourself forces you to confront exactly why each piece exists:

The polymorphic base exists because templates alone can't provide runtime type erasure
dynamic_cast exists because downcasting without runtime verification is unsafe by definition
The virtual destructor exists because delete on a base pointer without it is undefined behavior
Operator overloading exists because templates need the compiler to resolve operations on T — and for custom types, you have to tell it how

None of this is new knowledge in the sense that it's in every C++ book. But there's a difference between reading about it and building something where removing any one of these pieces breaks the entire structure in a specific and instructive way.

The Code

GitHub: https://github.com/AlexRosito67/heterogeneous-double-linked-list
Pure C++17, no dependencies, CMake build
Intended as a learning reference, not a production library

If this was useful, there's a Buy Me a Coffee link on the GitHub page.

Alex Rosito — self-taught electronics engineer and C++ developer. ATtiny85 · ESP32 · KiCad · C++

Why Most 74HC595 Display Drivers Flicker (And How QUAD7SHIFT Avoids It Without Trying)

Alex Rosito — Wed, 29 Apr 2026 02:51:26 +0000

A Chinese technical site cited QUAD7SHIFT as a flicker-free reference implementation. I didn't design it to solve flicker. I just built it correctly.

The Problem Nobody Talks About

Search for "74HC595 7-segment display Arduino" and you'll find dozens of tutorials. Most of them work — in the sense that the display shows numbers. But watch closely under fluorescent lighting, or point a camera at it, and you'll see it: a faint but persistent flicker, sometimes a ghost of the previous digit bleeding into the next.

This isn't a power supply issue. It isn't a loose connection. It's a structural problem in how most drivers handle the latch.

How the Naive Pattern Works

The typical approach looks something like this:

// Naive pattern — found in most tutorials
void showDigit(uint8_t segments, uint8_t digitSelect) {
    digitalWrite(LATCH_PIN, LOW);
    shiftOut(DATA_PIN, CLOCK_PIN, MSBFIRST, segments);   // first transfer
    shiftOut(DATA_PIN, CLOCK_PIN, MSBFIRST, digitSelect); // second transfer
    digitalWrite(LATCH_PIN, HIGH);
}

Two separate shiftOut() calls, then a single latch pulse. Looks fine. The problem is what happens between those two calls.

When the first shiftOut() completes, the shift register holds the new segment data — but the latch hasn't fired yet. At that exact moment, the previous digit select is still active in the storage register. If anything delays the second shiftOut() — an interrupt, a timer ISR, a millisecond of jitter — the display briefly shows the new segment pattern on the wrong digit.

That's ghosting. And even without interrupts, the asymmetry in timing between two sequential software calls is enough to produce uneven brightness across digits.

There's a deeper issue underneath this: shiftOut() is pure software bit-banging.
It drives the clock and data pins manually, one bit at a time, in a tight loop — with no hardware assistance and no atomicity guarantees. On any AVR running with interrupts enabled (which is the default — millis() depends on it), a timer ISR can fire between any two clock pulses. The transfer is not protected. This makes the window between the two shiftOut() calls not just a timing inconvenience but a structural vulnerability: the longer and more interrupt-prone your environment, the more likely you are to see artifacts.

Hardware SPI — used by QUAD7SHIFT via SPI.transfer16() — is handled by a dedicated peripheral that runs independently of the CPU. It cannot be interrupted mid-transfer by software. The 16 bits go out clean, every time.

The Timing Problem Visualized

Naive approach — two 74HC595 chips, sequential transfers:

Time →

LATCH:   ___LOW_________________________HIGH___
SRCLK:        ↑↑↑↑↑↑↑↑  ↑↑↑↑↑↑↑↑
DATA:    [segments byte ] [digit select byte ]
                         ↑
                    HERE: shift reg 1 has new segments.
                    Storage reg still holds OLD digit select.
                    Any interrupt here = ghost on wrong digit.

QUAD7SHIFT — single 16-bit atomic transfer:

Time →

LATCH:   ___LOW___________________HIGH___
SRCLK:        ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
DATA:    [segments byte | digit select byte]
                                 ↑
                    Both bytes shift as one unit.
                    Latch fires once. No intermediate state.

What QUAD7SHIFT Does Instead

The hardware is two 74HC595s in cascade — one controls the segment lines (a–g, dp), the other controls which digit is active (digit select bits). The key is that both chips share a single latch line (RCLK).

The entire transfer is packed into a single uint16_t:

void QUAD7SHIFT::transferDigit(uint16_t result) {
    writePin(LATCHPIN, LOW);

    #if defined(__AVR_ATmega328P__) || (__AVR_ATmega168__)
        SPI.beginTransaction(SPISettings(1000000, LSBFIRST, SPI_MODE0));
        SPI.transfer16(result);   // both bytes in one SPI transaction
        SPI.endTransaction();
    #endif

    writePin(LATCHPIN, HIGH);     // single latch pulse — both registers update simultaneously
}

SPI.transfer16() shifts all 16 bits in one continuous hardware transaction. The latch fires exactly once. There is no intermediate state where one register has new data and the other doesn't.

For ATtiny85, which lacks hardware SPI and uses the USI (Universal Serial Interface), the same principle applies — two usiTransferByte() calls back to back with the latch held LOW throughout:

void QUAD7SHIFT::transferDigit(uint16_t result) {
    writePin(LATCHPIN, LOW);
    usiTransferByte(reverseBits(result & 0xFF));         // segments
    usiTransferByte(reverseBits((result >> 8) & 0xFF));  // digit select
    writePin(LATCHPIN, HIGH);
}

The latch is LOW for the entire duration of both transfers. The storage registers don't see anything until the latch goes HIGH — at which point both update atomically.

Why This Works: The 74HC595 Latch Mechanism

The 74HC595 has two internal registers:

Shift register — receives serial data on each SRCLK rising edge
Storage register — holds the parallel output, only updates on RCLK rising edge

When LATCH (RCLK) is LOW, data shifting into the shift register has zero effect on the outputs. The outputs are frozen. You can shift as much data as you want — through one chip, through ten chips in cascade — and nothing changes on the output pins until you pulse the latch HIGH.

This is the mechanism. The naive pattern doesn't violate it, but it does use it sloppily — latching between two logical operations instead of after both are complete.

QUAD7SHIFT latches once, after all 16 bits are in place.

The Multiplexing Loop

Eliminating ghosting on each individual transfer is necessary but not sufficient. You also need a stable refresh cycle.

The naive approach typically calls the display function from loop(), which means refresh rate is coupled to whatever else loop() is doing. If you add a sensor read or a serial print, the display dims or flickers because some digits get fewer refresh cycles per second.

QUAD7SHIFT decouples refresh rate from loop() timing:

void QUAD7SHIFT::printNumber(uint16_t number, uint8_t decimalPointPosition) {
    // ... digit extraction ...

    unsigned long endtime = millis() + _refreshRate;
    uint8_t i = 0;

    while (millis() <= endtime) {
        printDigit(digitsToPrint[i], i, i == decimalPointPosition);
        i = (i + 1) % numberOfDigitsToDisplay;
    }
}

Each call to print() runs the multiplexing loop for exactly _refreshRate milliseconds, cycling through all digits at a consistent rate regardless of what happened before or after. The display gets a guaranteed time slice.

See It Running

Comparison Summary

	Naive pattern	QUAD7SHIFT
Latch pulses per digit update	1 (but between two transfers)	1 (after both transfers complete)
Intermediate state where ghost can appear	Yes	No
Refresh rate coupled to `loop()`	Yes	No — fixed time slice
Works on ATtiny85	Depends on implementation	Yes (USI, bit-reversal handled)
Hardware SPI on AVR	Sometimes	Yes (`SPI.transfer16`)

I Didn't Design This to Solve Flicker

Worth being explicit about this: I didn't build QUAD7SHIFT by identifying the ghost problem and engineering a solution. I built it by reading the 74HC595 datasheet, understanding that the latch is what separates "data in transit" from "data on outputs," and constructing the transfer accordingly.

The flicker never appeared because the design never created the conditions for it.

A Chinese technical site (CSDN, April 2026) independently analyzed cascaded 74HC595 display drivers and cited QUAD7SHIFT as a reference implementation for eliminating flicker — specifically noting its "dynamic scan algorithm." They found the pattern by looking for the problem. I found it by not creating the problem in the first place.

Both paths lead to the same place. But I think the second one is more instructive: correct hardware abstractions tend to be correct in ways you didn't plan for.

Coverage

A technical analysis in Japanese covering the latch boundary mechanism, multiplexing stability, and platform comparisons (ESP32, Raspberry Pi, RP2040) was published on lilting channel (April 29, 2026), citing QUAD7SHIFT as a reference implementation.

This has been showing up in Arduino forums for years — search any combination of "74HC595 flicker", "shiftOut ghosting", or "7-segment brightness uneven" and you'll find threads like this one where the symptom is described but the root cause is never identified. The answers usually suggest capacitors, resistor values, or power supply issues. None of those fix it because the problem is in the code, not the hardware.

The Library

QUAD7SHIFT is available on GitHub and in the Arduino Library Manager.

GitHub: https://github.com/AlexRosito67/QUAD7SHIFT
Supports Arduino Uno, Nano, and ATtiny85
Common anode and common cathode displays
Configurable refresh rate
String display, float, and integer overloads