[{"content":"🛠 Technology Stack Target Hardware: Raspberry Pi 4 Model B Sensing Hardware: ADXL345 (3-Axis Digital Accelerometer) Languages: C++ (Qt 6), Embedded C (Paho MQTT), Bash Protocols: MQTT over SSL/TLS (Port 8883), I2C, JSON Cloud Infrastructure: HiveMQ Cloud Broker Networking: Tailscale Mesh VPN, Pi-hole (DNS Security) The Project Overview Engineered a secure, end-to-end telemetry pipeline designed to monitor and synchronize high-G impact data from edge devices to a centralized monitoring station. This project bridges the gap between register-level sensor interfacing on Linux and high-level data visualization using the Qt framework. The system is hardened with industry-standard encryption to ensure data integrity across public networks.\nSystem Logic \u0026amp; Implementation The architecture is divided into a high-performance Edge Firmware and a reactive Telemetry Dashboard:\n1. Edge Firmware (Impact Detection) The Raspberry Pi interacts with the ADXL345 via a custom I2C driver. To optimize performance, the system utilizes a \u0026ldquo;High-G\u0026rdquo; threshold interrupt.\nData Processing: Raw 16-bit acceleration data is converted using Two’s Complement sign-extension and scaled to G-force units. Cloud Synchronization: When an impact exceeds the 1.5G threshold, the firmware packages the event into a JSON payload and publishes it to a secure HiveMQ cluster. 2. Qt 6 Dashboard (Asynchronous Visualization) The monitoring suite is built in C++ (Qt 6) and operates on a non-blocking event loop:\nSecure Handshake: Implements a manual SSL/TLS handshake (TLS v1.2) utilizing Server Name Indication (SNI) and ALPN protocols to bypass strict cloud firewalls. Live Telemetry: Features a dynamic scrolling chart that renders X, Y, and Z axes simultaneously. JSON Pipeline: An asynchronous parser decrypts and flattens incoming MQTT messages into UI-ready data structures without locking the main thread. Network \u0026amp; Security Hardening A significant portion of development was dedicated to ensuring the telemetry pipeline could operate within a secured home/enterprise network:\nDNS Whitelisting: Configured Pi-hole regex rules to allow encrypted telemetry traffic while blocking standard ad-trackers. Proxy Bypass: Since the system often operates behind a Tailscale VPN, the Qt application was programmed to bypass virtual network proxies using QNetworkProxy::NoProxy to ensure direct, low-latency socket communication. Port 8883 Enforcement: All traffic is strictly routed through Port 8883 (MQTTS), preventing packet sniffing and man-in-the-middle attacks. Live Execution Logs 1. Edge Firmware Output (Raspberry Pi): renode — firmware_audit.log vamsi-kiran@ASUS:~$ ./firmware_app\nConnecting to ssl://40db01641ba149dc91182576560ea139.s1.eu.hivemq.cloud:8883... Connected to the broker. RTC Time has been synced! Logger active: Waiting for Vibration... [LOGGED] IMPACT DETECTED! X:0.25g Y:0.74g Z:1.09g --- Attempting Cloud Sync... --- [LOGGED] IMPACT DETECTED! X:0.12g Y:-0.14g Z:1.93g --- Attempting Cloud Sync... --- [LOGGED] IMPACT DETECTED! X:-0.05g Y:-0.82g Z:0.58g 2. Dashboard Output (Linux Monitoring Station): renode — firmware_audit.log vamsi-kiran@ASUS:~$ ./AssetTrackerDashboard\n\u003e\u003e\u003e Opening TCP Socket to Port 8883... \u003e\u003e\u003e TCP Connected. Starting SSL Handshake... \u003e\u003e\u003e SUCCESS: Tunnel Encrypted! Sending MQTT Login... MQTT Login Successful! Subscribed to topic: asset_tracker/# Incoming Data: {\"x\":0.25, \"y\":0.74, \"z\":1.09} -\u003e Rendering Frame. Key Learnings SSL/TLS Protocol Nuances: Gained deep experience in debugging handshake failures, specifically managing SNI (Server Name Indication) and ALPN tags required by AWS-backed load balancers. Embedded Data Integrity: Learned to handle I2C register-level timing and sign-extension for MEMS sensors, ensuring that physical motion translates accurately to digital telemetry. Network Interoperability: Solved complex routing issues involving Pi-hole DNS sinkholes and Tailscale VPN interference, a critical skill for deploying IoT devices in real-world environments. Qt UI Performance: Mastered the use of QtCharts and signal-slot mechanisms to handle high-frequency data bursts without causing UI latency. View Source on GitHub\n","permalink":"https://vamsikiran277.github.io/projects/smart-asset-tracker/","summary":"\u003ch3 id=\"-technology-stack\"\u003e🛠 Technology Stack\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eTarget Hardware:\u003c/strong\u003e Raspberry Pi 4 Model B\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSensing Hardware:\u003c/strong\u003e ADXL345 (3-Axis Digital Accelerometer)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLanguages:\u003c/strong\u003e C++ (Qt 6), Embedded C (Paho MQTT), Bash\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProtocols:\u003c/strong\u003e MQTT over SSL/TLS (Port 8883), I2C, JSON\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCloud Infrastructure:\u003c/strong\u003e HiveMQ Cloud Broker\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNetworking:\u003c/strong\u003e Tailscale Mesh VPN, Pi-hole (DNS Security)\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"the-project-overview\"\u003eThe Project Overview\u003c/h3\u003e\n\u003cp\u003eEngineered a secure, end-to-end telemetry pipeline designed to monitor and synchronize high-G impact data from edge devices to a centralized monitoring station. This project bridges the gap between register-level sensor interfacing on Linux and high-level data visualization using the Qt framework. The system is hardened with industry-standard encryption to ensure data integrity across public networks.\u003c/p\u003e","title":"Smart Asset Tracker \u0026 Telemetry Dashboard"},{"content":"🛠 Technology Stack Languages: Embedded C (C11) Operating System: FreeRTOS (POSIX Port) Protocols: I2C, Hardware Interrupts (GPIO) Tools: libgpiod, GDB, GCC, Linux terminal The Project Overview The objective was to design a robust, thread-safe sensor acquisition system on a Linux-based RTOS environment. This project demonstrates high-reliability multitasking where multiple sensors share a single communication bus without data corruption or timing jitter.\nTechnical Highlights Kernel-Level Multitasking: Leveraged the FreeRTOS POSIX Port to manage three concurrent tasks using fixed-priority preemption, ensuring mission-critical tasks always receive CPU time. Thread-Safe I2C Management: Implemented a Mutex Semaphore to arbitrate access to the I2C bus. This prevents data collisions between the ADXL345 Accelerometer and DS3231 RTC tasks when accessing shared hardware. Asynchronous Event Handling: Developed a high-priority hardware listener using libgpiod to capture falling-edge interrupts on GPIO 17, triggering a system-wide graceful shutdown. Deterministic Scheduling: Replaced standard sleep calls with vTaskDelayUntil() to ensure a consistent 10Hz sampling frequency, eliminating timing drift critical for real-time telemetry analysis. Resource Cleanup: Engineered a custom shutdown() sequence ensuring all RTOS tasks are deleted and Linux file descriptors (I2C/GPIO) are properly closed before process termination. Live RTOS Execution \u0026amp; Task Arbitration The following terminal trace captures the live execution of the FreeRTOS tasks. It demonstrates the real-time arbitration of the I2C bus between the high-frequency accelerometer and the low-frequency real-time clock.\nrenode — firmware_audit.log vamsi-kiran@ASUS:~$ ./telemetry_app\nADXL initialized succesfully X:0 | Y:0 | Z:0 H:02 | M:20 | S:29 X:-4 | Y:144 | Z:192 X:-6 | Y:144 | Z:191 X:-4 | Y:144 | Z:194 X:-5 | Y:144 | Z:193 X:-7 | Y:145 | Z:192 X:-4 | Y:143 | Z:194 X:-4 | Y:145 | Z:190 X:-5 | Y:145 | Z:190 X:-6 | Y:143 | Z:197 X:-5 | Y:145 | Z:193 H:02 | M:20 | S:30 X:-5 | Y:143 | Z:189 X:-4 | Y:142 | Z:193 ... [Simulation continues] ... ^C Telemetry Data Audit Deterministic 10Hz Scheduling: Between the RTC outputs of S:29 and S:30, there are exactly ten X/Y/Z coordinate lines. This proves the vTaskDelayUntil() logic successfully avoids drift and maintains a strict 100ms task frequency. Thread-Safe IPC (Mutex): Notice that the output lines never mangle or overlap (e.g., you never see X:-4 | H:02 Y:144...). This confirms the FreeRTOS Mutex is successfully locking the printf and I2C file descriptors during context switches. Graceful Termination: The ^C (SIGINT) is caught by the system, allowing the process to release the I2C bus and terminate gracefully without hanging the hardware state. Key Learning Outcomes Concurrency Control: Mastered the use of Mutexes and Semaphores to handle shared resource contention in a real-time environment. RTOS Scheduling: Understood the difference between \u0026ldquo;soft\u0026rdquo; delays and deterministic \u0026ldquo;fixed-frequency\u0026rdquo; scheduling for sensor data integrity. System Robustness: Learned to implement graceful degradation and cleanup procedures to prevent memory leaks and \u0026ldquo;hung\u0026rdquo; hardware peripherals. Hardware Target This project is designed for Linux-based Embedded Systems (specifically tested on Raspberry Pi). It interfaces with an ADXL345 for motion data and a DS3231 Real-Time Clock for timestamping via the I2C protocol.\nView Source on GitHub\n","permalink":"https://vamsikiran277.github.io/projects/freertos-tasks/","summary":"\u003ch3 id=\"-technology-stack\"\u003e🛠 Technology Stack\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLanguages:\u003c/strong\u003e Embedded C (C11)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOperating System:\u003c/strong\u003e FreeRTOS (POSIX Port)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProtocols:\u003c/strong\u003e I2C, Hardware Interrupts (GPIO)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTools:\u003c/strong\u003e libgpiod, GDB, GCC, Linux terminal\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"the-project-overview\"\u003eThe Project Overview\u003c/h3\u003e\n\u003cp\u003eThe objective was to design a robust, thread-safe sensor acquisition system on a Linux-based RTOS environment. This project demonstrates high-reliability multitasking where multiple sensors share a single communication bus without data corruption or timing jitter.\u003c/p\u003e\n\u003ch3 id=\"technical-highlights\"\u003eTechnical Highlights\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eKernel-Level Multitasking:\u003c/strong\u003e Leveraged the \u003cstrong\u003eFreeRTOS POSIX Port\u003c/strong\u003e to manage three concurrent tasks using fixed-priority preemption, ensuring mission-critical tasks always receive CPU time.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThread-Safe I2C Management:\u003c/strong\u003e Implemented a \u003cstrong\u003eMutex Semaphore\u003c/strong\u003e to arbitrate access to the I2C bus. This prevents data collisions between the \u003cstrong\u003eADXL345 Accelerometer\u003c/strong\u003e and \u003cstrong\u003eDS3231 RTC\u003c/strong\u003e tasks when accessing shared hardware.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAsynchronous Event Handling:\u003c/strong\u003e Developed a high-priority hardware listener using \u003cstrong\u003elibgpiod\u003c/strong\u003e to capture falling-edge interrupts on GPIO 17, triggering a system-wide graceful shutdown.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDeterministic Scheduling:\u003c/strong\u003e Replaced standard sleep calls with \u003ccode\u003evTaskDelayUntil()\u003c/code\u003e to ensure a consistent \u003cstrong\u003e10Hz sampling frequency\u003c/strong\u003e, eliminating timing drift critical for real-time telemetry analysis.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eResource Cleanup:\u003c/strong\u003e Engineered a custom \u003ccode\u003eshutdown()\u003c/code\u003e sequence ensuring all RTOS tasks are deleted and Linux file descriptors (I2C/GPIO) are properly closed before process termination.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"live-rtos-execution--task-arbitration\"\u003eLive RTOS Execution \u0026amp; Task Arbitration\u003c/h3\u003e\n\u003cp\u003eThe following terminal trace captures the live execution of the FreeRTOS tasks. It demonstrates the real-time arbitration of the I2C bus between the high-frequency accelerometer and the low-frequency real-time clock.\u003c/p\u003e","title":"FreeRTOS Task Management \u0026 Sensor Suite"},{"content":"🛠 Technology Stack Languages: Bare-Metal C (C11) Hardware: STM32F407 (Discovery Board) - ARM Cortex-M4 Simulation: Renode (Antmicro) Protocols: UART (USART2), SysTick Timer logic Tools: arm-none-eabi-gcc, GDB, Renode The Project Overview A modular firmware application demonstrating a clean separation between hardware-specific drivers (BSP) and high-level application logic. The project focuses on non-blocking execution, architectural maintainability, and full system virtualization using the Renode framework.\nTechnical Highlights Layered Architecture (BSP): All register-level operations (RCC, GPIO, UART) are encapsulated within a dedicated Board Support Package. The application layer interacts only with abstract APIs, containing zero raw register addresses. Non-Blocking Logic: Replaced \u0026ldquo;busy-wait\u0026rdquo; loops with a SysTick-based interrupt system, allowing the CPU to process concurrent tasks (LED Heartbeat and Status Reporting) without stalling the execution thread. UART Serial Driver: Developed a custom driver for USART2, featuring manual Baud Rate calculation for the 16 MHz HSI clock to ensure stable 115200 baud communication. Virtual Hardware Validation: Successfully virtualized the STM32F407 hardware environment in Renode, enabling cycle-accurate firmware testing and UART output auditing without physical silicon. Simulation \u0026amp; Hardware Verification The project is validated using Renode to audit register-level interactions and verify the timing logic of the Board Support Package. By mapping the internal USART2 peripheral to a virtual analyzer, the firmware execution is audited for cycle-accurate behavior before deployment to physical silicon.\nrenode — firmware_audit.log vamsi-kiran@ASUS:~$ renode stm32f4.resc\n16:40:35.7373 [INFO] STM32F4_Discovery/sysbus: Loaded SVD: STM32F40x. 16:40:36.1429 [INFO] STM32F4_Discovery/sysbus: Loading block of 5784 bytes length at 0x8000000. 16:40:36.1430 [INFO] STM32F4_Discovery/sysbus: Loading block of 2352 bytes length at 0x20000548. 16:40:36.1622 [INFO] stm32f4: Machine started. 16:40:36.1629 [INFO] STM32F4_Discovery/cpu: Guessing VectorTableOffset value to be 0x8000000. 16:40:36.1711 [INFO] STM32F4_Discovery/cpu: Setting initial values: PC = 0x80015A5, SP = 0x20020000. 16:40:36.1728 [INFO] STM32F4_Discovery: Machine started. [USART2 Analyzer] A -\u003e Char Sent! A -\u003e Char Sent! A -\u003e Char Sent! A -\u003e Char Sent! A -\u003e Char Sent! ... [Simulation continues at 2.0s intervals] ... Execution Audit Logic Vector Table Alignment: Renode successfully identified the VectorTableOffset at 0x8000000, confirming the linker script correctly placed the code in Flash memory. Stack Pointer (SP) Initialization: The initial SP was set to 0x20020000, validating that the startup assembly properly allocated the stack in the upper region of SRAM. Deterministic Peripherals: The A -\u0026gt; Char Sent! output confirms that the manual baud rate calculation for the 16 MHz HSI clock correctly configured the USART2-\u0026gt;BRR register and that the TXE (Transmit Data Register Empty) polling logic is fully functional. Key Learning Outcomes Register Mapping \u0026amp; MMIO: Mastered the translation of ARM Cortex-M4 technical datasheets into functional C code using structures and volatile bit-field mapping. Software Design Patterns: Implemented \u0026ldquo;Separation of Concerns\u0026rdquo; to ensure high-level application code remains portable across different MCU architectures. Cross-Compilation \u0026amp; Toolchain: Transitioned to a Linux-based build pipeline using arm-none-eabi-gcc and custom linker scripts (.ld) for manual memory mapping. Hardware Target This project was designed for the STM32F407 Discovery Board. In the virtualized environment, it utilizes PD12 for the LED heartbeat and USART2 (PA2/PA3) for system status reporting at 115200 baud.\nView Source on GitHub\n","permalink":"https://vamsikiran277.github.io/projects/bsp-application/","summary":"\u003ch3 id=\"-technology-stack\"\u003e🛠 Technology Stack\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLanguages:\u003c/strong\u003e Bare-Metal C (C11)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHardware:\u003c/strong\u003e STM32F407 (Discovery Board) - ARM Cortex-M4\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSimulation:\u003c/strong\u003e Renode (Antmicro)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProtocols:\u003c/strong\u003e UART (USART2), SysTick Timer logic\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTools:\u003c/strong\u003e arm-none-eabi-gcc, GDB, Renode\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"the-project-overview\"\u003eThe Project Overview\u003c/h3\u003e\n\u003cp\u003eA modular firmware application demonstrating a clean separation between hardware-specific drivers (BSP) and high-level application logic. The project focuses on non-blocking execution, architectural maintainability, and full system virtualization using the Renode framework.\u003c/p\u003e\n\u003ch3 id=\"technical-highlights\"\u003eTechnical Highlights\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLayered Architecture (BSP):\u003c/strong\u003e All register-level operations (RCC, GPIO, UART) are encapsulated within a dedicated Board Support Package. The application layer interacts only with abstract APIs, containing zero raw register addresses.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNon-Blocking Logic:\u003c/strong\u003e Replaced \u0026ldquo;busy-wait\u0026rdquo; loops with a \u003cstrong\u003eSysTick-based interrupt system\u003c/strong\u003e, allowing the CPU to process concurrent tasks (LED Heartbeat and Status Reporting) without stalling the execution thread.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUART Serial Driver:\u003c/strong\u003e Developed a custom driver for USART2, featuring manual Baud Rate calculation for the \u003cstrong\u003e16 MHz HSI clock\u003c/strong\u003e to ensure stable \u003cstrong\u003e115200 baud\u003c/strong\u003e communication.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVirtual Hardware Validation:\u003c/strong\u003e Successfully virtualized the STM32F407 hardware environment in \u003cstrong\u003eRenode\u003c/strong\u003e, enabling cycle-accurate firmware testing and UART output auditing without physical silicon.\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"simulation--hardware-verification\"\u003eSimulation \u0026amp; Hardware Verification\u003c/h3\u003e\n\u003cp\u003eThe project is validated using \u003cstrong\u003eRenode\u003c/strong\u003e to audit register-level interactions and verify the timing logic of the Board Support Package. By mapping the internal \u003ccode\u003eUSART2\u003c/code\u003e peripheral to a virtual analyzer, the firmware execution is audited for cycle-accurate behavior before deployment to physical silicon.\u003c/p\u003e","title":"BSP-Backed Embedded Application"},{"content":"🛠 Technology Stack Languages: C++ (OOP Approach), Makefile Protocols: I2C, SPI, UART (Mini-UART), GPIO (Alternate Functions) Hardware: Raspberry Pi 4 (BCM2711 / ARM Cortex-A72) Tools: BCM2711 ARM Peripherals Datasheet, GCC Toolchain, GDB The Project Overview Developed a comprehensive, register-level peripheral driver suite for the Raspberry Pi 4 using an Object-Oriented approach in C++. This project demonstrates how to translate complex technical datasheets into a modular, reusable Hardware Abstraction Layer (HAL).\nTechnical Highlights Register-Level Control: Directly manipulated SoC registers using memory-mapped I/O (MMIO) to configure GPIO pins, Alternate Functions, and peripheral clock rates. OOP Driver Design: Implemented drivers as C++ classes, encapsulating peripheral state and methods. This ensures type safety and allows for easy instantiation of multiple communication buses. Protocol Implementation: I2C: Developed a robust master-mode driver with support for 7-bit addressing and data stream management. SPI: Engineered a high-speed Serial Peripheral Interface driver, managing Clock Polarity (CPOL) and Phase (CPHA). UART: Configured the Mini-UART peripheral for asynchronous serial communication, including precise baud rate generation math. Custom Build Pipeline: Created a modular Makefile system to manage dependencies, object files, and cross-compilation for the ARM architecture. Key Learning Outcomes Datasheet Interpretation: Mastered the BCM2711 Reference Manual, learning to map physical addresses to virtual memory and understanding peripheral-specific control registers. Communication Protocols: SPI: Learned the timing diagrams and shift-register logic required for high-speed full-duplex communication. UART: Understood start/stop bit framing, parity, and the impact of system clock frequencies on baud accuracy. I2C: Gained experience with the \u0026ldquo;Start-Address-Data-Stop\u0026rdquo; sequence and handling Acknowledgement (ACK/NACK) bits. C++ for Embedded: Leveraged C++ features like classes and private member variables to enforce data hiding and prevent illegal register access from the application layer. Hardware Target Designed specifically for the Raspberry Pi 4 Model B. The drivers interface directly with the Broadcom BCM2711 SoC, providing a bare-metal feel while running within a Linux user-space environment via /dev/mem access.\nView Source on GitHub\n","permalink":"https://vamsikiran277.github.io/projects/peripheral-drivers/","summary":"\u003ch3 id=\"-technology-stack\"\u003e🛠 Technology Stack\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLanguages:\u003c/strong\u003e C++ (OOP Approach), Makefile\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProtocols:\u003c/strong\u003e I2C, SPI, UART (Mini-UART), GPIO (Alternate Functions)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHardware:\u003c/strong\u003e Raspberry Pi 4 (BCM2711 / ARM Cortex-A72)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTools:\u003c/strong\u003e BCM2711 ARM Peripherals Datasheet, GCC Toolchain, GDB\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"the-project-overview\"\u003eThe Project Overview\u003c/h3\u003e\n\u003cp\u003eDeveloped a comprehensive, register-level peripheral driver suite for the Raspberry Pi 4 using an Object-Oriented approach in C++. This project demonstrates how to translate complex technical datasheets into a modular, reusable Hardware Abstraction Layer (HAL).\u003c/p\u003e","title":"Peripheral Driver Suite: GPIO, I2C, SPI \u0026 UART"},{"content":"🛠 Technology Stack Target Hardware: ZX-8080 (32-bit RISC-V Architecture) Clock Speed: 80 MHz System Frequency Language: Bare-Metal C Toolchain: RISC-V GCC (riscv64-unknown-elf-gcc) Simulation: Renode (Antmicro) Key Peripherals: 12-bit SAR ADC, General Purpose Timer (TIM1), GPIO The Project Overview This repository contains a bare-metal C implementation for the ZX-8080, a custom 32-bit RISC-V based microcontroller. The project demonstrates low-level hardware abstraction by interfacing with an onboard 12-bit SAR ADC for thermal monitoring and utilizing a General Purpose Timer for precise LED toggling. Furthermore, the entire hardware environment is successfully virtualized and tested using the Renode simulation framework.\nSystem Logic \u0026amp; Implementation The application performs two concurrent tasks within a robust super-loop:\n1. Precision Timing (LED Toggle) To achieve a human-readable 0.5s blink rate from an 80 MHz system clock, I implemented a two-stage clock division using Timer 1:\nPrescaler (PSC): Set to 7999. This reduces the timer clock to 10 kHz. f_clk = 80,000,000 / (7999 + 1) = 10,000 Hz\nAuto-Reload Register (ARR): Set to 4999. The timer counts 5000 ticks before setting the Update Interrupt Flag (UIF). Delay = (PSC + 1) * (ARR + 1) / f_sys = (8000 * 5000) / 80,000,000 = 0.5s\n2. Thermal Monitoring (ADC Polling) The code interacts with a 12-bit SAR ADC (Scale: 0–4095) for real-time environmental monitoring.\nTrigger: Hardware conversion is initiated directly via software register writes. Synchronization: The CPU polls the START_CONV bit, waiting for hardware to clear it upon completion to ensure data integrity. Hysteresis Logic: * current_temp \u0026gt; 3000: Activate Alarm (GPIO Pin 0 HIGH). current_temp \u0026lt; 1500: Deactivate Alarm (GPIO Pin 0 LOW). Bare-Metal Compilation \u0026amp; Linker Script Because this project runs without an Operating System, the standard C library is excluded using the -nostdlib flag. To tell the compiler exactly how to map the code to the ZX-8080\u0026rsquo;s physical memory, a custom linker script (link.ld) was authored:\nFlash Memory (0x0): Mapped for the executable code (.text sections) and read-only data (.rodata). SRAM (0x20000000): Mapped for initialized variables (.data) and uninitialized variables (.bss). The resulting output is a raw .elf binary that can be loaded directly onto the silicon.\nVirtual Hardware Simulation (Renode) To test the firmware without physical silicon, the ZX-8080 environment was built from scratch using Renode.\nPlatform Definition (zx8080.repl): Defines the memory map, attaching the CPU, Flash, SRAM, and Memory-Mapped I/O (MMIO) to the system bus at their exact datasheet addresses. Hardware Injection (gpio.py \u0026amp; timer.py): Custom Python peripherals act as the virtual silicon. They intercept the CPU\u0026rsquo;s memory reads/writes to inject mock ADC thermal values and assert Timer Interrupt flags in real-time. Execution Script (zx8080.resc): Initializes the machine, loads the .elf file, sets the Stack Pointer (SP) and Program Counter (PC), and logs GPIO outputs. How to Run the Simulation 1. Compile the Firmware: renode — firmware_audit.log vamsi-kiran@ASUS:~$ riscv64-unknown-elf-gcc -march=rv32i -mabi=ilp32 -nostdlib -T link.ld main.c -o zx8080_project.elf\n2. Launch and Execute in Renode: renode — firmware_audit.log vamsi-kiran@ASUS:~$ renode -e \u0026#39;s @zx8080.resc\u0026#39;\n11:23:13.8888 [INFO] Loaded monitor commands from: scripts/monitor.py 11:23:14.4057 [INFO] Including script(s): zx8080.resc 11:23:14.4293 [INFO] System bus created. 11:23:15.4009 [INFO] sysbus: Loading block of 424 bytes length at 0x0. 11:23:15.4354 [INFO] cpu: Setting PC value to 0x0. 11:23:15.9785 [INFO] ZX-8080: Machine started. Hardware: GPIO Write -\u003e 0x1L \u003c-- Thermal Alarm (Pin 0 HIGH) Hardware: GPIO Write -\u003e 0x20L \u003c-- LED Toggled Hardware: GPIO Write -\u003e 0x1L Hardware: GPIO Write -\u003e 0x20L ... [Simulation continues] ... Key Learnings The volatile Keyword is Critical: A major debugging breakthrough involved compiler optimization. Without the volatile keyword on the hardware structs, the RISC-V GCC compiler optimized away the hardware polling loops. Adding volatile forced the CPU to fetch fresh data from the memory bus on every cycle, allowing successful hardware synchronization. Hardware Abstraction via Structs: Instead of using error-prone pointer arithmetic, I utilized Memory-Mapped Structures. This approach maps a C struct directly to the peripheral\u0026rsquo;s register offsets, ensuring type-safe access. Register-Level Synchronization: Practiced robust peripheral handshaking by implementing polling methods—checking hardware status flags (like UIF in TIM_STAT) and manually clearing them to acknowledge events. Clock Tree Management: Mastered the relationship between system oscillators and peripheral clock domains to derive accurate timing intervals. View Source on GitHub\n","permalink":"https://vamsikiran277.github.io/projects/zx-8080-mcu/","summary":"\u003ch3 id=\"-technology-stack\"\u003e🛠 Technology Stack\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eTarget Hardware:\u003c/strong\u003e ZX-8080 (32-bit RISC-V Architecture)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClock Speed:\u003c/strong\u003e 80 MHz System Frequency\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLanguage:\u003c/strong\u003e Bare-Metal C\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eToolchain:\u003c/strong\u003e RISC-V GCC (\u003ccode\u003eriscv64-unknown-elf-gcc\u003c/code\u003e)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSimulation:\u003c/strong\u003e Renode (Antmicro)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKey Peripherals:\u003c/strong\u003e 12-bit SAR ADC, General Purpose Timer (TIM1), GPIO\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"the-project-overview\"\u003eThe Project Overview\u003c/h3\u003e\n\u003cp\u003eThis repository contains a bare-metal C implementation for the \u003cstrong\u003eZX-8080\u003c/strong\u003e, a custom 32-bit RISC-V based microcontroller. The project demonstrates low-level hardware abstraction by interfacing with an onboard 12-bit SAR ADC for thermal monitoring and utilizing a General Purpose Timer for precise LED toggling. Furthermore, the entire hardware environment is successfully virtualized and tested using the \u003cstrong\u003eRenode\u003c/strong\u003e simulation framework.\u003c/p\u003e","title":"ZX-8080 MCU: Bare-Metal Peripheral Control"},{"content":"🛠 Technology Stack Language: C (C11/C17) Hardware: STM32F407 (ARM Cortex-M4) Tools: Renode (SIL Simulation), STM32CubeIDE Key Concepts: C Bit-Fields, MMIO, Software-in-the-Loop (SIL) The Project Overview A low-level firmware implementation for the STM32F407 that demonstrates peripheral control via direct register manipulation. This project bypasses standard HAL/LL libraries to interface directly with the AHB1 bus matrix using custom C bit-field structures for type-safe hardware access.\nTechnical Highlights C Bit-Field Structures: Utilized custom struct definitions to map hardware registers, ensuring type-safe access to individual bits and eliminating manual bitwise masks (\u0026amp;, |, \u0026lt;\u0026lt;). Memory-Mapped I/O (MMIO): Manually mapped the RCC (Base: 0x40023800) and GPIOD (Base: 0x40020C00) to control hardware clocking and pin states. SIL Validation (Renode): Automated hardware verification using Renode to validate register-level behavior via memory-access tracing. This allows for cycle-accurate auditing of the firmware\u0026rsquo;s execution without physical hardware. 🔍 Simulation \u0026amp; Hardware Verification The project is validated using Renode to trace memory-mapped I/O (MMIO) interactions. This ensures the firmware logic correctly targets the ARM Cortex-M4 register map before deployment to physical silicon.\nrenode — firmware_audit.log vamsi-kiran@ASUS:~$ renode --plain --hide-monitor -e \u0026#39;include @Simulation/stm32_blink.resc\u0026#39;\n19:43:38.5796 [INFO] System bus created. 19:43:39.3288 [INFO] sysbus: Loaded SVD: STM32F40x. 19:43:39.4383 [INFO] gpioPortD: [cpu: 0x80001EE] WriteUInt32 to 0x0 (Mode), value 0x1000000 19:43:39.4390 [INFO] gpioPortD: [cpu: 0x80001F8] WriteUInt32 to 0x14 (OutputData), value 0x1000 \u003c-- LED ON 19:43:39.4457 [INFO] gpioPortD: [cpu: 0x8000216] WriteUInt32 to 0x14 (OutputData), value 0x0 \u003c-- LED OFF ... [Simulation continues] ... 📑 Full Verification Log Audit (verification.log) The following excerpt from the automated log audit validates the peripheral clock gating and the recursive toggling logic:\n19:43:39.3542 [INFO] sysbus: Loading block of 764 bytes length at 0x8000000. 19:43:39.4383 [INFO] gpioPortD: [cpu: 0x80001E6] ReadUInt32 from 0x0 (Mode), returned 0x0 19:43:39.4383 [INFO] gpioPortD: [cpu: 0x80001EE] WriteUInt32 to 0x0 (Mode), value 0x1000000 19:43:39.4390 [INFO] gpioPortD: [cpu: 0x80001F2] ReadUInt32 from 0x14 (OutputData), returned 0x0 19:43:39.4390 [INFO] gpioPortD: [cpu: 0x80001F8] WriteUInt32 to 0x14 (OutputData), value 0x1000 19:43:39.4457 [INFO] gpioPortD: [cpu: 0x8000216] WriteUInt32 to 0x14 (OutputData), value 0x0 19:43:39.4522 [INFO] gpioPortD: [cpu: 0x80001F8] WriteUInt32 to 0x14 (OutputData), value 0x1000 19:43:39.4733 [INFO] gpioPortD: [cpu: 0x8000216] WriteUInt32 to 0x14 (OutputData), value 0x0 Hardware Audit Mode Config (Offset 0x0): The value 0x1000000 sets Bits 25:24 to 01, successfully configuring Pin 12 as a General Purpose Output. Output Toggle (Offset 0x14): Toggling between 0x1000 (Bit 12 set) and 0x0 verifies cycle-accurate pin control. Watchpoint Tracing: Renode captures the exact Program Counter (e.g., 0x80001EE) for every write, providing a verifiable audit trail. Key Learning Outcomes Code Maintainability: Improved readability for engineering teams by replacing \u0026ldquo;magic number\u0026rdquo; masking with structured mapping. Hardware-Software Verification: Mastered the use of Watchpoint Hooks on memory address 0x40020C14 to capture value writes during execution. View Source on GitHub\n","permalink":"https://vamsikiran277.github.io/projects/bitfield-optimization/","summary":"\u003ch3 id=\"-technology-stack\"\u003e🛠 Technology Stack\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eLanguage:\u003c/strong\u003e C (C11/C17)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHardware:\u003c/strong\u003e STM32F407 (ARM Cortex-M4)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTools:\u003c/strong\u003e Renode (SIL Simulation), STM32CubeIDE\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKey Concepts:\u003c/strong\u003e C Bit-Fields, MMIO, Software-in-the-Loop (SIL)\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"the-project-overview\"\u003eThe Project Overview\u003c/h3\u003e\n\u003cp\u003eA low-level firmware implementation for the STM32F407 that demonstrates peripheral control via direct register manipulation. This project bypasses standard HAL/LL libraries to interface directly with the \u003cstrong\u003eAHB1 bus matrix\u003c/strong\u003e using custom C bit-field structures for type-safe hardware access.\u003c/p\u003e\n\u003ch3 id=\"technical-highlights\"\u003eTechnical Highlights\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eC Bit-Field Structures:\u003c/strong\u003e Utilized custom \u003ccode\u003estruct\u003c/code\u003e definitions to map hardware registers, ensuring type-safe access to individual bits and eliminating manual bitwise masks (\u003ccode\u003e\u0026amp;\u003c/code\u003e, \u003ccode\u003e|\u003c/code\u003e, \u003ccode\u003e\u0026lt;\u0026lt;\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMemory-Mapped I/O (MMIO):\u003c/strong\u003e Manually mapped the RCC (Base: \u003ccode\u003e0x40023800\u003c/code\u003e) and GPIOD (Base: \u003ccode\u003e0x40020C00\u003c/code\u003e) to control hardware clocking and pin states.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSIL Validation (Renode):\u003c/strong\u003e Automated hardware verification using Renode to validate register-level behavior via memory-access tracing. This allows for cycle-accurate auditing of the firmware\u0026rsquo;s execution without physical hardware.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"-simulation--hardware-verification\"\u003e🔍 Simulation \u0026amp; Hardware Verification\u003c/h3\u003e\n\u003cp\u003eThe project is validated using \u003cstrong\u003eRenode\u003c/strong\u003e to trace memory-mapped I/O (MMIO) interactions. This ensures the firmware logic correctly targets the ARM Cortex-M4 register map before deployment to physical silicon.\u003c/p\u003e","title":"STM32F4 Bare-Metal LED Toggle (Bit-Field \u0026 SIL)"},{"content":"Vamsi Kiran Mekala Embedded Systems Engineer | Dublin | vamsikiran167@gmail.com | +353 892745183\n👤 Profile Embedded Systems Engineer with expertise in C/C++, Linux kernel/user space programming, and low-level driver development. Proven track record in designing communication protocol stacks (CAN) and optimizing hardware-software interfaces.\n🎓 Education Master\u0026rsquo;s in Engineering \u0026amp; Electronics and Computer Engineering | Dublin City University\nBachelor\u0026rsquo;s in Science \u0026amp; Electronics and Communication Engineering |National Institute of Technology\n💼 Relevant Experience Embedded Firmware Engineer | Novus Hi-Tech Robotics Systemz Gurugram, India | 07/2023 – 12/2024\nProtocol Stack Development: Architected and implemented a custom CAN protocol stack from scratch in C/C++ for the Gen X product line. Low-Level Implementation: Engineered an ISO 11898-compliant 11-bit identifier system, optimizing bit-wise operations to reduce memory usage on resource-constrained hardware. Driver State Monitoring (DSM): Enhanced DSM firmware, reducing latency in sensor data processing and mapping signal propagation with detailed timing diagrams. 🧰 Technical Skills Languages: C, C++, C++ (Qt 6), Python, Rust, Embedded C, Assembly Embedded: Linux Kernel Modules, Bare-metal Programming, Device Drivers, RTOS (FreeRTOS) Protocols: I2C, SPI, UART, GPIO, CAN/CAN-FD, TCP/IP, MQTT Hardware: Raspberry Pi (BCM2835/2711), ARM Cortex-M Tools: Git, CMake, GDB, Docker, Cross Compilation, OpenOCD 🏆 Key Projects 1. Real-Time Multi-Tasking Telemetry System Architected a preemptive multitasking system using the FreeRTOS kernel on a Raspberry Pi (BCM2711).Integrated Mutex Semaphores to arbitrate shared I2C access between ADXL345 and DS3231 sensors.\n2. Bare-Metal Linux Driver Development Constructed functional device drivers for the BCM2835 SoC interacting directly with Physical Memory via memory mapping. Developed GPIO and UART drivers by manipulating hardware registers directly.\n3. Smart Asset Tracker \u0026amp; Vibration Logger Engineered a secure telemetry pipeline using MQTT to sync data to HiveMQ Cloud with SSL/TLS encryption.Developed a real-time Qt 6 visualization dashboard to parse JSON payloads.\n📥 Download Full Version: Click here to download the PDF version of my resume\n","permalink":"https://vamsikiran277.github.io/resume/","summary":"\u003ch1 id=\"vamsi-kiran-mekala\"\u003eVamsi Kiran Mekala\u003c/h1\u003e\n\u003cp\u003e\u003cstrong\u003eEmbedded Systems Engineer\u003c/strong\u003e | Dublin |\n\u003ca href=\"mailto:vamsikiran167@gmail.com\"\u003evamsikiran167@gmail.com\u003c/a\u003e | \u003ca href=\"tel:+353892745183\"\u003e+353 892745183\u003c/a\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003ch3 id=\"-profile\"\u003e👤 Profile\u003c/h3\u003e\n\u003cp\u003eEmbedded Systems Engineer with expertise in C/C++, Linux kernel/user space programming, and low-level driver development. Proven track record in designing communication protocol stacks (CAN) and optimizing hardware-software interfaces.\u003c/p\u003e\n\u003chr\u003e\n\u003ch3 id=\"-education\"\u003e🎓 Education\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMaster\u0026rsquo;s in Engineering \u0026amp; Electronics and Computer Engineering\u003c/strong\u003e | Dublin City University\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eBachelor\u0026rsquo;s in Science \u0026amp; Electronics and Communication Engineering\u003c/strong\u003e |National Institute of Technology\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"-relevant-experience\"\u003e💼 Relevant Experience\u003c/h3\u003e\n\u003cp\u003e\u003cstrong\u003eEmbedded Firmware Engineer | Novus Hi-Tech Robotics Systemz\u003c/strong\u003e\n\u003cem\u003eGurugram, India | 07/2023 – 12/2024\u003c/em\u003e\u003c/p\u003e","title":"Technical Resume"}]