rt-fc-offloader Intro: Why, SPI, Serial, Switching, MSP Difference, and ESC-Config Write-Up

rt-fc-offloader Intro

Why rt-fc-offloader exists

We have INAV running on Linux on a Pi Zero 2W. The hard part is not running Linux flight-control software — the hard part is strict real-time I/O behavior.

This project exists to offload three timing-critical paths into deterministic FPGA logic:

• NeoPixel (NeoPx) output timing
• DShot generation timing
• ESC-protocol tunneling for configuration and firmware updates

The goal is small and fast: keep Linux flexible for flight-control logic while hardware guarantees the exact timing-sensitive work.

Why we moved from MSP to FCSP

MSP is useful for ecosystem compatibility, but we ran into issues using it as the center of runtime transport for these offloaded timing paths.

So we created FCSP as the runtime protocol for this architecture because it gives:

• explicit framing and integrity checks
• channelized routing model
• deterministic behavior under load/noise
• a cleaner FPGA implementation path for parser/router/FIFO pipelines

Transport usage: SPI and Serial

SPI is the primary runtime transport for FCSP between Linux host and FPGA.

Serial is a secondary/alternate transport for bring-up, diagnostics, and validation workflows.

ESC-config tunneling (channel/port details)

ESC configurator traffic is tunneled through FCSP channels:

• CONTROL channel (0x01) for register/mux control
• ESC_SERIAL channel (0x05) for ESC protocol byte stream tunneling

Typical ESC-config sequence:

1. configure mux control (select motor/mode)
2. optional break pulse for bootloader entry
3. exchange ESC bytes over FCSP ESC_SERIAL channel (0x05)
4. restore DShot mode after completion

How FCSP is parsed and routed

1. ingress receives framed bytes (SPI or Serial)
2. parser detects sync/header/length and packet context
3. CRC16-XMODEM gate validates integrity
4. router dispatches by channel (CONTROL, ESC_SERIAL, TELEMETRY, etc.)
5. response path tracks return interface and sends replies to the correct egress

How this is done in FPGA

The architecture is implemented as dedicated RTL blocks instead of software-timed bit banging:

• ingress transport block (SPI/UART)
• frame parser + CRC block
• channel router/switch block
• control bridge for register access
• hardware I/O engines for DShot, NeoPixel, and ESC serial tunneling
• TX arbiter + framer for deterministic response egress

In short: Linux decides what to do, FPGA guarantees when it happens.

More updates soon as DShot and MSP-facing integration work continues.

Companion ESC configurator

Current status: we now support both MSP and FCSP. MSP remains available for compatibility/tooling workflows, and FCSP remains the runtime-first transport for deterministic offload behavior.