Bare-Metal

🛠 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. Technical 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 “busy-wait” 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 & 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. ...

🛠 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). ...

🛠 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. ...

🛠 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. Technical 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 (&, |, <<). 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’s execution without physical hardware. 🔍 Simulation & 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. ...