GIGA Shield Lab: From One Touchscreen to a Complete Engineering Platform

Engineering case study · Embedded UI ·Arduino GIGA R1WiFi · October 2026

A touch display can be a menu of demonstrations, or it can be the front end of a reproducible engineering platform. GIGA Shield Lab explores the second approach: one shared C++/LVGL environment for instrumentation, mathematics,robotics, educational microapps and a genuine Commodore 64 workspace. This article focuses on thedesign decisions and verification evidence, rather than repeating the full feature catalogue on theGIGA Shield Lab project page.

The problem: one device, many experiments

The Arduino GIGA R1 WiFi and its 800 × 480 Display Shield can run very different experiments, but a collection of unrelated screens would create duplicated navigation, inconsistent input handling and an unclear boundary between a simulation and a measurement. The engineering objective was to make the device feel like one laboratory: launch an experiment from a common HOME, return predictably, retain consistent localization and input semantics, and know which software image produced each observation.

The architecture: a single C++/LVGL source of truth

The canonical UI uses C++ and LVGL 9.6.0. The same product logic feeds theArduinofirmware and native host development environment; browser viewing and the WebAssembly workstream are validation or presentation surfaces, not a second independently maintained JavaScript product. A central launcher organizes the experience while shared primitives handle localization, rendering, navigation and touch/HID input.

The architecture deliberately distinguishes the12 launcher-visible microappsfrom four internal services, and treats the C64 environment as a separate HOME destination. This avoids artificially inflating the public microapp count or allowing historical prototypes to masquerade as the current production UI.

A difficult subsystem: a real C64, not a simulated screenshot

The C64 destination demonstrates why source identity matters. The system has to perform actual 6510 execution, render VIC-II video and handle SID audio while offering BASIC, DEBUG and MEMORY inspection. Program navigation, touch keyboard behavior and licensed or user-supplied ROM provenance are part of the acceptance contract. A screenshot of a BASIC prompt is therefore not proof that the emulator works.

The physical release: what was actually verified

The frozen physical releasev2.261016-2117, dated 16 October 2026, uses a firmware revision recorded internally on Arduino core 4.6.0 and LVGL 9.6.0. The release evidence binds the firmware build, on-device execution and diagnostic captures; internal source identifiers are not published. On the GIGA-DISPLAY target, the following were reported as accepted:

• Release identity:build and upload receipts, same-device USB re-enumeration and executed-source identity matched the frozen candidate.
• Display and navigation:common HOME and carousel, physical frame capture, C64 BASIC/DEBUG/MEMORY areas and a 65-key touch keyboard.
• Input and localization:EN/IT switching, Italian/US keyboard operator handling, physical Calculator interactions and HID report-path checks.
• Resource diagnostics:startup out-of-memory, LVGL flush-allocation failures and DMA failure counters reported zero in the release acceptance.

These observations support a real hardware milestone, not a blanket claim that every lab, sensor, browser endpoint or long-duration workflow has been qualified.

Evidence levels must remain explicit

The native 800 × 480 captures document the UI generated from the C++/LVGL source. A host simulation proves a software interaction path, not physical sampling accuracy. A hardware receipt proves the behavior actually measured on the identified board and firmware image. The browser-facing simulator and static gallery are valuable review surfaces, but their public deployment and full end-to-end interaction are separate from the frozen physical release.

What remains open

• Cold reconnect:acceptance after complete power interruption still needs its own evidence.
• Extended booth soak:sustained operation must be demonstrated independently of brief functional checks.
• Public AGS experience:the standalone site and interactive WebAssembly simulator must be published and verified separately; an unpublished or localhost-only URL must not be advertised as a working public demo.

What this changed

The important result is architectural: a shared embedded interface can make many experiments navigable without duplicating each application’s controls. The release also illustrates a disciplined boundary betweensource-level proof, native rendering, physical execution and deployment. Those distinctions are useful well beyond the GIGA Display Shield.

For the product overview, the microapp catalogue and future publication links, seeArduino GIGA Shield Lab. For the separate topic of GIGA R1 data streaming towardopenDAQand DewesoftM, readArduino GIGA R1 Streaming LT: Eight Channels, DewesoftM and a Reproducible Acquisition Path. That acquisition case study covers a different engineering question and is not duplicated here.

Evidence basis:the documented physical GIGA Shield Lab release and reviewed product evidence as of 5 November 2026. Detailed engineering records remain private; public readers can consult the linked project and case studies.