chore: preserve FreeRTOS and C series updates

plans/informatyka/freertos-c.md

@@ -1,8 +1,8 @@
 # FreeRTOS C — book-led card sequence
 
-Status: FC01–FC02 exist; FC03 is the next implementation; FC04–FC15 are
-planned. This series uses only the FreeRTOS C API. C++ wrappers belong to a
-later, separate series.
+Status: FC01–FC15 istnieją; blok 15 kart FreeRTOS C jest kompletny i stanowi
+zamknięty fundament przed serią FreeRTOS C++. Każda karta używa publicznego
+API C, a końcowa FC15 scala mechanizmy w jeden deterministyczny eksperyment.
 
 ## Primary source and ordering rule
 
@@ -62,7 +62,7 @@ simulator.
 
 ```text
 FreeRTOS C — 15 cards
-├── FC01 · Heap schemes and heap_4 block mechanics
+├── FC01 · heap_4: from a linear cursor to reusable blocks
 ├── FC02 · First task, typed context, TCB and task stack
 ├── FC03 · Tick, priorities, preemption and time slicing
 ├── FC04 · Delay, blocking, task states and deletion
@@ -79,22 +79,37 @@ FreeRTOS C — 15 cards
 └── FC15 · Integrated deterministic FreeRTOS C application
 ```
 
-## FC01 — Heap schemes and heap_4 block mechanics
+## FC01 — `heap_4`: from a linear cursor to reusable blocks
 
-**Book basis:** 3.1–3.4: `heap_1`–`heap_5`, heap utilities, allocation
-failure and static allocation introduction.
+**Duration:** one 30-minute lesson.
 
+**Direct predecessor:** C07, K&R 5.4 Task04 — `allocbuf[64]`, `allocp`,
+`alloc(5)`, `alloc(7)` and cursor offsets `0 -> 5 -> 12`.
+
+**Book basis:** the `heap_4` and heap-statistics parts of Chapter 3. The other
+FreeRTOS heap implementations are a one-minute map of alternatives, not
+parallel lesson content.
+
+- Opening problem: the linear project cannot release the first 5-byte area
+  while preserving the later 7-byte area, cannot remember reusable holes and
+  recovers the arena only with a whole-arena reset.
+- New model: a block header, an address-ordered free list, first-fit selection,
+  splitting and coalescing of physically adjacent free blocks.
 - Raw API: `pvPortMalloc`, `vPortFree`, `xPortGetFreeHeapSize`,
   `xPortGetMinimumEverFreeHeapSize`, `vPortGetHeapStats`.
-- Main task: compare allocator policies, then walk allocation, split, free
-  and coalescing in `heap_4`.
-- Blocks: A1 allocator boundary; A2 block/list layout; A5 allocation flow;
-  A6 free/allocated block state; A7 heap addresses and statistics.
-- Exercise: predict the free-list shape for a new allocate/free order.
-- Hazard3/GDB proof: block headers, aligned sizes and coalesced neighbors
-  agree with the final heap statistics.
-- Main pitfall: treating the minimum-ever-free value as current free space or
-  assuming all heap implementations support free/coalescing.
+- Task 1 and Task 2 are short teacher-led models with a student prediction;
+  they are not separate build/debug sessions during the lesson.
+- Task 3 is the only central student replay: real upstream `heap_4.c`, two
+  stable checkpoints, fragmentation metrics, recovery and OOM.
+- Pico 2 W supplies one prebuilt RP2350 hardware observation. `heap_4` is the
+  allocator selected and linked by the project, not a hardware feature of the
+  microcontroller.
+- Acceptance: the student names the three additions over the linear allocator
+  (header, free list, coalescing), predicts `2 free blocks -> 1 free block`,
+  and distinguishes current free bytes, largest free block and minimum-ever
+  free bytes.
+- Main pitfall: assuming that a large sum of free bytes guarantees one large
+  allocation, or that minimum-ever-free increases after `free`.
 
 ## FC02 — First task, typed context, TCB and task stack
 
@@ -367,10 +382,12 @@ Every new card must contain:
 8. HTML and TeX generated from one `card_source.json`;
 9. no PDF generation and no commit unless explicitly requested.
 
-## Implementation order
+## Completed implementation order
 
 ```text
-FC03 scheduler
+FC01 heap_4
+→ FC02 first task
+→ FC03 scheduler
 → FC04 state/delay
 → FC05 queues
 → FC06 software timers
@@ -385,5 +402,7 @@ FC03 scheduler
 → FC15 integration
 ```
 
-Ukończenie FC15 jest pierwszą z dwóch bramek wejścia do FreeRTOS C++; drugą
-jest ukończenie właściwych kart językowych C++/OOP.
+Obie bramki wejścia do FreeRTOS C++ są spełnione: FC15 zamyka tor systemowy C,
+a właściwe karty językowe C++/OOP dostarczają model własności, RAII, szablony i
+statyczne trampoline. Następnym etapem jest audyt i realizacja serii FreeRTOS
+C++ karta po karcie, bez mieszania wrapperów z implementacją kernela w C.