24 lines
1.8 KiB
Markdown
24 lines
1.8 KiB
Markdown
# 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), exposes `Board`/`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 through `BoardParts`/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.
|