## Project Overview
mint is an embedded development tool that works with layout files (toml/yaml/json) and excel sheets to assemble, export, sign (and more) static binary files for flashing to microcontrollers.
## Architecture & Codebase
### Core Concepts
- **Layouts**: TOML/YAML/JSON files defining memory blocks (`src/layout`).
- **DataSheet**: Excel workbook (`.xlsx`) serving as the data source (`src/variant`).
- Uses `Name` column for lookups.
- Supports variants via columns (e.g., `Debug`, `VarA`).
- Arrays are referenced by sheet name (prefixed with `#`).
- **Output**: Generates binary files, handling block overlaps and CRC calculations (`src/output`).
### Build Flow
1. **Parse Args**: `clap` defines arguments in `src/args.rs`.
2. **Resolve Blocks**: Parallel loading of layout files (`rayon`).
3. **Build Bytestreams**: Each block is built by combining layout config with Excel data.
4. **Output**: Binary files are generated (either per-block or combined).
### Key Directories
- `src/commands/`: Command implementations (e.g., `build`).
- `src/layout/`: Layout parsing and block configuration.
- `src/variant/`: Excel interaction and value retrieval.
- `src/output/`: Binary generation and data ranges.
## Development Environment
- **Nix**: Use `nix develop` for the environment.
- **Commands**:
- Build: `cargo build`
- Test: `cargo test` (Always run after changes)
- Format: `cargo fmt` (Run before submitting)
- Clippy: `cargo clippy` (Run before submitting)
## Working Guidelines
- **Minimal Changes**: Do only what is asked. Aim to keep changes minimal and focused, and reuse existing code and patterns when possible.
- **Clarification**: Ask if goals are unclear - lay out a clear plan and get feedback before implementing anything.
- **Comments**: No "history" comments (e.g., "changed x to y"). Document current state only.
- **Compatibility**: Do not maintain backwards compatibility unless trivially possible or explicitly requested. Focus on better functionality and cleaner code.
- **Documentation**: functions and structs should be documented with succinct doc comments. Keep documentation (including readme) up to date with the code.
- **Testing**: Add at least unit test and one integration test for each new feature/functionality addition.
