Home
"Every Universe of Discourse has its logical structure." (Langer, 1929)
“Real-time” has become a catch-all term, often used to describe online interactive or simply fast systems. However, this isn’t a correct definition. With so many loose terms, at least this one is solid:
A system is real-time if any of its responses must be completed within a guaranteed time frame, regardless of execution time, considering interference from other tasks, if it is concurrent.
So, if concurrency is already difficult, when you need to bind it to real-time responsiveness, you will eventually start asking yourself whether we have the right tools for the job. The crude answer is: we don't. Response time emerges from implementation. To increase our chances of getting it right, we need a simple mental model.
The Docbook provides design internals, rationale for design choices, some theory, and rich usage examples.
The User manual is a streamlined description of the services (no kernel internals or rationales are exposed).
1. The Execution model:
The Execution Image is a single-process. Roughly speaking, we enable concurrency within a single process by composing a thread of execution with a unique portion of the running stack. This composition gives us a schedulable unit, which we chose to call a Task. System Tasks and User Tasks have different stack pointers, but user tasks run privileged. The rationale for this choice is in the Docbook; to summarise, it is a choice of non-compromising analysability and responsiveness for the given target systems. The rationale behind this choice is detailed in the Docbook. Essentially, it’s about maintaining analysability and responsiveness given the target systems: constrained firms and hard real-time application-specific computers.
2. The Design Ethos and the Real-Time Model:
RK0 design has a clear real-time model, summarised in the diagram below. Further details are available in the links above and the Service Semantics wiki. The main characteristic of the real-time model in RK0 can be summarised as: there is always a known reason for execution progress. This is the “0 surprises” guideline. This model is not a minor detail; it underpins every design decision.
We are talking about CPUs in the range of 8-256 KiB of RAM. Application-specific needs for dynamic allocation and deallocation, as well as some kernel mechanisms, make use of an allocator that suits real-time demands: fixed-size blocks, word-aligned, O(1).
Shared-state and message-passing are supported. In theory, you could use both, but that would be counterintuitive, as they are different ways of thinking of an application design and would probably just complicate things, mainly when ownership is a matter. The application.c in the repo has many examples.
-
RK0 is a suitable system whose quality of service degrades quickly when not meeting time constraints. Tasks can't be unaware of each other and are actually cooperating concurrent units. The solution is domain-dependent. The hardware is domain-dependent. The deployed application was tested and is trusted. This is the typical closed model that most real-time critical applications fit.
-
It doesn't target any solution that until recently was handled by MMU-equipped, moderately powerful devices, running tailored full-fledged OSes (historically BSDs, until Linuxes prevailed); anything that faces it on the web, exposing to a high attack surface.
Functional Requirements mapping to test cases
Every modular mechanism has a list of requirements identified by a unique ID, along with a unit test case.
Q: Why is there no release yet?
A: A release is serious stuff. v1.0.0 will come when I can push:
-
a good Trace mechanism (a UART trace is operational but I am targeting something better)
-
can provide meaningful and honest system characterisation (the Wiki has meaningful measurements, although I want to raise the bar)
-
the test harness in a way it works for any potential contributors (it works on my computer)