Skip to content
Rodeo

rodeo-sdk

The firmware side of the platform. You are writing an Electrosmith Daisy program: libDaisy and DaisySP do the work they always did, and rodeo-sdk adds what the Daisy cannot do on its own — the connectors, the satellite chain, the second codec, and a pile of logic that is easier to test on a laptop than on a bench.

Being rewritten, in the open

The first Rev B boards arrived on 28 October 2026 and most of this has now run on one. The SDK is still mid-rewrite, so this documents a library in motion rather than a finished one. Each page says what is written, what has run on hardware and what has not; the plan and its bring-up table are planning/REV_B_PLAN.md.

What works today

  • USB on the panel USB-C, which is the whole reason Rev B exists. On a Rev B board: UAC1 four in and four out at 16-bit, USB-MIDI, a serial port, and the SD card as a drive in disk mode. Tested on macOS; Windows and Linux have not been tried. 24-bit audio works on a direct port but not behind a USB 2.0 hub, so 16-bit is the default.
  • Both codecs, in one callback. audio_4x4 runs four in and four out across the Seed’s codec and the CS4272. The second codec’s ADC is noisy while its own DAC plays — a board fault, not a driver one, and written up on the motherboard’s page.
  • The satellite chain, end to end. A ring of a pot bank and an encoder bank ran about 24,600 scans in two minutes with none bad, every control read and every LED driven.
  • The SD card in 1-bit mode, 388 KB/s write and 1.24 MB/s read on a 2 GB card, and the same card mounted on a Mac in disk mode.
  • The pure-logic headers. Scaling, filtering, UI smoothing, the scope — no hardware in them, tested on a laptop, and unaffected by the board revision. Every function and type is in the API reference, generated from the headers.
  • The satellite chain’s frame format. sat_frame.h is the wire protocol in code, shared by the Seed and the satellites and tested by playing both, down to a simulated ring.
  • The I/O connectors. Digital, analog in and CV out on the ten connectors, checked against what each one can do, and tested on a bare Seed wired to itself.
  • The Rev B pin map. board.h names every pin by what it is wired to, and host tests check it against libDaisy’s own pin table.
  • Toolchain and template. Building, flashing and starting an app have not changed.

What is still being written

USB as a library rather than an example, and the guide pages for the drivers that landed during bring-up. The battery gauge has a driver and host tests but has never answered with a real number: the cell on our board was plugged in backwards and took the gauge with it.

Each of these gets its page here when its code lands. rodeo-demo is the first instrument being written against this SDK; rodeo-002 moves onto it after.

How it is put together

Layer 1 is pure logic. Headers with no hardware in them at all, so they build and run on a laptop under common/tests. If something can be tested without a board, it belongs here.

Layer 2 is the board. Drivers that talk to real silicon over SPI, I²C and UART. They depend on board.h, which is the single source of truth for the pin map.

Layer 3 is your instrument. The control assignments — which knob is cutoff, which encoder picks the waveform — live in your app and its own control map, not in the SDK. If something here names a specific knob or a specific sound, it is in the wrong place.

Where to go next

  • Install and build — toolchain, submodules, and the macOS newlib trap
  • Your first app — copy the template and get something running
  • Pure-logic headers — the parts you can test without hardware
  • API reference — every header’s functions and types, generated from the code
  • Examples — what exists to run right now
  • Versioning — how the SDK is tagged, and how an app refuses to build against one that is too old