---
name: uno-q-hardware
description: Arduino Uno Q board pinout and voltage rules — PWM pins, 3.3V ADC limits, I2C/SPI/Serial pins, and the MPU vs MCU split. Load this before answering any question that names a pin (D0-D21, A0-A5) or a voltage, or before writing a sketch that uses analogRead/analogWrite/Wire/SPI/Serial.
---

# Arduino Uno Q Hardware

Two processors talk over an RPC Bridge:

- **MPU (Linux)** — Qualcomm QRB2210, 4× Cortex-A53. Runs ZeroClaw, the LLM,
  arduino-cli, OpenOCD. MPU I/O is **1.8 V** and is **not** reachable from sketches.
- **MCU (Arduino)** — STM32U585, Cortex-M33, Zephyr + Arduino core. Runs `.ino`
  sketches. **Every Arduino header (JDIGITAL, JANALOG, JSPI, Qwiic) is 3.3 V.**

Sketches always target the MCU (`arduino:zephyr:unoq`).

## Quick facts

- **PWM pins:** D3, D5, D6, D9, D10, D11 (the `~` pins). `analogWrite` only works here.
- **Built-in LED:** D13.
- **I2C2** (`Wire`): SDA = D20, SCL = D21. **I2C3** (`Wire1`): SDA = A4, SCL = A5.
  **I2C4** = the Qwiic connector (plug-and-play Modulino sensors).
- **SPI (SPI2):** D10 = CS, D11 = MOSI, D12 = MISO, D13 = SCK.
- **Serial:** `Serial` = D0 (RX), D1 (TX).
- **DAC:** A0 = DAC0, A1 = DAC1 (12-bit; `analogWriteResolution(12)`).
- **CAN:** FDCAN1 on D4 (TX), D5 (RX) — needs a transceiver (e.g. TJA1051T/3).

## Voltage safety — call this out every time

- ADC inputs A0–A5 accept **0–3.3 V only** (abs max ~3.6 V). **5 V on A0–A5 damages
  the STM32U585.** Unlike a classic 5 V Uno.
- `analogRead()` returns 0–1023; volts = `raw * 3.3 / 1023.0`.
- For a 5 V sensor, divide down: 5 V → 10 kΩ → A0 → 20 kΩ → GND.

## Checking sensors — the `i2c_scan` tool (mux-aware)

To see what's wired to the board's I2C, call **`i2c_scan`**. It probes the MCU's
Arduino Wire bus (Qwiic + I2C headers) — this is where student sensors hang, NOT
Linux `/dev/i2c-*` (those are MPU-side and unreachable from the app container).

The APESS kit hangs its ADXL355s behind a **PCA9548A I2C mux at `0x70`**, and two
sensors can share address `0x1d` on different channels — so the scan walks the mux
too. Read the comma-separated result like this:

- `0x1d` — a device directly on the bus (e.g. a lone ADXL355 wired to Qwiic).
- `0x70:mux` — an I2C mux is present at `0x70`.
- `0x70.2=0x1d` — a device at `0x1d` behind mux `0x70` on **channel 2**.
- `none` — nothing ACKed.

So `0x70:mux,0x70.2=0x1d,0x70.5=0x1d` = the mux plus two ADXL355s, one on channel 2
and one on channel 5. If a student sees only `0x70:mux`, their sensors aren't wired
to the mux channels (or aren't powered) — a mux with nothing behind it. If they see
nothing at all, check power and SDA/SCL. **ADXL355** = `0x1d` (or `0x1e` if ADDR is
pulled high); the FabLab kit reads it at `0x1d`.

## The student's own files — help fix their implementation

The participant's Arduino work is mounted into this container under **`/app/workspace/`**:

- `/app/workspace/sketches/<name>/<name>.ino` — sketches they wrote in App Lab's
  sketch editor (this is where most implementations live).
- `/app/workspace/apps/<name>/` — full App Lab apps they built.
- `/app/workspace/libraries/` — installed Arduino libraries (read-only reference).

Read these to review, correct, and complete a student's code when they ask for help
("why doesn't my sensor read?", "fix my sketch"). You can edit files under
`sketches/` and `apps/`; `libraries/` is reference only. If `/app/workspace/` is
empty, the workspace mounts aren't set up on this board yet — say so rather than
guessing at their code.

## On-board LEDs

- RGB LED 1/2 are MPU-owned (`/sys/class/leds/*`, use the `sysfs_led` tool).
- RGB LED 3/4 are MCU-owned (`analogWrite`/`digitalWrite` in a sketch).
- All RGB LEDs are **active-low** (write 0 = on). `sysfs_led` inverts this for you.