Reinventing the Dashboard: Designing a Digital Cluster for a 1995 Miata

Introduction

If you drive a 1995 NA Miata, you know the charm of its analog gauges. The crisp needle sweep, the minimalism, the simplicity. But as a software engineer who spends just as much time tweaking Neovim configs as tuning engines, I couldn’t resist asking: what if the Miata’s dashboard was fully digital?

Not in the “bolt on an iPad” sense, but a thoughtfully engineered cluster that blends modern embedded tech with the retro character of the car. That question has grown into one of the most challenging and rewarding projects I’ve worked on — a digital dashboard system that uses MIPI DSI and SPI displays, microcontrollers, and custom software to transform how I interact with the car.

This article is part reflection, part technical breakdown. The project isn’t finished yet, but the journey so far has taught me more about hardware, software, and system design than I could have imagined.

The Vision

The idea started small: replace the analog tachometer with a circular LCD. But like most engineering rabbit holes, it quickly escalated.

Two large MIPI DSI displays as the tachometer and speedometer.
Three smaller SPI-based GC9A01 round displays to handle fuel, oil pressure, and temperature.
An optional center infotainment screen for navigation or Android Auto.
Camera inputs (rear, blind spot, maybe front-facing).
A software layer that could make the dashboard skinable — retro dials one day, futuristic HUD the next.

Essentially, I wanted to reimagine the Miata’s cluster not just as a display, but as a canvas for both aesthetics and function.

Hardware: Choosing the Displays

Picking displays turned out to be my first real education in trade-offs.

MIPI DSI panels
- Gorgeous resolutions, fluid refresh rates.
- Widely used in smartphones, so plenty of options.
- But: they demand serious bandwidth and proper drivers — not something you casually drive with an Arduino.
GC9A01 1.28" SPI circular displays
- Perfect size for small gauges.
- Supported in Zephyr and LVGL out of the box.
- SPI is simple but slower, meaning careful optimization is needed to hit usable refresh rates.

What started as “slap in some screens” turned into a deep dive on display protocols, refresh bottlenecks, and the importance of bandwidth in system design.

Software: From Blinky to LVGL

Before this project, I thought “draw something on a screen” was a solved problem. Plug in a library, send pixels, done. Turns out, embedded graphics are a whole world.

I began with Zephyr RTOS on an nRF52840 (Pro Micro form factor) — chosen partly because I already had one running custom firmware for a keyboard. My first goal: just get LVGL (the lightweight embedded GUI library) running on the GC9A01.

Step 1: Configure SPI loopback in Zephyr.
Step 2: Bring up the GC9A01 driver.
Step 3: Render a static LVGL widget.

When I finally saw a primitive LVGL animation play on the tiny round screen, it felt like magic. That single moment bridged months of learning about device trees, Zephyr overlays, SPI timing, and display init sequences.

But it also highlighted constraints: LVGL + SPI + 240×240 pixels isn’t exactly snappy. Animations need careful tuning. Resource limits force you to design efficiently.

Architecture: Centralized vs Distributed

This is where the project shifted from “fun experiment” into real system architecture.

Option 1: Centralized compute
- One high-performance board (x86 or ARM SBC with GPU) drives all displays.
- Easier for rendering consistency and advanced features (Android Auto, camera feeds).
- Risk: single point of failure — if it crashes, everything goes dark.
Option 2: Distributed microcontrollers
- Each display has its own controller running LVGL.
- A central unit just pushes sensor data over CAN or serial.
- Pros: fault tolerance, less strain on any one device.
- Cons: synchronization is tricky, wiring becomes a mess.

This forced me to think about reliability in a new way. When you’re driving 70mph, you don’t want your tachometer to freeze because a mainboard rebooted.

Integration with the Car

The Miata wasn’t built with digital dashboards in mind, so integration itself is a lesson:

Sensors: Some are analog (oil pressure), some are digital (speed via VSS). I’ll need a mix of ADC inputs and possibly a CAN adapter for future upgrades.
Power: Displays and SBCs draw more current than a few bulbs. Ensuring the alternator can handle the load is critical.
Thermal: Electronics inside a sunlit Miata cabin can easily overheat — something I hadn’t thought about until I read display datasheets with max operating temps.

The “systems thinking” part of me loves this — every design choice cascades into others.

Challenges Along the Way

Bandwidth limitations: SPI is a bottleneck for fast updates. I’ve had to think about partial screen redraws and LVGL optimizations.
RTOS learning curve: Zephyr overlays, device tree configs, and RTOS concepts were a steep hill to climb.
Durability: The project has to survive vibration, bumps, and years of use. 3D-printed mounts and proper connectors matter as much as code.
Unfinished pieces: MIPI DSI is still on the research board. Driving them reliably requires either a GPU-capable SBC or specialized bridge chips.

The Human Side: Why This Project Matters

What surprised me most is how much this project blurred lines between hobby, engineering, and personal growth.

It started as “just for fun,” but it’s become my best crash course in embedded systems, hardware-software integration, and architecture trade-offs.
It ties directly into my other explorations — from LVGL on small SPI displays, to learning Gentoo and kernel internals, to thinking about distributed systems (Orleans → dashboard controllers).
And it’s personal: I love this car, and giving it a custom digital dashboard feels like merging who I am as an engineer with what I love as an enthusiast.

Next Steps

Finish refining LVGL demos on the GC9A01s.
Decide on compute architecture: powerful central SBC vs distributed MCUs.
Begin experimenting with MIPI DSI panels.
Design 3D-printed mounts and housings that fit cleanly in the Miata’s retro dash.

Conclusion

This project isn’t finished — and that’s the best part. Every step forward has unlocked something new: a concept I didn’t understand, a protocol I hadn’t heard of, a system design question I didn’t expect.

If there’s a lesson so far, it’s this: personal projects are the best classrooms. By trying to reinvent the dashboard of a 1995 Miata, I’ve learned more about embedded development, display tech, and system architecture than any structured course could teach me.

And when it’s done? I’ll have a one-of-a-kind dashboard that makes my Miata as much a reflection of my engineering journey as my driving hobby.