1.8 KiB
1.8 KiB
Assistant Configuration
Global Rules
- Rust emdedded
- Always describe what you thinking and your plan befor starting to change files.
- Make sure code have max 5 indentation levels
- Use arrays, structs, etc for clean organization
- Make sure the codebase is manageable and easily readable
- Always check code (compile/check)
- Always fix compile warnings
- Do not try to deploy project to hardware
- Use "just" for check, test, flash etc
- Use file structure described in this file
Firmware File Structure Blueprint (RP2040 / RP2350)
src/hardware.rs— Required. Centralize pin assignments, clock constants, peripheral aliases, timer intervals, and other board-specific configuration. Nothing outside this module hardcodes MCU pin numbers or magic frequencies.src/board.rs— Required. Board bring-up; owns peripheral wiring (clocks, GPIO, comms, sensors, USB), exposesBoard/BoardParts(or equivalent). Keep granular comments explaining each hardware init block.src/main.rs— Required. Thin firmware entry; fetch initialized parts, load persisted configuration, configure timers, and run the primary control loop (USB/event poll, scheduling, report generation). Runtime orchestration only.- Feature modules stay single-purpose (e.g.,
inputs.rs,sensors.rs,storage.rs,status.rs,usb_report.rs,usb_device.rs). Each should include unit tests with short intent comments capturing edge cases and data packing, runnable in host mode. - Utility crates (
mapping.rs,calibration.rs, etc.) should avoid cross-module side effects—prefer explicit data passed throughBoardParts/state structs. - Comments document why a block exists or which hardware behaviour it mirrors; avoid repeating obvious code but provide enough context for re-use across RP-series projects.