bunnie affe4e6c54 move APIs out of cramium-hal ... So the organization of the code is now the following tiers: libs/cramium-api: contains hardware-abstracted API code to the hardware layers (traits, some constants, enums, etc.). For example, "here is an IO trait that lets you configure and set GPIO pins", which could then be implemented in hardware or emulation. The APIs aren't entirely generic across all SoCs because they are tweaked to accommodate quirks of the cramium SoC. libs/cramium-hal: contains board-specific driver codes that do not require persistent services to be started. Possibly misnamed because it also includes not just cramium-chip items, but also e.g. peripherals to the cramium SoC, such as the PMIC and camera. services/cramium-hal-service: contains the `main` process that manages shared resources, such as UDMA, IO pins, IFRAM. These drivers cannot be delegated to a `lib` crate because there can be only one instance of these resources, and instead we have to dynamically allocate access to these through IPC messaging. services/cramium-emu: hosted mode emulation of things in cramium-hal-service. services/bao-video: contains a `main` process that integrates the camera and OLED driver. This means that all graphic drawing primitives also interface with this crate. These are condensed into a single process space to speed up execution, and kept separate from cramium-hal-services because we want the video services to not be blocked by, for example, a thread that is handling I2C things.		2025-02-20 13:54:46 +08:00
..
src	move APIs out of cramium-hal	2025-02-20 13:54:46 +08:00
Cargo.toml	move APIs out of cramium-hal	2025-02-20 13:54:46 +08:00