Welcome to My Digital Garden

Truth Table X Y X & Y X | Y X ^ Y 0 0 0 0 0 0 1 0 1 1 1 0 0 1 1 1 1 1 1 0 Points to Remember The left-shift and right-shift operators should not be used for negative numbers Left Shift(<<) just means multiply by 2. Similarly >> results division by 2. XOR results 0 if both bits are same. So a^1=~a , a^0=a and a^a=0. Questions How to toggle or flip a particular bit in a number? To toggle any bit in a variable, Use (^) exclusive OR operator. #define togglebit(data, bit) (data* = data ^ (1<<bit)) Write MACRO to Swap the bytes in 16bit Integer Variable. #define ByteSwap16(Value) ((Value & 0x00FF) << 8) | ((Value & 0xFF00) >> 8) #define ByteSwap32(Value) ((Value & 0x000000FF) << 24) | ((Value & 0x0000FF00U) << 8) | ((Value & 0x00FF0000U) >> 8) | ((Value & 0xFF000000U) >> 24) Count the number of set bits in a number unsigned int countSetBits( unsigned int number ) { unsigned int count = 0; while( number != 0) { count++; number &= (number-1); } return count; } Swap 2 bits of given integer int swapBits(unsigned int n, unsigned int p1, unsigned int p2) { unsigned int bit1 = (n >> p1) & 1; /* Move p1'th to rightmost side */ unsigned int bit2 = (n >> p2) & 1; /* Move p2'th to rightmost side */ unsigned int x = (bit1 ^ bit2); /* XOR the two bits */ /* Put the xor bit back to their original positions */ x = (x << p1) | (x << p2); /* XOR 'x' with the original number so that the two sets are swapped */ unsigned int result = n ^ x; }

Introduction GPIO (General Purpose Input/Output) is a fundamental interface in embedded systems and Linux-based platforms. Linux provides multiple methods to control GPIOs, including the deprecated /sys/class/gpio/ interface and the modern libgpiod (GPIO character device) API. This document provides a comprehensive guide to managing GPIOs in Linux. GPIO Interfaces in Linux Linux provides three primary ways to manage GPIOs: Legacy Sysfs Interface (/sys/class/gpio/) - Deprecated but still present on some systems. GPIO Character Device (/dev/gpiochipX) - The recommended approach using libgpiod. Direct Kernel Access - Through kernel drivers or device tree configurations. 1. Sysfs GPIO Interface (Deprecated) The sysfs-based interface was historically used to control GPIOs but has been marked as deprecated in favor of gpiod. If still available, it can be accessed via /sys/class/gpio/. ...

Overview A Bayer filter is a color filter array (CFA) that arranges RGB color filters on a square grid of photosensors. Color Sensitivity Digital image sensors can only detect brightness, not color. To produce color sensors, a color filter is applied to each pixel. Generally the sensor is divided into 50% green, 25% red, and 25% blue photosites. G R G R B G B G G R G R B G B G Demosaicing Each pixel is filtered to record only one of three colors, so the data from each pixel cannot fully specify each of the red, green, and blue values on its own. To obtain a full-color image, demosaicing algorithms are used to interpolate a set of complete red, green, and blue values for each pixel. The color of each pixel is interpolated by those around it. ...

SPI (Serial Peripheral Interface) Overview Synchronous, full-duplex serial bus. Master-slave architecture (1 master, multiple slaves). Uses 4 wires: SCLK (clock), MOSI (Master Out Slave In), MISO (Master In Slave Out), SS/CS (Slave Select). Physical Layer Push-pull outputs (faster than open-drain). Each slave requires a dedicated SS line. Data Frame Structure No start/stop bits – continuous stream synchronized to SCLK. Data sampled on clock edges defined by CPOL (clock polarity) and CPHA (clock phase): Mode 0: CPOL=0 (idle low), CPHA=0 (sample on rising edge). Mode 3: CPOL=1 (idle high), CPHA=1 (sample on falling edge). SCLK | MOSI (Data from Master) | MISO (Data from Slave) | CS (Active Low) Key Features Full-duplex communication (simultaneous MOSI/MISO). No addressing – slaves selected via SS lines. Speeds: Up to 100+ Mbps (depends on hardware). Pros & Cons Pros Cons High-speed communication High pin count (n+3 for n slaves) Simple protocol, flexible modes No built-in error detection Full-duplex support No multi-master support Use Cases High-speed sensors (e.g., IMUs). Display controllers (OLED, TFT). SD cards, NOR flash memory. Comparison Table Feature UART I2C SPI Clock None (async) Shared (SCL) Shared (SCLK) Duplex Full-duplex Half-duplex Full-duplex Topology Point-to-point Multi-device Master-slave Speed Low (≤115kbps) Moderate (≤3.4Mbps) High (≥10Mbps) Addressing None 7/10-bit Hardware (SS lines) Pins 2 (TX/RX) 2 (SCL/SDA) 4 + n (SS per slave) Error Handling Parity bit ACK/NACK None

UART (Universal Asynchronous Receiver-Transmitter) UART is a simple, asynchronous serial communication protocol used for full-duplex communication between two devices. Key Features: Asynchronous: No clock signal – relies on pre-agreed baud rate (e.g., 9600, 115200 bps). Uses two main lines: TX (Transmit) and RX (Receive). Configurable baud rate (e.g., 9600, 115200 bps). Error detection: Parity bit (optional). Flow control: Hardware (RTS/CTS) or software (XON/XOFF). No addressing – only two devices per bus. Data Frame Structure Start bit (1 bit, logic low). Data bits (5–9 bits, LSB-first). Parity bit (optional, even/odd/none). Stop bit(s) (1 or 2 bits, logic high). Start Bit | Data Bits (5-9) | Parity Bit (Optional) | Stop Bit (1-2) Points to Remember If the baud rate is set as 115200, then the recever will expect stop bit that is high state for 1 baud period(generally). Usage in Linux Kernel: #include <linux/serial_core.h> struct uart_port *port; uart_write(port, "Hello", 5); Use Cases Debugging consoles (e.g., Linux kernel printk via UART). GPS modules, Bluetooth/Wi-Fi modules.

Monolithic Kernel All core OS services (memory management, process scheduling, file systems, drivers) reside in kernel space. Example: Linux Kernel. Pros: Fast performance, direct access to hardware. Cons: Large codebase, difficult debugging, crashes can affect the whole system. Microkernel Minimal core kernel, with most services running in user space. Example: QNX, Minix. Pros: Stability, modularity, better security. Cons: Performance overhead due to inter-process communication (IPC).

1. Overview RTOS (Real-Time Operating System): Designed for deterministic, time-critical applications with low-latency response. Why RTOS over Linux? Deterministic Execution: RTOS ensures tasks meet strict timing deadlines, unlike Linux, which has non-deterministic scheduling. Low Overhead: RTOS has minimal context switching overhead and no user/kernel space separation. Resource-Constrained Devices: Ideal for microcontrollers (MCUs) with limited memory and processing power. Fast Boot Times: RTOS boots in milliseconds, while Linux requires a much longer initialization process. Interrupt Handling: More responsive to real-time interrupts, whereas Linux introduces latency due to its complex scheduler. FreeRTOS: A lightweight, open-source RTOS widely used in embedded systems. Linux Kernel: A general-purpose OS with multi-user capabilities, used in complex embedded and desktop/server systems. 2. FreeRTOS vs. Linux Kernel (Key Differences) Kernel vs. User Space FreeRTOS: It doesn’t have the concept of a user space and kernel space like Linux. The whole system is essentially one space, and tasks directly interact with the kernel (RTOS). You can think of FreeRTOS as a single program running with different tasks that can interact with each other or with hardware directly. Linux Kernel: Linux operates with a strict separation between user space and kernel space. User applications cannot directly interact with hardware; they must go through system calls, which are handled by the kernel. Scheduler FreeRTOS: Preemptive, cooperative, or tickless scheduling. Supports priority-based scheduling (fixed priority, round-robin, etc.). Simple task model, each task runs in its own stack but shares memory. Linux Kernel Also has a preemptive scheduler, but it is much more complex, as it must handle multiple users, system calls, different types of scheduling (e.g., real-time, normal tasks), and various priorities. Linux is optimized for fairness CFS (Completely Fair Scheduler) and general-purpose multitasking. The FreeRTOS scheduler, by contrast, is simpler and more deterministic. Processes FreeRTOS: Does not have a “process” model like Linux. Instead, it has tasks. Tasks in FreeRTOS can be thought of as lightweight threads. FreeRTOS doesn’t manage the memory space for each task in the same way Linux does for processes. All tasks share the same address space and run in the same context. Linux Kernel: Linux uses processes, each of which has its own memory space. Processes in Linux can be multi-threaded, and each thread can have different scheduling characteristics. Linux processes are isolated from each other, so one process crashing doesn’t affect others. Memory Management FreeRTOS: Memory management is more manual. FreeRTOS does not have sophisticated memory management like Linux. It provides basic functions for allocating fixed-size blocks or dynamic memory pools (pvPortMalloc, vPortFree). It doesn’t have virtual memory, so all tasks have access to the same memory space, making it much simpler but also more prone to memory corruption if not managed properly. Linux Kernel: Linux includes virtual memory, meaning each process has its own virtual address space. It supports advanced features like paging and memory protection. The Linux kernel has a memory management unit (MMU) and sophisticated memory allocators for heap, stack, and memory mapping. Drivers FreeRTOS: Drivers in FreeRTOS are usually written to interface directly with the hardware. Embedded developers write hardware-specific drivers for devices such as GPIO, UART, SPI, I2C, etc. The drivers are tightly coupled with the hardware and typically run in the same task context as the rest of the application. Interfacing with hardware is done via direct memory-mapped registers and interrupt service routines (ISRs). Linux Kernel: The Linux kernel has a comprehensive set of device drivers for a wide variety of hardware. Drivers in Linux are implemented as kernel modules, which can be dynamically loaded and unloaded. These drivers abstract hardware interactions and often provide a system call interface for user-space applications to interact with hardware. GPIO Management FreeRTOS: Direct register manipulation or vendor-specific HAL libraries. No standard GPIO subsystem like Linux. GPIO interrupts are handled using ISR (Interrupt Service Routines) with FreeRTOS primitives like queues for event notification. Linux Kernel: GPIO Subsystem: Provides an abstraction layer using sysfs, character devices, or device tree bindings. Uses kernel interrupt handling with debounce and polling mechanisms. Interrupt Handling FreeRTOS: Interrupt handling is done through Interrupt Service Routines (ISRs), which are small, time-critical functions that handle hardware interrupts. FreeRTOS provides mechanisms to synchronize tasks with ISRs via semaphores or queues. Linux Kernel: Linux also uses ISRs, but in addition to regular interrupts, it has a more complex mechanism for handling asynchronous events, such as software interrupts, tasklets, work queues, etc. The kernel abstracts much of the interrupt management for portability. Synchronization Mechanisms FreeRTOS: Offers simple synchronization primitives like semaphores, mutexes, queues, and event groups. These are lightweight and highly optimized for small systems with limited resources. Linux Kernel: Linux also provides synchronization mechanisms like semaphores, mutexes, and spinlocks. However, these mechanisms are more complex and support features like priority inversion prevention, as well as various types of locking for different kernel contexts. Filesystem and I/O FreeRTOS: By default, FreeRTOS does not provide any filesystem management or complex I/O subsystem. I/O is typically done through simple APIs provided by the BSP or device driver code. Linux Kernel: Linux supports a full-fledged filesystem with many types (e.g., ext4, NTFS) and includes complex device I/O management, including file descriptors, blocking/non-blocking I/O, and extensive support for network file systems (NFS, CIFS). Conclusion: Feature FreeRTOS Linux Kernel Kernel/User Space Single space Separated Scheduler Priority-based, Preemptive CFS, RT scheduling Driver Model Direct access, HAL-based Kernel module-based GPIO Management Direct register access Standard GPIO subsystem Process Model Tasks only Processes & Threads Memory Management Heap-based, no MMU Virtual memory, MMU support Use Cases Real-time, MCUs High-performance, SBCs, SoCs FreeRTOS and Linux serve different purposes in embedded systems: ...

!assets/Pasted image 20250203182747.png Reference GirFlow Explained: https://youtu.be/Aa8RpP0sf-Y

SHA-256 is a cryptographic hash function that produces a fixed-size 256-bit (32-byte) hash. It is deterministic, collision-resistant, and designed for security-critical applications. !assets/hashing-algorithm-sha256.png How SHA-256 Works Preprocessing: Pad the input to a multiple of 512 bits. Append a 1, then add k zeros, and finally append the original message length (64 bits). Initialize Hash Values: Use constants derived from the fractional parts of square roots of the first 8 primes (eight 32-bit words). Example: h0 = 0x6a09e667, h1 = 0xbb67ae85, .... Process Blocks: Split the padded message into 512-bit blocks. For each block: Expand the block into 64 words using a message schedule. Perform 64 rounds of compression using bitwise operations (e.g., XOR, AND, modular addition). Compression Function A compression function is applied to each block, creating a new hash value. This function involves mixing the bits of the current hash value and the message block. Iteration Repeat the compression function for each block, using the output of each iteration as input for the next. Final Hash: Combine the intermediate hash values to produce the final 256-bit digest. Example: SHA-256 for String “Hello” Input: “Hello” → ASCII 48656C6C6F. Padding: Length = 40 bits (5 bytes). Pad with 1, 407 zeros, and 0000000000000028 (hex for 40 bits). Hash Computation: After processing, the final hash is: 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969. Use Cases SHA-256 Cryptographic security in: Digital signatures (SSL/TLS certificates). Password storage (hashed+salted). Blockchain (Bitcoin transactions). File integrity verification (e.g., software downloads). Guarantees: Pre-image resistance, collision resistance.

CRC is an error-detection code used to detect accidental changes to raw data (e.g., during transmission or storage). It works by treating the data as a polynomial and performing polynomial division with a predefined generator polynomial. The remainder of this division becomes the CRC value. How CRC is Calculated Convert data to binary: Treat the data as a sequence of bits. Append zeros: Add n zeros to the end of the data, where n is the degree of the generator polynomial (e.g., CRC-32 uses a 33-bit polynomial, so append 32 zeros). Polynomial division: Divide the data + zeros by the generator polynomial using modulo-2 arithmetic (XOR operations). CRC value: The remainder of this division is the CRC checksum. Example: CRC-8 for String “Hi” Data: “Hi” in ASCII is 01001000 01101001. Generator Polynomial: CRC-8 (e.g., x⁸ + x² + x + 1), represented as 100000111. Append 8 zeros: Data becomes 010010000110100100000000. Perform division: Divide 010010000110100100000000 by 100000111 using XOR. Remainder: Let’s assume the remainder is 00110110 (hex 0x36). Final CRC: 0x36. Use Cases Error detection in: Network protocols (Ethernet, Wi-Fi). Storage systems (hard drives, ZIP files). Quick checksums for small data transfers. Not secure against intentional tampering.