Omar SobhandClaude Opus 4.8
62c435c648
Vendors the fork's 11 granular UNO Q skills (bridge, flashing, led-matrix, uno-q-hardware, sketch-patterns, modulino, linux-led, audio, vision, wireless, arduino-app-lab) next to the comprehensive arduino-uno-q skill, and installs the whole set into every agent's workspace on each board. Why both: the comprehensive skill is the rich cloud reference (read_skill → references); the granular skills are keyword-triggered and match the fork's eager skill-inliner rules, so the on-board Qwen auto-inlines them (no read_skill round-trip). flashing + led-matrix carry the exact uno_q_flash + frame-API / ArduinoGraphics-not-installed detail that makes flashing reliable. - push-skill.sh generalized: a single skill dir (has SKILL.md) OR a parent dir installs every skill under it; provision-fleet now ships all of skills/. - Verified on board 65301572: cloud/Sonnet-5 lists all 12 skills. Co-Authored-By: Claude Opus 4.8 <[email protected]>
51 lines
2.2 KiB
Markdown
51 lines
2.2 KiB
Markdown
---
|
|
name: bridge
|
|
description: Arduino Bridge — the RPC layer that lets Python on the Uno Q's Linux side (MPU) call functions on the Arduino sketch (MCU) and vice-versa. Load this before any project that combines a Python program with an Arduino sketch, or asks how to send data between the Linux side and the sketch.
|
|
---
|
|
|
|
# Bridge — Inter-Processor RPC on the Uno Q
|
|
|
|
The Uno Q is two computers on one board:
|
|
|
|
- **MPU** (QRB2210, Debian Linux) — Python, web servers, AI models, OpenCV, Wi-Fi.
|
|
- **MCU** (STM32U585, Zephyr + Arduino) — `.ino` sketches; owns every Arduino
|
|
header pin (digital, PWM, ADC, I²C, SPI, UART, CAN).
|
|
|
|
**Bridge** is Arduino's software RPC layer so either side can call the other.
|
|
The MCU has **no Wi-Fi and no Linux**; the MPU has **no direct Arduino pins**. Use
|
|
Bridge whenever a project needs *both* sides.
|
|
|
|
## When to use Bridge
|
|
|
|
| Scenario | Why |
|
|
|---|---|
|
|
| Python reads a sensor wired to A0 | MCU owns the pin → Python calls the MCU |
|
|
| Sketch needs internet/weather data | MCU has no Wi-Fi → MCU calls the MPU |
|
|
| An AI model on Linux drives an LED | Python runs the model → calls the MCU |
|
|
| Sketch streams data to a web dashboard | MCU samples → MPU serves HTTP/WebSocket |
|
|
|
|
## Two ways to reach the MCU from ZeroClaw
|
|
|
|
1. **Runtime GPIO via the deployed Bridge app** — use the `gpio_read` / `gpio_write`
|
|
tools. These talk to the uno-q-bridge app (TCP :9999) that must already be
|
|
running on the board (`zeroclaw peripheral setup-uno-q` deploys it). Good for
|
|
toggling pins on a sketch that is already flashed.
|
|
2. **Flash a whole sketch** — use `uno_q_flash` (see the `flashing` skill) to
|
|
compile and program a full `.ino`, including one that `#include <Bridge.h>` and
|
|
exposes its own RPC services.
|
|
|
|
## Sketch side (MCU)
|
|
|
|
```cpp
|
|
#include <Bridge.h>
|
|
void setup() { Bridge.begin(); }
|
|
void loop() { /* expose services / handle calls */ }
|
|
```
|
|
|
|
## Pitfalls
|
|
|
|
- The MCU has **no Wi-Fi peripheral** — `#include <WiFi.h>` will not compile for
|
|
`arduino:zephyr:unoq`. Network access is the MPU's job, reached via Bridge.
|
|
- `gpio_read`/`gpio_write` require the bridge app running; if they error with a
|
|
connection failure, the app isn't up.
|