apress/deploy/uno-q/skills/uno-q-hardware/SKILL.md

name, description

name	description
uno-q-hardware	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.