Proposal: URML (substrate-neutral robot intent) capability-manifest mapping for CircuitPython — Python-on-MCU substrate

[idoco2003]

Hi @adafruit team,

Proposing a URML v0.1 capability-manifest mapping for CircuitPython over adafruit/CircuitPython. URML (Universal Robot Language, Apache-2.0) is an open spec for substrate-neutral robot intent.

CircuitPython runs on 400+ board variants spanning RP2040, SAMD21/51, nRF52, STM32, and ESP32. URML's microbit_edu manifest pattern (RFC-0018) implicitly covers CircuitPython-class boards, but the Python-on-MCU substrate is its own layer URML's manifest should declare explicitly. The natural URML integration shape is host-side: a Mu / Thonny / Code-with-Mu IDE-side bridge that emits validated URML primitives, with CircuitPython on the device dispatching them.

This is proposal-only, posted as part of URML's Move #13 outreach (15 engageable RFCs in this wave).

Full RFC: https://github.com/URML-MARS/URML/blob/main/docs/rfcs/0174-adafruit-circuitpython-outreach.md

Questions worth adafruit/CircuitPython maintainer input on:

1. Python-on-MCU substrate manifest fields. Spec RFC queued (shared with MicroPython-on-MCU declarations). Manifest field expectations from the CircuitPython perspective?
2. 400+ board-variant identifier scheme. Should URML's manifest use CircuitPython's existing board-id convention, or a separate URML identifier mapped to it?
3. Drag-drop deploy-model declaration. Useful manifest field for educational deployments?
4. Library-ecosystem declaration. Should URML's manifest declare which Adafruit_CircuitPython_* libraries are loaded?
5. Adapter home. URML repo (reference/edu-runtime/CircuitPythonAdapter), Adafruit-maintained adafruit/circuitpython-urml-bridge, or both?
6. Conformance listing. Would Adafruit consider a README link to URML's compatible-runtimes registry once a working adapter ships?
7. Anything else.

Ido Yahalomi (URML maintainer, urml.dev, greenvh@gmail.com)

---

AI-assisted prose, maintainer-reviewed before posting (see VIBE.md). Human-only correspondence available on request.

[dhalbert]

We would not mind being listed in the spec. I looked over the RFC. We would prefer to discuss this with a human rather than an LLM. A few comments:

• The drag-and-drop deployment model does not work for all boards. Some don't present a USB MSC drive.
• We are not likely to maintain the adapter / URML bridge ourselves. We have an Adafruit library bundle maintained and supported by Adafruit staff, and a community library bundle maintained by community members: https://github.com/adafruit/CircuitPython_Community_Bundle. The community bundle would be the place for this.
• We can add a pointer to this somewhere. Besides a README here, another place is https://github.com/adafruit/awesome-circuitpython.
• CircuitPython is a friendly fork of MicroPython, and largely shares the base language implementation. But the built-in modules for using hardware are different than MicroPython's. So two mappings, one for each, make sense.
• MicroPython is deemphasizing file operations through an MSC drive, and prefers using communications programs on the host computer.

[idoco2003]

Thanks Dan, this is exactly the feedback I was hoping for.

Here's what I'll do based on your notes:

1. USB-MSC. Dropping it as an assumption in the RFC. The manifest will declare the deployment path per-board, not per-language.
2. Adapter home. Will route the CircuitPython adapter through the Community Bundle when there's something concrete to publish, not through core. I'll follow the bundle's contribution process.
3. awesome-circuitpython. Will open a listing PR there once the adapter actually works on a board I can test.
4. CircuitPython ≠ MicroPython. Splitting into two separate Spec RFCs. The hardware-module surface is the gap; you're right that pretending it's one mapping would mislead.
5. MSC deemphasis on MicroPython. Noted for the MicroPython side; that's a separate outreach.

Happy to keep the conversation here or move to email if that's easier — I'm Ido, you can reach me at greenvh@gmail.com.