Update content

Author: theEmbeddedGeorge

Advanced_Hardware/Vector_Processing_FPUs.md

@@ -32,6 +32,11 @@ I2C (Inter-Integrated Circuit) is a synchronous, multi-master, multi-slave, pack
 - **Clock stretching** - Slaves can slow down communication
 - **Arbitration** - Non-destructive arbitration for bus access
 
+### **Interviewer intent (what they’re probing)**
+- Can you explain open‑drain + pull‑ups and rise‑time limits?
+- Do you understand arbitration and clock stretching behavior?
+- Can you reason about bus speed vs capacitance?
+
 ## 🤔 **What is I2C Protocol?**
 
 I2C protocol is a synchronous serial communication standard that enables multiple devices to communicate over a shared two-wire bus. It uses a master-slave architecture with support for multiple masters, making it ideal for connecting multiple integrated circuits, sensors, and peripheral devices in embedded systems.

Communication_Protocols/I2C_Protocol.md

@@ -32,6 +32,11 @@ Serial Peripheral Interface (SPI) is a synchronous serial communication protocol
 - **Chip select management** - Individual slave selection
 - **Configurable clock modes** - Flexible timing requirements
 
+### **Interviewer intent (what they’re probing)**
+- Can you explain CPOL/CPHA and timing setup/hold?
+- Do you know how chip‑select timing affects multi‑slave buses?
+- Can you reason about throughput vs CPU/DMA trade‑offs?
+
 ## 🤔 **What is SPI Protocol?**
 
 SPI protocol is a synchronous serial communication standard that enables high-speed data exchange between a master device (typically a microcontroller) and one or more slave devices (peripherals such as sensors, memory chips, displays, etc.). It uses a shared clock signal to synchronize data transmission, ensuring reliable and efficient communication.

Communication_Protocols/SPI_Protocol.md

@@ -33,6 +33,11 @@ UART (Universal Asynchronous Receiver/Transmitter) is a widely used serial commu
 - **Error Detection**: Parity checking, frame errors, overrun detection
 - **Flow Control**: Hardware and software flow control mechanisms
 
+### **Interviewer intent (what they’re probing)**
+- Can you explain framing, baud tolerance, and typical errors?
+- Do you know when to use hardware vs software flow control?
+- Can you design a robust RX/TX buffering strategy?
+
 ---
 
 ## 🧠 **Concept First**

Communication_Protocols/UART_Protocol.md

@@ -55,6 +55,11 @@ static inline void reg_set_mode(uint32_t mode) {
 - Define `*_Pos` and `*_Msk` macros or enums; avoid magic numbers.
 - Document endianness where on-wire vs in-memory order differs.
 
+### Interviewer intent (what they’re probing)
+- Can you update a bitfield without breaking neighbors?
+- Do you understand UB around shifts and signed types?
+- Can you reason about endianness and on-wire layouts?
+
 ---
 
 ## 🧪 Guided Labs

Embedded_C/Bit_Manipulation.md

@@ -144,22 +144,22 @@ C is primarily a **procedural programming language**, which means:
 
 ### **Memory Model**
 
-C uses a **static memory model** with manual memory management:
+C defines an abstract machine; the actual memory layout is implementation-defined. Embedded targets typically place code in Flash/ROM and data in RAM, and the linker script controls section placement.
 
 ```
-C Memory Layout:
+Typical Embedded Memory Layout (varies by target/toolchain):
 ┌─────────────────────────────────────────────────────────────┐
 │                    Stack (Local Variables)                 │
-│                    ↓ Grows downward                       │
+│                    ↓ Often grows downward                 │
 ├─────────────────────────────────────────────────────────────┤
 │                    Heap (Dynamic Memory)                  │
-│                    ↑ Grows upward                         │
+│                    ↑ Often grows upward                   │
 ├─────────────────────────────────────────────────────────────┤
-│                    .bss (Uninitialized Data)              │
+│                    .bss (Zero-initialized Data)            │
 ├─────────────────────────────────────────────────────────────┤
-│                    .data (Initialized Data)               │
+│                    .data (Initialized Data)                │
 ├─────────────────────────────────────────────────────────────┤
-│                    .text (Code)                           │
+│                    .text/.rodata (Code/Const)              │
 └─────────────────────────────────────────────────────────────┘
 ```
 
@@ -203,10 +203,10 @@ C uses a **static type system** with **weak typing**:
 ### **Scope and Lifetime**
 
 **Scope Rules:**
-- **File Scope**: Variables declared outside functions
-- **Function Scope**: Variables declared inside functions
-- **Block Scope**: Variables declared inside code blocks
-- **Global Scope**: Variables accessible throughout the program
+- **File Scope**: Identifiers declared outside any function
+- **Block Scope**: Identifiers declared inside `{}` blocks (including function bodies)
+- **Prototype Scope**: Parameter names in function prototypes
+- **Function Scope**: Labels only (used with `goto`)
 
 **Lifetime Rules:**
 - **Automatic**: Local variables (stack-based)
@@ -306,8 +306,8 @@ long     also_variable;       // Size varies by platform
 
 #### **Floating Point Types**
 ```c
-float    single_precision;    // 32-bit IEEE 754
-double   double_precision;    // 64-bit IEEE 754 (avoid in embedded)
+float    single_precision;    // Typically 32-bit IEEE 754
+double   double_precision;    // Implementation-defined (32 or 64-bit)
 ```
 
 #### **Character Types**
@@ -623,9 +623,9 @@ Memory management in C involves allocating, using, and freeing memory resources.
 
 **Memory Types:**
 - **Stack Memory**: Automatic allocation for local variables
-- **Heap Memory**: Dynamic allocation with malloc/free
-- **Static Memory**: Global and static variables
-- **Constant Memory**: Read-only data and code
+- **Heap Memory**: Dynamic allocation with malloc/free (if enabled)
+- **Static Storage**: Global and static variables
+- **Flash/ROM**: Read-only code and const data (platform concept)
 
 **Memory Lifecycle:**
 - **Allocation**: Requesting memory from the system
@@ -765,7 +765,7 @@ An array name in an expression decays to a pointer to its first element. The arr
 
 ### Why it matters in embedded
 - Knowing when decay happens prevents bugs with `sizeof` and parameter passing.
-- Arrays placed in Flash as `static const` look like ordinary arrays but are read‑only and may require `volatile` when mapped to hardware.
+- Arrays placed in Flash as `static const` look like ordinary arrays but are read‑only; use `volatile` only for memory‑mapped registers or data changed by hardware/ISRs.
 
 ### Minimal example: decay and sizeof
 ```c
@@ -959,6 +959,7 @@ typedef union {
     uint8_t raw[34];
 } protocol_message_t;
 ```
+> Note: Type-punning through unions is implementation-defined in C. For strict portability, use `memcpy` to move between object representations.
 
 ## 🔧 **Preprocessor Directives**
 
@@ -1293,8 +1294,9 @@ ptr = NULL;  // Prevent use-after-free
 - **GDB**: GNU Debugger
 
 ### **Standards**
-- **C11**: Current C language standard
-- **C99**: Previous C language standard
+- **C11**: Widely used in embedded toolchains
+- **C17/C18**: Bug-fix revision of C11
+- **C23**: Latest ISO C standard (toolchain support varies)
 - **MISRA C**: Safety-critical coding standard
 
 ---

Embedded_C/C_Language_Fundamentals.md

@@ -49,6 +49,11 @@ static inline uint32_t periph_ready(void) { return (PERIPH->STAT & 1u) != 0u; }
 - Be explicit about read-only/write-only semantics via `const` on `volatile` fields.
 - Consider memory barriers for ordering on platforms that require them.
 
+### Interviewer intent (what they’re probing)
+- Can you model registers safely and clearly in C?
+- Do you know why `volatile` matters and what it doesn’t solve?
+- Can you explain read‑modify‑write hazards and ordering?
+
 ---
 
 ## 🧪 Guided Labs

Embedded_C/Memory_Mapped_IO.md

@@ -40,6 +40,11 @@ void add_buffers(uint16_t* restrict a, const uint16_t* restrict b, size_t n){
 - Be mindful of strict aliasing; stick to the same effective type or `memcpy`.
 - Prefer `restrict` only when you can prove non-aliasing.
 
+### Interviewer intent (what they’re probing)
+- Can you explain lifetime, aliasing, and safe access patterns?
+- Do you know when to use `volatile` vs `const` vs `restrict`?
+- Can you reason about pointer decay and address arithmetic?
+
 ---
 
 ## 🧪 Guided Labs

Embedded_C/Pointers_Memory_Addresses.md

@@ -53,6 +53,11 @@ void copy_fast(uint8_t * restrict dst, const uint8_t * restrict src, size_t n);
 - `const` expresses intent and may change placement; don’t cast it away to write.
 - Use `restrict` only when you can prove no aliasing.
 
+### Interviewer intent (what they’re probing)
+- Do you know when `volatile` is required and when it is insufficient?
+- Can you explain how `const` affects placement and safety?
+- Do you understand aliasing and when `restrict` is valid?
+
 > Platform note: For I/O ordering on some MCUs/SoCs, pair volatile accesses with memory barriers when required by the architecture.
 
 ---

Embedded_C/Type_Qualifiers.md

@@ -46,6 +46,11 @@ Choose edges to capture transitions; levels to detect sustained conditions. Alwa
 - **Interrupt Latency** - Time from interrupt occurrence to handler execution
 - **Debouncing** - Eliminating false triggers from mechanical switches
 
+### **Interviewer intent (what they’re probing)**
+- Can you choose edge vs level correctly and explain why?
+- Do you know how to keep ISRs short and safe?
+- Can you reason about latency, priority, and masking?
+
 ---
 
 ## 🔍 Visual Understanding