From Arduino Prototype to Production: the Display Decisions

A prototype built on an Arduino library and a marketplace breakout board is a legitimate engineering artefact - it proved the idea. The jump to production is not about rewriting everything on principle; it is about knowing which parts of the prototype were load-bearing and which were scaffolding. For the display, that split is unusually clean, and this guide walks it decision by decision.

Written by the Junxian applications engineering team. Figures quoted for “our models” are calculated from the 103 models on this site that carry a full parameter set, so they change when the catalogue changes.

Is it OK to ship Arduino display libraries in a product?

Engineers ask this constantly, and the honest answer is: often yes, with eyes open. The questions that matter are licence terms - display libraries span permissive to copyleft, and your legal exposure depends on which - plus maintenance: who fixes it when a silicon revision changes behaviour, and footprint: graphics libraries carry fonts and buffers your production MCU may not have room for. A library that passes those three checks is a component like any other. One that fails them is technical debt with a ship date.

The init table is the part worth owning

Whatever sits above it, the layer that actually configures the panel - reset timing, offsets, VCOM, gamma, inversion - is small, stable and specific to the glass you ship. Own that layer: keep it as your own file with the values from the module datasheet, not whatever defaults the library carried. It is a page of code, it is the part that breaks when a batch changes, and owning it means a controller change is a table swap rather than an archaeology project. Our init guide lists what belongs in it.

The breakout board does not go to production

The red or blue breakout with the pin header is a development tool: undocumented sourcing, a connector chosen for breadboards, mounting holes where the maker had room. The production version of that display is the bare module it was built around - an FPC into a ZIF connector, or a module with a defined frame - specified by datasheet rather than by listing photo. The glass can be identical; everything around it changes, and the mechanical design should target the module, not the breakout.

Sourcing: the moment the supplier becomes part of the design

At one unit, the display is a purchase. At a thousand, it is a relationship with failure modes: controller substitutions you are not told about, batches that drift, listings that vanish mid-production. The qualification questions are laid out in our datasheet guide; the short version is that a production display needs a named controller, a real datasheet, change notice and an end-of-life path - none of which a marketplace listing offers.

Plan the second source at the first order

The cheapest time to handle obsolescence is before it happens: pick a size and resolution that exists across multiple glass sources, keep the init layer swappable as above, and ask the supplier directly which parts of the module are single-source. A display chosen this way survives a controller EOL with a firmware table update; a display chosen by listing photo survives nothing.

When the right move is a smart module instead

If the production MCU is small, busy or has no display controller, moving the UI into a UART smart module - its own controller, its own layouts, commands instead of pixels - can delete the entire graphics stack from your firmware. It costs more per unit and removes a project's worth of risk, which below a few thousand units is frequently the right trade. Our smart serial modules are this type; the interface guide covers where they fit.

A transition checklist

Concretely, the display work between prototype and production is: confirm the library's licence and footprint or replace it; extract the init table into code you own, with values from the real module datasheet; move from breakout to a documented module and design the connector and mounting around it; qualify the supplier with the five questions; and record controller, glass and firmware table against each production batch. Send us the breakout you prototyped on and the volumes you expect, and we will propose the documented module that matches it - with the init table included.