Conversation
The hardware specification hierarchy is clarified to be as such: - A `soc` flag specifies dependencies that are generic to a system-on-chip (SoC). For example, the locations of registers, or the extents of memory regions contained in the `soc`. - A `board` flag specifies dependencies that are specific to a board. For example, the resolution of displays, pin mappings to peripherals, and sizes of external memory. Typically, a board assumes a `soc`, so both a `board-*` and `*-soc` set of flags are required to fully specify a build. - Precursor (the first target for Xous) did not hold to this abstraction and conflated the two, so it is a special case in the build system. - "Hosted" mode emulations are considered to be a `board` target; the `soc` is assumed to be the host (linux, windows, etc.) Since all builds require a `board` specifier, documentation now requires a `doc-deps` flag to be passed. This effectively specifies a set of dummy board dependencies so that the documentation can build. Here is the recommended command line for building docs: `cargo doc --no-deps --feature doc-deps`
this is where we'll try to aggregate all the shims that allow the target to work on hosted mode
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.
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.
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.
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.
also condense main into a single routine again, now that we have gone through the trouble of creating interoperable APIs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refactor the API for the baochip (formerly cramium) target to make code interoperable between hosted mode, as well a the various board targets planned.
All targets compile, but lots of warnings still on the baochip side. The stubs exist to create the graphics layer for the baosec hosted mode but the actual emulation fails because none of the stubs have been implemented.
A README is added to help document the overall organization that the code has landed in.