From 3bffa8ed83280bdc8db634a344631b31170b7f55 Mon Sep 17 00:00:00 2001 From: Robin Mueller Date: Wed, 30 Aug 2023 19:15:38 +0200 Subject: [PATCH] added chapter for constrained systems --- satrs-book/src/constrained-systems.md | 43 +++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/satrs-book/src/constrained-systems.md b/satrs-book/src/constrained-systems.md index e69de29..ba18e29 100644 --- a/satrs-book/src/constrained-systems.md +++ b/satrs-book/src/constrained-systems.md @@ -0,0 +1,43 @@ +# Working with Constrained Systems + +Software for space systems oftentimes has different requirements than the software for host +systems or servers. Currently, most space systems are considered embedded systems. + +For these systems, the computation power and the available heap are the most important resources +which are constrained. This might make completeley heap based memory management schemes which +are oftentimes used on host and server based systems unfeasable. Still, completely forbidding +heap allocations might make software development unnecessarilly difficult, especially in a +time where the OBSW might be running on Linux based systems with 500 MB RAM. + +A useful pattern used commonly in space systems is to limit heap allocations to program +initialization time and avoid frequent run-time allocations. This prevents issues like +running out of memory (something event Rust can not protect from) or heap fragmentation. + +# Using pre-allocated pool structures + +A huge candidate for heap allocations is the TMTC and handling. TC, TMs and IPC data are all +candidates where the data size might vary greatly. The regular solution for host systems +might be to send around this data as a `Vec` until it is dropped. `sat-rs` provides +another solution to avoid run-time allocations by pre-allocated static pools. + +These pools are split into subpools where each subpool can have different page sizes. +For example, a very small TC pool might look like this: + +TODO: Add image + +A TC entry inside this pool has a store address which can then be sent around without having +to dynamically allocate memory. The same principle can also be applied to the TM and IPC data. + +# Using special crates to prevent smaller allocations + +Another common way to use the heap on host systems is using containers like `String` and `Vec` +to work with data where the size is not known beforehand. The most common solution for embedded +systems is to determine the maximum expected size and then use a pre-allocated `u8` buffer and a +size variable. Alternatively, you can use the following crates for more convenience or a smart +behaviour which at least reduced heap allocations: + +1. [`smallvec`](https://docs.rs/smallvec/latest/smallvec/). +2. [`arrayvec`](https://docs.rs/arrayvec/latest/arrayvec/index.html) which also contains an + [`ArrayString`](https://docs.rs/arrayvec/latest/arrayvec/struct.ArrayString.html) helper type. +3. [`tinyvec`](https://docs.rs/tinyvec/latest/tinyvec/). +