How We Did ESC Configuration: MSP Compatibility + FCSP Runtime Path

Why we built this

We wanted ESC configuration that is small and fast on Linux targets like Raspberry Pi Zero 2W, while still keeping compatibility with existing tooling.

So we kept MSP where it helps, but moved runtime transport and timing-sensitive flow into FCSP + FPGA offload.

How we did it

1. Ported core logic to Python
   We separated protocol operations from UI and moved ESC transaction flow into reusable Python modules.
2. Kept transport explicit
   FCSP CONTROL (0x01) handles mode/mux/select operations, and ESC_SERIAL (0x05) carries tunneled ESC serial bytes.
3. Used hardware steering
   Select motor channel in hardware, optionally issue break/preamble for bootloader entry, tunnel request/response bytes, then restore normal DShot mode.
4. Hardened reliability
   Improved serial init/flush/error paths, explicit timeouts, and cleaner recovery when an ESC does not respond.

MSP vs FCSP (and why both)

MSP is still useful for compatibility and ecosystem tooling.

FCSP is the runtime-first path for deterministic behavior in this architecture. Timing-sensitive work stays in RTL, not Linux scheduling.

What works now

• ESC passthrough/tunneling over FCSP
• Motor select + mode control
• Bootloader entry sequence support
• Read version/settings workflows
• MSP compatibility flow + FCSP runtime flow

Repo references

• rt-fc-offloader
• esc-configurator

Next post: reliability details and the exact tunnel state-machine sequence.