a vim plugin that displays stuff on an led matrix
dunkirk.sh
1# CRUSH.md - Daedalus Project Guidelines
2
3## Build Commands
4- Setup environment: `direnv allow`
5- Build firmware: `cd firmware && make`
6- Flash to RP2350: `cd firmware && make flash`
7- Disassemble: `cd firmware && make disasm`
8- Clean build: `cd firmware && make clean`
9- Format code: `clang-format -i firmware/src/*.cpp firmware/src/*.h`
10- Lint code: `cppcheck --enable=all firmware/src/`
11
12## Test Commands
13- Run all tests: `ctest -S build`
14- Run single test: `ctest -R <test_name> -V`
15
16## Code Style Guidelines
17
18### General
19- Use 2-space indentation
20- Max line length: 100 characters
21- UTF-8 encoding for all files
22- Follow Google C++ Style Guide with modifications in .clang-format
23
24### Naming Conventions
25- Classes: PascalCase (e.g., `LedController`)
26- Functions: camelCase (e.g., `initializeHardware()`)
27- Variables: camelCase (e.g., `ledPin`)
28- Constants: UPPER_SNAKE_CASE (e.g., `MAX_BUFFER_SIZE`)
29- Files: snake_case.ext (e.g., `led_controller.cpp`)
30
31### Error Handling
32- Use return codes for error reporting
33- Check return values from SDK functions
34- Use assertions for invariants
35- Avoid dynamic memory allocation when possible
36
37### Nix Development
38- Pico SDK is provided via nixpkgs with withSubmodules override
39- All tools are managed through Nix
40- Use `nix flake update` to update dependencies
41
42## Code Style Guidelines
43
44### General
45- Use 2-space indentation
46- Max line length: 100 characters
47- UTF-8 encoding for all files
48
49### Naming Conventions
50- Functions/methods: camelCase
51- Variables: camelCase
52- Constants: UPPER_SNAKE_CASE
53- Classes: PascalCase
54- Files: kebab-case.ext
55
56### Error Handling
57- Use explicit error handling (no silent failures)
58- Log errors with appropriate context
59- Return meaningful error messages
60
61### Comments
62- Use JSDoc-style comments for functions
63- Keep comments current with code changes
64- Explain "why" not "what" in comments
65
66### Git Practices
67- Commit messages: Start with verb in present tense
68- Keep commits focused on single changes
69- Reference issues in commit messages when applicable