Rust Embedded Firmware Delivery

Establish hardware facts first, then select abstractions and frameworks. Do not treat example code for a specific development board as portable; do not claim firmware is usable without hardware evidence.

Determine Task Type

Distinguish between the following deliverables:

1. Portable no_std Library or Driver: Core logic should be tested on host using mock HALs.
2. Specific MCU/Development Board Firmware: Requires target, runtime, HAL/PAC, memory layout, burn tooling, and hardware acceptance testing.
3. Board Support or Boot Code: Focuses on linking, startup, clocks, pins, and safety invariants.
4. Embedded Linux Application: Typically uses std; handle as CLI, Web, or concurrency application unless device interface or cross-compilation is involved.

Mandatory Hardware Contracts

Confirm and record before modification: