# FreeRusTOS - Design Decisions
Please answer inline after each question (I'll read your answers and proceed accordingly).
---
## 1. Upstream Version
The vendored FreeRTOS-Kernel is at `V10.4.3-744` (development branch), but AGENTS.md recommends `v11.1.0 LTS`.
**Should I checkout the v11.1.0 tag, or proceed with the current development branch?**
Answer: Use the FreeRTOS-Kernel that I already checked out here. Again - other than looking at the Cortex M3 port or DSPIC port for gudance to make a "dummy'/empty port, you can ignore the PORTS dir.
---
## 2. Target Architecture Width
FreeRTOS uses `BaseType_t`, `UBaseType_t`, `StackType_t` which vary by architecture (typically `i32`/`u32` on 32-bit, `i16`/`u16` on 16-bit).
**Should I default to 32-bit types with optional 16-bit via feature flag, or another approach?**
Answer: We will assume a 32b system, I think. Trying to support 16b systems seems impossible. No, actually, that doesn't sound right. There are incresingly 64b systems (like Cortex A53) that FreeRTOS gets used on. If possible, and not brutally complex, supporting 32/64 for the overall system width would be great.
---
## 3. Tick Type Width
FreeRTOS supports 16-bit, 32-bit, or 64-bit tick counters (`TickType_t`).
**Should I default to 32-bit ticks with optional 16/64-bit via feature flags?**
Answer: Not sure here. THis is where some variability MIGHT be nice? but I am not sure if they have var tick widths ONLY to cope with all the different systems it runs on? or maybe this is one of those options for ultra-low resource 32b micros (less RAM).
---
## 4. Memory Allocation Strategy
For `pvPortMalloc`/`vPortFree`, options are:
- (A) Require the `alloc` crate and wrap Rust's global allocator
- (B) Start with stub allocators that panic at runtime
- (C) Both, selectable via Cargo features (e.g., `feature = "alloc"`)
**Which approach should I take?**
Answer: OH, this should all be nostd of course. Yes, wrapping the basic global allocator as a first minimal FreeRTOS malloc would be great! Although this is where I am in the dark - I don't know how to deal with the "pointers" for the alloc/free interface in semantically correct rust. since that interface is sort of not meant to exist in rust. Even though it does ... Box'es and stuff.
---
## 5. SMP (Multi-Core) Support
The kernel has SMP support (`configNUMBER_OF_CORES > 1`). Including it adds complexity.
**Should I start with single-core only (`configNUMBER_OF_CORES = 1`), or include SMP code paths from the start?**
Answer: Start with single core. Add a TODO. I don't know what SMP looks like inside FreeRTOS, so ... single core seems easiest for now.
---
## 6. Co-Routines
FreeRTOS co-routines (`croutine.c`) are a legacy feature, rarely used in modern applications.
**Should I skip co-routines initially, or include them in the port?**
Answer: Skip co-routine support.
---
## 7. Mini List Item Optimization
FreeRTOS has `MiniListItem_t` (a smaller struct for the list end marker) controlled by `configUSE_MINI_LIST_ITEM`.
**Should I start simple (always use full `ListItem_t`), or support both variants from the beginning?**
Answer: I am unfamiliar with this. I do actually want "full feature" coverage for FreeRTOS, so I am inclined to stay START with standard ListItem_t, and TODO for the MiniList, but let's target eventually doing it.
---
## 8. Data Integrity Check Bytes
FreeRTOS can embed magic values in structures for corruption detection (`configUSE_LIST_DATA_INTEGRITY_CHECK_BYTES`).
**Should I support this feature from the start, or defer it?**
Answer: Since this is a FreeRTOS feature, I would like it. AGAIN - unless it is somehow IMPOSSIBLE in rust.
FWIW I am actually QUITE open to doing VERY non-Rust things to accomplish the "C-like code", tricks with structures and such. But the point is - users don't have to look at it. They just have to import the crate and use it.
---
## 9. Trace Macros
FreeRTOS has extensive `traceENTER_*`/`traceRETURN_*` hooks (currently no-ops).
**Should I include these as no-op inline functions from the start (for future tracing support), or omit them initially?**
Answer: I do actually want the macro CALLS included (just tons and tons of text generation), even if they aren't hooked up to anything by default. Which I think they arent, I think those are for users to implement?
---
## 10. First Target Port (M5)
AGENTS.md mentions M5 involves picking a real embedded port (e.g., Cortex-M).
**Do you have a preferred target architecture for the eventual real port, or should I defer this decision?**
Answer: Cortex M4f is always the default easiest target because there are so many of them and I have dev boards. But the ACTUAL GOAL here is to port the CORE FREETOS IMPLEMENTATION, an the port can be empty/dummy for now. If that makes sense.
---