Continue adding more contents

Author: theEmbeddedGeorge

Communication_Protocols/High_Speed_Protocols.md

@@ -95,8 +95,11 @@ Explore → [Advanced Hardware](#advanced-hardware) → [Embedded Security](#emb
 
 #### **Phase 1: Real-Time Systems (6 weeks)**
 **RTOS Concepts**
-- **FreeRTOS Basics** - Task creation, scheduling, inter-task communication
-- **Task Creation and Management** - Task states, context switching, stack management
+- **[FreeRTOS Basics](./Real_Time_Systems/FreeRTOS_Basics.md)** - Determinism, tick, scheduler, kernel objects
+- **[Task Creation and Management](./Real_Time_Systems/Task_Creation_Management.md)** - Lifecycle, priorities, stack sizing, timing
+- **[Scheduling Algorithms](./Real_Time_Systems/Scheduling_Algorithms.md)** - RM, DM, EDF, schedulability, jitter
+- **[Interrupt Handling](./Real_Time_Systems/Interrupt_Handling.md)** - ISR design, priorities, FromISR APIs, latency
+ - **[Kernel Services](./Real_Time_Systems/Kernel_Services.md)** - Queues, semaphores, mutexes, event groups, notifications
 - **Scheduling Algorithms** - Round-robin, priority-based, rate monotonic
 - **Interrupt Handling** - ISR design, interrupt latency, nested interrupts
 - **Kernel Services** - Semaphores, mutexes, message queues, event flags

Communication_Protocols/Protocol_Implementation.md

@@ -0,0 +1,183 @@
+# 🧠 FreeRTOS Basics
+
+> Understanding the core ideas of an RTOS and how FreeRTOS applies them in embedded systems
+
+## 📋 Table of Contents
+
+- **Overview**
+- **What is an RTOS?**
+- **Why FreeRTOS?**
+- **Core Concepts**
+- **FreeRTOS Architecture at a Glance**
+- **Timing and the Kernel Tick**
+- **Task Model and States**
+- **Memory and Footprint**
+- **ISRs vs Tasks**
+- **Best Practices and Pitfalls**
+- **Quick Example**
+- **Interview Questions**
+
+---
+
+## 🎯 Overview
+
+Real-Time Operating Systems (RTOS) enable deterministic, predictable execution under constraints like deadlines and bounded latency. FreeRTOS is a lightweight, portable RTOS widely used on MCUs for task scheduling, synchronization, and timing services.
+
+---
+
+## 🤔 What is an RTOS?
+
+- **Determinism**: Bounded response time to events.
+- **Preemption**: Higher-priority tasks can preempt lower-priority tasks.
+- **Scheduling**: Selects the next task to run based on priority and state.
+- **Time Services**: Delays, timeouts, periodic work.
+- **Synchronization**: Safe coordination between concurrent tasks and ISRs.
+
+RTOS ≠ “fast”; it is “predictable.” Deterministic latency is the goal.
+
+---
+
+## 💡 Why FreeRTOS?
+
+- **Portable**: Supports many MCU families and toolchains.
+- **Small Footprint**: Fits into tens of KB of Flash/RAM.
+- **Familiar APIs**: Simple C interface for tasks, queues, semaphores, timers.
+- **Configurable**: Tune features via `FreeRTOSConfig.h`.
+- **Ecosystem**: Rich examples, community, and commercial support (FreeRTOS+).
+
+---
+
+## 🧠 Core Concepts
+
+- **Task**: Independent execution context with its own stack and priority.
+- **Scheduler**: Preemptive priority-based (optional time-slicing among equal priorities).
+- **Tick**: Periodic interrupt that advances time and drives delays/timeouts.
+- **Ready List**: Per-priority queues of tasks ready to run.
+- **Blocked State**: Task waits on time, queue, semaphore, event group, etc.
+- **Critical Sections**: Temporarily suspend preemption for short, atomic work.
+- **Synchronization Primitives**: Queues, semaphores (binary/counting), mutexes (with priority inheritance), event groups, stream/message buffers.
+- **Software Timers**: Deferred work executed in a timer service task.
+
+---
+
+## 🏗️ FreeRTOS Architecture at a Glance
+
+```
+Application Tasks  ─┐  ┌─> Queues/Semaphores/Mutexes/EventGroups
+                     │  │
+Software Timers   ───┼──┤  (Kernel objects in RAM)
+                     │  │
+Idle Task         ───┘  └─> Scheduler (priority-based, preemptive)
+                             ↑
+                             │
+                         SysTick/Timer ISR (kernel tick)
+```
+
+- Each task has a TCB (Task Control Block) + stack.
+- The scheduler selects the highest-priority READY task.
+- The tick interrupt updates delays, unblocks expired tasks, and may trigger a context switch.
+
+---
+
+## ⏱️ Timing and the Kernel Tick
+
+- **Tick Rate (`configTICK_RATE_HZ`)**: Commonly 100–1000 Hz.
+- **Delays**: `vTaskDelay`, `vTaskDelayUntil` use ticks; accuracy is ±1 tick.
+- **Tickless Idle**: Suppress periodic ticks while idle to save power; requires a wake-up source.
+- **Timeouts**: All blocking APIs accept timeouts (in ticks) for deterministic waits.
+
+Design tip: Choose a tick rate that balances timing resolution vs. CPU overhead and power.
+
+---
+
+## 🔁 Task Model and States
+
+States: READY ↔ RUNNING ↔ BLOCKED ↔ SUSPENDED
+
+- **READY**: Eligible to run; waiting for CPU based on priority.
+- **RUNNING**: Currently executing on the CPU.
+- **BLOCKED**: Waiting on time or a kernel object (queue/semaphore/event group).
+- **SUSPENDED**: Not scheduled until explicitly resumed.
+
+Priorities are integer levels; higher value = higher priority (port-dependent). Starvation is possible if a very high-priority task never blocks.
+
+---
+
+## 🧮 Memory and Footprint
+
+- **Per-task Stack**: Size depends on worst-case call depth and ISR usage via `portSAVE_CONTEXT`/`portRESTORE_CONTEXT`.
+- **Kernel Heap**: Selected by `heap_1`..`heap_5`:
+  - `heap_1`: Static bump allocator (no free). Smallest, fastest.
+  - `heap_2`: Free with coalescing. Simple fragmentation handling.
+  - `heap_3`: Wraps `malloc/free`. Depends on C library.
+  - `heap_4`: Best-fit with coalescing. Good fragmentation characteristics.
+  - `heap_5`: Multiple non-contiguous regions. Flexible for constrained MCUs.
+- **Idle Hook / Malloc Failed Hook / Stack Overflow Hook**: Enable for diagnostics.
+
+Choose stack sizes by measurement (watermarking) and enable stack overflow checking.
+
+---
+
+## ⚡ ISRs vs Tasks
+
+- ISRs should be minimal: capture data/state and defer processing to tasks (via queues/stream buffers/event groups).
+- Use the “FromISR” API variants inside interrupts.
+- Ensure correct interrupt priority configuration (only permissive priorities may call FreeRTOS APIs; depends on port and `configMAX_SYSCALL_INTERRUPT_PRIORITY`).
+
+---
+
+## ✅ Best Practices and ⚠️ Pitfalls
+
+Best Practices:
+- Keep high-priority tasks short and frequently blocking.
+- Assign priorities by criticality and latency, not by feature importance.
+- Use bounded queues and timeouts; avoid infinite blocking.
+- Instrument: enable run-time stats and stack high-water marks.
+- Prefer event-driven designs over tight polling.
+
+Pitfalls:
+- Priority inversion without mutexes that implement priority inheritance.
+- Oversized tick rate increasing power and CPU overhead.
+- Excessive heap fragmentation (use `heap_4`/`heap_5` or static allocations).
+- Doing heavy work in ISRs or high-priority tasks leading to starvation.
+
+---
+
+## 🧪 Quick Example (conceptual)
+
+```c
+// Two cooperative tasks using delays; conceptual snippet only
+void vBlinkTask(void* arg) {
+  for (;;) {
+    led_toggle();
+    vTaskDelay(pdMS_TO_TICKS(500)); // periodic blink
+  }
+}
+
+void vButtonTask(void* arg) {
+  for (;;) {
+    if (button_pressed()) {
+      xQueueSend(xEvents, &(int){1}, 0);
+    }
+    vTaskDelay(pdMS_TO_TICKS(10)); // debounce period
+  }
+}
+```
+
+Focus: periodic work with `vTaskDelay`, event passing via a queue, and short duty cycles so higher-priority tasks can preempt.
+
+---
+
+## 🎤 Interview Questions
+
+1. What makes an RTOS “real-time” and how is that different from “fast”?
+2. Explain the role of the kernel tick and how tickless idle works.
+3. Describe task states and how tasks transition between them.
+4. How would you size task stacks and select a heap scheme on a constrained MCU?
+5. Why should ISR work be minimized and deferred? How is that implemented in FreeRTOS?
+
+---
+
+Next: See `Task_Creation_Management.md` for deeper task lifecycle, priorities, and stack management.
+
+

Communication_Protocols/Wireless_Protocols.md

@@ -0,0 +1,102 @@
+# 🧨 Interrupt Handling in RTOS-Based Systems
+
+> Concepts for low-latency ISRs, nesting, priority mapping, and deferring work to tasks
+
+## 📋 Table of Contents
+
+- Overview
+- Interrupt Latency and Determinism
+- ISR Design Principles
+- Interrupt Priorities and Kernel Interaction
+- Deferring Work to Tasks
+- Synchronization From ISRs
+- Measuring and Tuning Latency
+- Best Practices and Pitfalls
+- Interview Questions
+
+---
+
+## 🎯 Overview
+
+Interrupts handle urgent, asynchronous events with minimal latency. In RTOS systems, ISRs should be short and primarily signal tasks to perform the bulk of work. Proper priority configuration and correct use of FromISR APIs are essential for determinism.
+
+---
+
+## ⏱️ Interrupt Latency and Determinism
+
+- **Sources of Latency**: Interrupt masking, critical sections, higher-priority ISRs, memory wait states.
+- **Determinism Goal**: Bound the worst-case latency; keep critical sections short and minimize nested work.
+- **Jitter**: Variability in latency; reduce by avoiding long non-preemptible sections and heavy ISRs.
+
+---
+
+## 🛠️ ISR Design Principles
+
+- Do the minimum necessary in the ISR: capture timestamp/data, clear the source, and signal a task.
+- Avoid blocking, dynamic memory, or long loops in ISRs.
+- Ensure the ISR is reentrant or protect shared state.
+- Use volatile-qualified shared variables and atomics where required.
+
+---
+
+## 🎚️ Interrupt Priorities and Kernel Interaction
+
+- On Cortex-M, lower numeric priority value = higher urgency; only priorities numerically larger (less urgent) than `configMAX_SYSCALL_INTERRUPT_PRIORITY` may call RTOS APIs.
+- The kernel may disable interrupts briefly for critical sections; keep those sections small in drivers.
+- Nesting: A higher-priority interrupt can preempt a lower one; keep nesting depth small to bound latency.
+
+---
+
+## 📬 Deferring Work to Tasks
+
+Common patterns:
+- **Queue to Task**: Send a message from ISR to a worker task.
+- **Event Group**: Set bits to notify events.
+- **Stream/Message Buffer**: Transfer bytes/messages efficiently to a single receiver.
+- **Direct-to-Task Notifications**: Lightweight, fast signaling to a specific task.
+
+Benefits: keeps ISRs short, leverages task priorities, and eases testing.
+
+---
+
+## 🔗 Synchronization From ISRs
+
+- Use the `...FromISR` API variants (e.g., `xQueueSendFromISR`, `xTaskNotifyFromISR`).
+- Pass `pxHigherPriorityTaskWoken`/`xHigherPriorityTaskWoken` and request a context switch if needed.
+- Never use mutex APIs from ISRs; use semaphores or notifications. Mutexes implement priority inheritance and are task context only.
+
+---
+
+## 🔍 Measuring and Tuning Latency
+
+- **Instrumentation**: Toggle a GPIO at ISR entry/exit and measure with a logic analyzer.
+- **Cycle Counters**: Use DWT cycle counter (Cortex-M) for fine-grained timing.
+- **Trace Tools**: Kernel trace to observe ISR-to-task wakeups and scheduling.
+- **Tuning**: Reduce critical sections, lower tick rate if it causes contention, optimize memory wait states.
+
+---
+
+## ✅ Best Practices and ⚠️ Pitfalls
+
+Best Practices:
+- Keep ISRs short; defer to tasks.
+- Use the smallest interrupt priority capable of meeting latency needs.
+- Validate `configPRIO_BITS`, NVIC priorities, and `configMAX_SYSCALL_INTERRUPT_PRIORITY`.
+- Use direct-to-task notifications for fastest signaling.
+
+Pitfalls:
+- Calling non-FromISR APIs in interrupt context.
+- Misconfigured NVIC priorities leading to hard faults or non-determinism.
+- Heavy computation in ISRs causing jitter and missed deadlines.
+
+---
+
+## 🎤 Interview Questions
+
+1. What contributes to interrupt latency, and how do you bound it?
+2. Why should ISR work be minimized and deferred to tasks? How do you implement that?
+3. Which RTOS APIs are safe to call in an ISR and why?
+4. How do you configure NVIC priorities to work correctly with an RTOS?
+5. How would you measure ISR latency on a Cortex-M MCU?
+
+