Arduino EFBus

Arduino EFBus: a low-latency MCU↔MPU transport for UNO Q

Arduino UNO Q gave us the Linux-capable platform, the microcontroller boundary and the development ecosystem on which this work could grow. EFBus is our project-level transport and service architecture built on that foundation: it does not replace Arduino software or hardware, but adds the explicit contracts that our robot and measurement applications need to work together reliably.

Why we built it for the RoboCup robot

During the 2025–2026 RoboCup development cycle, our robot had to move at roughly 15–30 cm/s while coordinating sensors, navigation, motor control, diagnostics and Linux-side tools from a single Arduino UNO Q. At those speeds, every unnecessary copy, ambiguous retry or competing data session could become a control problem. We needed minimum latency, predictable ownership and maximum efficiency without hiding the system behind several unrelated controller boards.

That practical requirement led us to build EFBus: a measured MCU↔MPU protocol and service boundary designed around the robot’s real acquisition and control paths. The result was not a generic message tunnel, but an explicit contract for who owns a session, which data is valid, how a capability is negotiated and how a diagnostic observer can read the latest state without opening a second control session.

From the Arduino platform to a reusable FermiLabs protocol

We started from the capabilities Arduino made available through UNO Q: a real-time MCU side, a Linux MPU side and a compact development platform suitable for experimentation. EFBus complements that architecture by making the boundary versioned, typed and measurable. Arduino remains the platform and ecosystem; EFBus expresses the application and transport rules required by our specific robotics and acquisition workloads.

OpenDAQ helped shape the way we think about acquisition and signals. Channel identity, timing, topology, freshness, quality and provenance must remain visible before a value is treated as a meaningful signal. Those concepts became part of our EFBus design, and today EFBus is the shared transport base for our Arduino UNO Q applications, including RoboCup, Arduino OpenDAQ and the related laboratory tools.

Core architecture

• one authoritative EFBus data/session owner per service epoch;
• SDK 0.12.0, daemon API 1.8, Wire 2.5 and MCU API 1.4 compatibility baseline;
• typed multi-endpoint service model with EFC9 composition identity;
• capability/profile negotiation and fail-closed compatibility behaviour;
• observer/cache access for diagnostic clients instead of a second data session;
• bounded command authority, idempotent request handling and explicit retry limits;
• measured transport and resource behaviour, with hardware evidence kept separate from software claims.

Optional module ecosystem

EFBus started as the transport boundary for the robot, but it evolved into a small family of optional companions. Each module has its own contract and admission gate; modules are disabled unless an application explicitly selects them, so the core remains lean and predictable.

• OpenDAQ companion:an optional Linux/MPU acquisition path and the single public EFBus SDK data-session owner when selected. It publishes typed EFC9 records for physical A0–A3 ADC codes and the D0–D15 digital-input topology, while keeping timing, channel identity and raw-value provenance explicit. It never opens SPI, parses private Wire storage or exposes commands, and acquisition overflow never backpressures EFBus.
• Matrix companion:an optional MCU graphics path for packed pixels, deterministic DMA plans and bounded animation primitives. It is independently admitted and can be omitted without adding code or RAM to firmware that does not use it; physical update rates and profiles remain separate evidence gates.
• Indicators companion:optional semantic status for the UNO Q RGB LEDs. MCU RGB3 can show EFBus health, RGB4 accepts bounded application leases, and the Linux companion can render application or OpenDAQ state on RGB1 with priorities and automatic TTL expiry. Applications send semantic states rather than touching GPIO or sysfs paths.
• Display service:an optional one-writer service for HD44780+PCF8574, SSD1306, Matrix and other explicitly admitted backends. It supports target identity, request fingerprints, revisions, idempotency, clear-then-OFF expiry and independent target masks; the native MCU path uses Display schema v2 over the shared I2C Fabric.
• Shared I2C Fabric Manager:a bounded MCU scheduler for direct and one-hop MUX routes. It admits collisions before runtime, executes one transaction per tick and keeps fairness and ownership explicit instead of allowing independent modules to compete for the bus.
• Board Diagnostics:a disabled-by-default typed endpoint that exposes cached owner state and bounded diagnostic records. Providers copy already-known state; they do not scan I2C, select a MUX, read UART or perform hardware actions from a capture path.
• Optional Services (EFOS):a disabled-by-default router for configuration, capability discovery and unified diagnostics. It creates no thread, autonomous timer, heap activity, polling loop, raw I/O or hardware action until an application admits a provider.
• Feedback/Review:the product-agnostic companion supplies browser and native feedback, bounded offline queues, idempotent receipts, review envelopes, analytics and optional contextual screenshots. Its EFBus adapter accepts only an allowlisted read-only observer/cache snapshot; it never opens another EFBus session or becomes a command owner.

Other separated observers

The repository also contains optional wireless and BitChat companions. The wireless path fans out latest-only telemetry to bounded local HTTP/SSE and read/notify BLE surfaces without actuation. BitChat is a separate authenticated messaging harness with no EFBus endpoint or motor command path. Keeping these surfaces separate prevents convenience features from enlarging the robot’s safety or transport authority.

Measured performance and qualification boundaries

EFBus was designed for low-latency, high-efficiency operation rather than for a headline benchmark detached from the robot. The repository records transport, memory, timing and optional-module evidence with explicit profiles and regression gates. The current V09 tree is an operational reference candidate built on the V08 compatibility boundary, not a blanket production freeze: post-delta regression, audit reconciliation and exact hardware or deployment gates remain separate decisions.

Next platform to evaluate: Arduino VENTUNO Q

If anArduino VENTUNO Qbecomes available to FermiLabs, we will begin a controlled experimentation and implementation phase before deciding whether it belongs in a competition robot. The official board combines a Qualcomm Dragonwing IQ8 processor, with an octa-core Kryo CPU, Adreno 623 GPU and Hexagon AI acceleration up to 40 dense TOPS, with a dedicated STM32H5F5 Arm Cortex-M33 microcontroller at 250 MHz for deterministic, low-latency control.

Its 16 GB of LPDDR5 memory, 64 GB of eMMC storage with M.2 NVMe expansion, Wi‑Fi 6, Bluetooth 5.3, 2.5 Gb Ethernet, camera and display interfaces, CAN-FD and Arduino App Lab could provide substantially more compute and memory headroom for computer vision, local AI, mapping, simulation and replay. The safety-critical motor and stop paths would remain on the real-time MCU, while Linux-side workloads could become richer without weakening the EFBus ownership boundary.

Our first VENTUNO Q work would be experimental and measurable: compare perception and transport latency, jitter, thermal and power behaviour, camera pipelines, sensor integration, mapping throughput, fault handling and replay quality against the UNO Q baseline. Availability would not mean automatic adoption or competition compliance; any race use would require its own rules, hardware and safety qualification.

Why it matters to FermiLabs

EFBus is now shared infrastructure rather than a standalone product island. RoboCup uses it to separate real-time safety and navigation from Linux perception and observability. Arduino OpenDAQ uses it to expose typed acquisition without creating a second data owner. SpeedCircuits and the wider FermiLabs laboratory workflow can consume the resulting measurements while keeping simulation, observation and physical qualification clearly distinguished.

Current public status

The repository tracks a V09 operational reference candidate on top of the proven V08 compatibility boundary. Public APIs, supported services, compatibility versions, installation constraints, measured performance and known limitations remain tied to the repository’s publication contract. The software/reference-candidate status must not be read as a blanket claim that every optional module or connected board is production-qualified.

Publication contract

This page is the canonical public narrative consumed by FermiLabs.fermilabs/publication.jsonis the machine-readable project contract andfermilabs/updates.jsonis the public update feed. Material changes to APIs, protocols, supported services, compatibility versions, packaging, measured public performance, validation status or known limitations must update the relevant publication files in the same reviewed change.