Crates

This section is an architecture map of the library crates used by Core modules and executable crates.

Compared with Modules, these crates define reusable contracts, data models, and helper layers. Stateful orchestration happens in explicitly owned managers (for example task/users/virtual_file_system), while crates provide the typed interfaces those modules and executables consume.

Architecture map

Foundation and cross-cutting

• Shared: common low-level types (shared::flags, units, HTTP/time helpers, UTF-8/slice utilities).
• Synchronization: synchronization facade (Arc + embassy_sync re-exports).
• Target: build-target introspection from Cargo environment.
• Internationalization: external embedded-i18n integration, build-time locales, and font ranges.

Storage and device contract stack

• File System: core path/metadata/device/file-system traits.
• Little FS: concrete FileSystemOperations backend on top of littlefs2-sys.
• Device: typed control commands for device endpoints (currently hash commands).
• Peripherals: compact shared pin-state payload model.

Runtime-facing crates

• Executable: executable contract and launcher path (GET_MAIN_FUNCTION, execute).
• Authentication: persistent users/groups + password verification routines.
• Bootsplash: startup animation crate integrated with graphics manager/LVGL.
• Testing: host-oriented integration runtime assembly for tests.

Reading order (crates-first)

This order stays neutral and follows dependency direction from shared abstractions to runtime usage:

1. Shared
2. Synchronization
3. Target
4. Internationalization
5. File System
6. Little FS
7. Device
8. Peripherals
9. Executable
10. Authentication
11. Bootsplash
12. Testing

Contract vs implementation

• Contract: this index documents stable architecture boundaries and navigation order for crate-level contracts.
• Current implementation: the mapped crates correspond to the current Core workspace crate layout and dependency direction.