gneiss
gneiss copied to clipboard
Framework for platform-independent SPARK components
This could also mean that all components run on a microcontroller with a bare-metal runtime. We need: - Image containing multiple components - "Kernel" scheduling components
Goal: Implement graphics driver for PINETIME using Framebuffer session
Create an SPI driver that enables the usage of the display.
We should run `black` (and possibly the the other linters we use in RecordFlux) on `cement` as it grows bigger.
Currently the global platform state is modelled by `Platform_State` This state however is not volatile. Some inputs, e.g. a timer require `Async_Writers` to be modelled correctly. This could be solved...
Idea: - Gneiss Log Client - Gneiss Log Server to Matrix proxy - Matrix client - JWX - HTTP/2 library (using RecorFlux) - Stream interface - GreenTLS component - Input:...
The current project has seen many architectural changes, especially on Linux. The current state, while it works for the tests is still in the state of a proof of concept...
Use know-good image for testing the setup.
Fix file descriptor leaks on Linux
Usable for hardware and software interrupts. Applications just use names/references for events.