Develop the full Daisy Pod spike so it can be flashed the moment the board arrives. Architecture: one shared engine, two front-ends. - pm-synth: make it `#![no_std]` (mirroring track-format), routing float math through `libm` so the SAME f32 code runs on the host and on the Daisy's Cortex-M7F (hardware FPU — no fixed-point port needed). Add `Player`, a self-running sequencer that owns the Synth + scheduled clicks and renders sample-by-sample, looping at the pattern boundary. Integer-only hot path (clicks pre-resolved to sample indices); exposes a `fired()` beat counter. Add SPIKE_PROGRAM/SPIKE_BARS as the shared source of truth. - synthrender: render the SAME Player to pm-daisy-preview.wav — the host-side "simulator". Bit-identical preview of the hardware output (before its codec); far more useful than chip emulation (Renode can't model the audio codec). - pm-daisy (new, workspace-excluded firmware): thin BSP binary for the Daisy Seed/Pod. embedded-alloc heap + board bring-up + SAI-DMA audio interrupt feeding Player::next_sample() into stereo frames, USER LED flashing per click. Audio loop follows the `daisy` crate's examples/audio.rs. Board revision (codec) is a Cargo feature; README documents matching it + both flash paths (probe-rs/RTT and USB DFU) + the QSPI-bootloader fallback. Verified without hardware: host build + preview render (48 kHz, onsets on the 8th-note grid at 124 BPM); firmware cross-compiles + links for thumbv7em-none- eabihf at ~87 KB (fits the 128 KB internal flash) across all three codec revisions; track-format conformance + `node tests/run.mjs` (47 pass) still green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
18 lines
739 B
TOML
18 lines
739 B
TOML
[workspace]
|
|
resolver = "2"
|
|
members = [
|
|
"track-format",
|
|
"pm-ui",
|
|
"uisim",
|
|
"glyphgen",
|
|
"pm-synth",
|
|
"synthrender",
|
|
]
|
|
# pm-kit (RP2350/thumbv8m), pm-grid (RP2040/thumbv6m), and pm-daisy (STM32H750/thumbv7em) are
|
|
# embedded firmware (no_std + their own profile/build). Each is built on its own from its crate dir
|
|
# (e.g. `cargo build` inside pm-grid/, which picks up its .cargo/config.toml target), so they are
|
|
# kept OUT of this host workspace to avoid pulling their cortex-m deps into host build/test.
|
|
exclude = ["pm-kit", "pm-grid", "pm-daisy"]
|
|
|
|
# Profiles live at the workspace root (member profiles are ignored in a workspace). The firmware's
|
|
# size/LTO profile stays in pm-kit/Cargo.toml since pm-kit is excluded.
|