From 5b2e30dfea9daf9fbf901a93bb7bad2a337a2bd2 Mon Sep 17 00:00:00 2001 From: Robin Mueller Date: Fri, 9 Feb 2024 12:41:20 +0100 Subject: [PATCH] this is a first step --- satrs-book/src/constrained-systems.md | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/satrs-book/src/constrained-systems.md b/satrs-book/src/constrained-systems.md index d604414..84699a3 100644 --- a/satrs-book/src/constrained-systems.md +++ b/satrs-book/src/constrained-systems.md @@ -19,15 +19,29 @@ A huge candidate for heap allocations is the TMTC and handling. TC, TMs and IPC 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 offering 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: +pools. These pools are split into subpools where each subpool can have different page sizes. +For example, a very small telecommand (TC) pool might look like this: ![Example Pool](images/pools/static-pools.png) +The code to generate this static pool would look like this: + +```rust +use satrs_core::pool::{StaticMemoryPool, StaticPoolConfig}; + +let tc_pool = StaticMemoryPool::new(StaticPoolConfig::new(vec![ + (6, 16), + (4, 32), + (2, 64), + (1, 128) +])); +``` + + 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. +to dynamically allocate memory. The same principle can also be applied to the telemetry (TM) and +inter-process communication (IPC) data. # Using special crates to prevent smaller allocations