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.
ux-api can't do rkyv derives and rely on std items in a
no-std environment. This is necessary because some of the
base layer APIs (frame buffers, points, etc.) are relied
upon in a no-std loader environment to render diagnostics
to the screen. Thus ux-api needs to have a baseline of
primitives available without a std flag.
I thought originally cramium-emu would be a library crate, but
actually, it makes more sense as a "services" crate. The APIs
that cramium-emu would live in cramium-api, and cramium-emu
itself is a bit closer to cramium-hal-service, filling in
the executable bits of code that allow emulation to run.
This is a distillation of cramium-hal items into "pure API"
items so that we can have a parallel cramium-emu crate.
The idea is that the API crate sits on top of both implementations;
the HAL goes to hardware, and EMU goes to hosted mode emulations.
a bunch of imports were in here that should be in blitstr2
let's test this out and see how well these abstractions hold up
as we configure the rest of the OS around it.
ux-api is meant to be a platform-independent set of APIs for
elements involving UX interchange in xous. In particular, it
sets up the path for portability of the gfx/minigfx crates and modals.
realizing a bunch of stuff like the stack expects you to enqueue
the OUT receiver with calls to read() that happen to block, fixing
max packet size that can be different for in and out end points,
and handling quirks of the core when sending setup packets longer than
64 bytes.
the UsbBus implementation is being totally rewritten for the
inside-out IRQ protected scheme.
we can now get past some preliminaries in the link protocol
(i.e., address setting and the first config descriptor), but
a long way to go still in debugging.
the uart in the shared library is claimed by the first process
that touches it, so prints in the shared library at early boot have
to be carefully configured
