Robert Rico – An Embedded Systems Engineer

Structured Documentation & Reliable Solutions for Embedded Projects

Category: The Earth Rover

  • Earth Rover Development: ADC Expansion Discovery and the Catalyst for DINO

    Earth Rover Development: ADC Expansion Discovery and the Catalyst for DINO

    From Motor Control to Analog Input Reality

    With STM32 integration providing reliable motor control communication architecture, the logical next step was replacing test data with real analog inputs from joystick potentiometers. This seemingly straightforward transition exposed a fundamental limitation that would reshape not only The Earth Rover project but spark an entirely new direction in digital logic exploration.

    The ESP32-C3’s ADC constraints revealed themselves precisely when the project demanded more analog channels than the hardware could provide. This discovery initiated a chain of investigation that led from analog multiplexing solutions to discrete logic exploration, ultimately catalyzing the DINO CPU project.

    The ADC Limitation Discovery

    Initial rover control requirements seemed well within ESP32-C3 capabilities:

    Required Analog Inputs:

    • Left joystick X-axis (horizontal movement)
    • Left joystick Y-axis (forward/backward movement)
    • Right joystick X-axis (rotation control)
    • Future expansion: Battery voltage monitoring
    • Future expansion: Current sensing feedback

    ESP32-C3 ADC Reality:

    • ADC1: 5 channels available (GPIO0-GPIO4)
    • ADC2: Shared with Wi-Fi functionality (unreliable during ESP-NOW operation)
    • Effective channels: 3 reliable ADC inputs

    The math was unforgiving: 5 required inputs, 3 available channels.

    Initial Workaround Attempts

    Channel Sharing Investigation: Testing revealed ADC2 interference with ESP-NOW communication, making Wi-Fi and additional ADC channels mutually exclusive.

    External ADC Evaluation: Adding dedicated ADC chips (MCP3008, ADS1115) introduced I2C/SPI complexity and additional component costs.

    Redesign Considerations: Moving to ESP32-S3 would solve the ADC problem but require complete firmware architecture changes.

    None of these approaches felt elegant for a project focused on understanding embedded fundamentals rather than simply achieving functional goals.

    The CD4053BE Discovery

    Research into analog signal routing led to analog multiplexers, specifically the CD4053BE triple 2-to-1 analog switch.

    CD4053BE Characteristics

    Component: CD4053BE Triple 2-to-1 Analog Multiplexer Function: Routes analog signals based on digital control inputs Key Specifications:

    • Three independent 2-to-1 switches
    • 5V operation compatible with ESP32-C3
    • Low on-resistance (80Ω typical)
    • Control via digital GPIO pins

    Multiplexer Implementation Investigation

    The CD4053BE enabled potential ADC expansion through time-division multiplexing concepts. Research focused on understanding how analog multiplexing could address the channel limitation while maintaining signal integrity.

    Channel Expansion Potential

    With three CD4053BE multiplexers, the ADC capability could expand significantly:

    Original: 3 ADC channels With Multiplexing: 6 ADC channels (3 × 2-to-1 switching) Future Scalability: 12+ channels possible with additional multiplexers

    This solution offered the analog input capacity needed for comprehensive rover control while introducing minimal complexity.

    KiCAD and Wiring Diagram Necessity

    The multiplexer integration revealed the inadequacy of breadboard prototyping for documenting and maintaining complex analog circuits.

    Circuit Complexity Growth

    Component Count Increase:

    • ESP32-C3 controller
    • STM32L432KC motor control board
    • Three CD4053BE multiplexers
    • Joystick potentiometers (multiple axes)
    • Power distribution and filtering

    Wiring Complexity:

    • ADC signal routing through multiplexers
    • Digital control lines for MUX selection
    • Power distribution for multiple voltage domains
    • SPI communication between controllers

    KiCAD Learning Integration

    Schematic Capture: Creating formal circuit diagrams for reproducible builds Component Library Management: Establishing standardized symbols for project components Net Management: Tracking signal routing across complex multi-board systems Documentation Standards: Generating professional-quality circuit documentation

    Engineering Insight: Complex embedded projects require formal circuit documentation for debugging, reproduction, and future modification. Breadboard sketches become inadequate quickly.

    The Endianness Resolution

    Successful analog multiplexing implementation required resolving data format consistency across the entire TX→RX→MCB communication chain.

    Multi-Platform Data Consistency

    ESP32-C3 ADC Data: 12-bit values in little-endian format ESP-NOW Transmission: Network byte order considerations STM32 Reception: ARM Cortex-M little-endian native format

    Protocol Development

    Establishing consistent data representation became critical for reliable multi-platform communication. The investigation focused on creating standardized data formats that would work reliably across ESP32-C3, ESP-NOW, and STM32 platforms.

    Integration Milestone Achievement

    The successful completion of analog multiplexing investigation marked a critical project milestone:

    Technical Understanding Achieved

    1. ADC Expansion Strategy: 3 channels expandable to 6+ through analog multiplexing
    2. Real Analog Input Planning: Joystick potentiometers ready to replace test data throughout system
    3. Multi-Platform Data Consistency: Reliable data format standards across ESP32-C3, ESP-NOW, and STM32
    4. Circuit Documentation Framework: Formal KiCAD schematics for reproducible construction
    5. System Integration Readiness: Complete TX→RX→MCB chain prepared for real sensor inputs

    The DINO Catalyst

    The CD4053BE multiplexer investigation had an unexpected consequence: it sparked fascination with discrete logic components and their capabilities.

    Digital Logic Curiosity

    Working with the CD4053BE raised fundamental questions:

    • How do analog switches work at the transistor level?
    • What other logic functions can be implemented with discrete components?
    • Could complex digital systems be built without microcontrollers?

    Historical Computing Interest

    The multiplexer research led to exploration of historical computing architectures:

    • How were computers built before microprocessors?
    • What logic was possible with TTL and CMOS components?
    • Could a complete CPU be constructed from discrete logic?

    DINO Project Genesis

    These questions catalyzed the DINO (Discrete INtegrated Operations) CPU project – an exploration of building computational systems using only discrete logic components, no microcontrollers.

    Key Realization: The same problem-solving approach used for analog multiplexing could be applied to digital logic design. Sequential circuits, memory systems, and arithmetic operations were all achievable with discrete components.

    Engineering Philosophy: Understanding computational fundamentals by building them from first principles, just as the bare-metal C programming had revealed embedded system foundations.

    Project Trajectory Transformation

    The successful Earth Rover ADC expansion investigation created an unexpected fork in the development path:

    Rover Development Continuation

    With analog input strategy established, The Earth Rover project could continue toward:

    • Enhanced control algorithms
    • Autonomous navigation features
    • Remote monitoring capabilities
    • Advanced sensor integration

    DINO Project Initiation

    Simultaneously, the discrete logic curiosity sparked an entirely new project direction:

    • CPU-free digital logic exploration
    • Sequential circuit design with discrete components
    • Memory systems built from TTL/CMOS logic
    • Eventually: complete 8-bit CPU construction

    Engineering Decision: Rather than choosing between projects, both would proceed in parallel, with rover development providing practical embedded experience while DINO explored computational fundamentals.

    Methodology Evolution

    The ADC expansion phase refined several critical engineering practices:

    Component Research Depth

    Beyond Specifications: Understanding not just what components do, but how they enable system-level capabilities Alternative Solution Evaluation: Systematic comparison of different approaches before implementation Scalability Consideration: Choosing solutions that support future expansion rather than minimum viable implementations

    Documentation Standards

    Formal Circuit Documentation: KiCAD schematics as first-class project deliverables Integration Testing Protocols: Systematic validation procedures for multi-component systems Decision Rationale Recording: Documenting why specific approaches were chosen for future reference

    Learning Transfer

    Cross-Project Knowledge Application: Multiplexer investigation techniques transferring to discrete logic exploration Fundamental Principles Focus: Understanding underlying concepts rather than memorizing specific implementations Question-Driven Investigation: Allowing curiosity about component behavior to drive deeper technical exploration

    Looking Forward: Parallel Development Paths

    The successful ADC expansion milestone established two parallel development trajectories:

    Earth Rover Evolution

    Continued development of the rover platform with enhanced capabilities:

    • Advanced control algorithms using expanded analog inputs
    • Autonomous navigation feature development
    • Remote monitoring and telemetry systems
    • Integration with additional sensor modalities

    DINO Project Launch

    Exploration of discrete logic computational systems:

    • Basic sequential circuit design and implementation
    • Memory system construction from discrete components
    • Arithmetic logic unit development
    • Eventually: complete CPU architecture implementation

    Unified Approach: Both projects would share the same methodical engineering approach, systematic documentation practices, and fundamental understanding focus that had proven successful throughout the rover development.

    Key Insight: Sometimes the most valuable project outcomes are the unexpected directions they reveal. The ADC expansion investigation solved an immediate technical problem while opening entirely new avenues for exploration and learning.

  • Earth Rover Development: STM32 Integration and SPI/DMA Challenges

    Earth Rover Development: STM32 Integration and SPI/DMA Challenges

    From Working Communication to Real-Time Control

    After establishing reliable ESP-NOW communication between TX and RX devices and implementing basic SPI functionality, the next critical milestone was integrating the STM32L432KC Motor Control Board (MCB) into the data flow. What seemed like a straightforward addition of another SPI peripheral quickly revealed the complexities of multi-platform embedded development and real-time system requirements.

    The goal was clear: extend the proven TX→RX communication chain to TX→RX→MCB, enabling joystick commands to control motors through a dedicated motor control processor. The reality involved wrestling with timing domains, DMA buffer management, and the fundamental differences between ESP32-C3 and STM32 development ecosystems.

    Development Environment Transition

    Moving from the unified ESP-IDF environment to STM32 development required establishing an entirely different toolchain and workflow.

    STM32CubeMX vs. STM32CubeIDE Decision: Initial attempts with STM32CubeIDE revealed it created friction with the established VIM and CMake workflow. STM32CubeMX for code generation, followed by CMake integration, maintained consistency with the ESP32-C3 development approach while providing the necessary STM32 peripheral configuration.

    OpenOCD and GDB Return: Unlike ESP-IDF’s integrated debugging, STM32 development required manual OpenOCD configuration and GDB setup. This transition back to lower-level debugging tools provided more direct control but demanded greater familiarity with ARM debugging fundamentals.

    CMake Integration Challenges: Combining STM32CubeMX-generated code with a custom CMake build system required careful management of generated files and manual integration of STM32 HAL libraries.

    STM32 SPI Peripheral Implementation

    Configuring the STM32L432KC as a full-duplex SPI peripheral introduced new categories of complexity beyond the ESP32-C3 controller implementation.

    Basic Peripheral Configuration

    The STM32 SPI peripheral required careful timing coordination with the ESP32-C3 controller. Initial configuration established the foundation for bidirectional communication.

    Interrupt Handling Architecture

    Unlike the ESP32-C3 controller side, the STM32 peripheral required reactive interrupt handling for incoming data. The peripheral couldn’t predict when the ESP32-C3 would initiate communication, requiring robust buffer management and rapid response capability.

    DMA Integration Necessity

    Initial polling-based SPI implementation quickly revealed timing inadequacies for real-time motor control. When motor commands required processing within tight timing windows, CPU-blocking SPI operations created unacceptable latency.

    DMA Configuration Investigation

    Implementing DMA for SPI communication required understanding buffer management requirements and timing constraints. The investigation revealed the complexity of coordinating DMA transfers with SPI communication timing.

    DMA Buffer Management Exploration

    Initial DMA implementation focused on circular buffer approaches, though this would later prove problematic for the specific timing requirements. Circular buffer management introduced complex state tracking requirements that demanded careful evaluation.

    Timing and Synchronization Challenges

    Cross-platform communication revealed fundamental timing domain differences between ESP32-C3 and STM32L432KC.

    Clock Domain Differences

    The ESP32-C3 and STM32 operated at different base frequencies, creating setup/hold time violations:

    • ESP32-C3: 80MHz APB clock with configurable SPI divisors
    • STM32L432KC: 80MHz system clock with independent SPI timing

    Logic Analyzer Validation

    Timing issues required systematic logic analyzer investigation:

    Setup Time Violations: ESP32-C3 data transitions occurred too close to STM32 clock edges Hold Time Issues: STM32 data wasn’t stable long enough for ESP32-C3 sampling Clock Jitter: Inconsistent timing between platforms caused intermittent communication failures

    Resolution Strategy: Reducing SPI clock frequency from 1MHz to 500kHz provided adequate timing margins for both platforms.

    Data Format and Endianness Resolution

    Multi-platform communication exposed byte ordering inconsistencies that required protocol-level solutions.

    Endianness Investigation

    Multi-platform communication revealed the importance of data format consistency. The investigation identified potential byte ordering issues that required systematic resolution for reliable data transfer between ESP32-C3 and STM32L432KC platforms.

    Protocol Definition Investigation

    Establishing a consistent packet structure required careful consideration of data format and transmission reliability. The investigation focused on creating robust communication protocols for multi-platform embedded systems.

    Integration Success Criteria

    The STM32 integration milestone was considered complete when several critical capabilities were demonstrated:

    1. Reliable Multi-Platform Communication: ESP32-C3 to STM32L432KC data transfer without corruption
    2. Real-Time Performance: Communication architecture ready for motor control timing requirements
    3. DMA Stability: Continuous operation without buffer overflows or communication failures
    4. Bidirectional Data Flow: Motor status feedback successfully transmitted back to ESP32-C3
    5. System Scalability: Architecture ready for additional peripheral integration

    Engineering Methodology Validation

    This integration phase reinforced several critical embedded development practices:

    Component Isolation Testing: Each SPI implementation was validated independently before integration Logic Analyzer Dependency: Complex timing relationships couldn’t be debugged without hardware-level visibility Systematic Problem Resolution: Multi-platform issues required methodical investigation across both development environments Documentation Discipline: Engineering journal entries became essential for tracking cross-platform debugging discoveries

    Looking Forward: ADC Limitations Discovery

    With reliable STM32 integration established, the next development phase focused on replacing test data with real analog inputs from joystick potentiometers. This transition would quickly reveal the ESP32-C3’s ADC limitations and catalyze the discovery of analog multiplexing techniques that would fundamentally change the project’s trajectory.

    The successful STM32 integration provided the stable foundation necessary for the analog input expansion that followed, demonstrating how methodical subsystem development enables complex system capabilities.

    Key Takeaway: Multi-platform embedded development requires understanding each platform’s timing characteristics, development ecosystem differences, and communication protocol requirements. Success depends on systematic integration testing and comprehensive hardware-level debugging.

  • SPI Communication: From Theory to Working Protocol

    SPI Communication: From Theory to Working Protocol

    The ESP32-C3 receives joystick data via ESP-NOW and needs to transmit motor commands to the STM32L432KC motor control board. Simple enough in concept—SPI communication between microcontrollers handles this interface. The reality involved learning SPI fundamentals, implementing interrupt service routines, debugging timing discrepancies between logic analyzers and software logs, and discovering the critical importance of proper ISR design in embedded systems.

    Learning SPI from Fundamentals

    The journey began with understanding what SPI actually is. Re-reading chapters from “Making Embedded Systems” by Elicia White provided the theoretical foundation, but implementing it on the ESP32-C3 required reverse engineering existing code examples.

    An OLED tutorial provided the starting point—working SPI code that could be dissected and understood. This exploration led to implementing the first interrupt service routine (ISR) for the project, a milestone that opened understanding of hardware-driven event handling.

    ESP32-C3 SPI Implementation Discovery

    The ESP32-C3’s SPI implementation proved more complex than basic SPI theory suggested. Converting from C++ to C reduced ROM footprint—a lesson learned from the OTA project where unused libraries consumed significant memory space.

    Understanding the chip select (~CS) pin behavior became crucial. Unlike SCLK, MISO, and MOSI pins that have specialized SPI functions, ~CS operates as a standard GPIO pin under software control. This revelation explained much about SPI transaction management.

    Hardware Interface Reality

    Implementing physical SPI communication required understanding pull-up and pull-down resistors. A simple button interface for testing SPI functionality introduced these concepts practically—buttons need proper electrical termination to function reliably.

    Success came gradually. An LED controlled via SPI and ISR provided the first evidence that SPI transactions were occurring. The LED blinked in response to SPI activity, confirming that the interrupt system was triggering correctly.

    Development Environment Decisions

    Initial attempts used pure CMake for ESP32-C3 development, aiming for maximum control over the build process. However, the complexity of ESP32-C3’s hardware abstraction and peripheral drivers made esp-idf the pragmatic choice for forward progress.

    This decision eliminated the need for OpenOCD and GDB debugging, though it meant sacrificing the low-level control and visibility those tools provide. The aspiration to move away from esp-idf remains, but development velocity took priority.

    Protocol Verification and Debugging

    Logic analyzer verification provided the first definitive proof that SPI was working correctly. Visual confirmation of clock signals, data transitions, and timing relationships gave confidence that the implementation was fundamentally sound.

    However, confidence wasn’t complete. Understanding exactly what was happening required deeper investigation, but the logic analyzer confirmed that data was flowing and the ISR was responding to SPI events appropriately.

    Further testing at 1MHz sampling on the logic analyzer revealed consistent data patterns responding to test inputs. The breakthrough came when ASCII data became visible in the logic analyzer traces—’LIGHT_ON’ messages appeared clearly, confirming end-to-end communication.

    A timing discrepancy emerged between logic analyzer captures and ESP_LOG output. The hardware showed one timing pattern while software logs suggested different behavior. This inconsistency demanded resolution before proceeding to STM32 integration.

    Transmitter Development and FreeRTOS Discovery

    The transmitter (TX) side required attention to resolve timing issues. Converting from C++ to C and implementing the same esp-idf workflow used for the receiver provided consistency across the communication system.

    The TX implementation used binary semaphores—a pattern that triggered recognition from university training that there might be better synchronization mechanisms available. The ESP32-C3 natively incorporates FreeRTOS, explaining why the main entry point is app_main() rather than standard main(). This architecture provides multitasking capabilities built into the hardware platform.

    Understanding this RTOS foundation led to exploring FreeRTOS queues—a familiar concept from software development experience. Queues provide clean data flow between interrupt handlers and application tasks.

    ISR Design Breakthrough

    Implementing queues revealed a fundamental ISR design error. The interrupt service routine was performing too much work—attempting to send data and introduce delays within the ISR itself. This violated the cardinal rule of interrupt handling: keep ISRs short and fast.

    The solution involved restructuring the ISR to simply add data to a queue, then handling transmission in a separate task. This architectural change separated time-critical interrupt handling from communication processing.

    System Integration Success

    Resolving the timing discrepancy required coordinated debugging using the logic analyzer captures and ESP_LOG output analysis. This multi-tool approach provided complete visibility into system behavior.

    The combination of proper queue implementation and corrected ISR design eliminated timing issues entirely. Logic analyzer traces and software logs finally agreed about communication timing and data flow.

    Complete TX to RX data relay functioned with zero timing issues. The logic analyzer and ESP logs showed consistent behavior, confirming reliable wireless communication. This achievement provided confidence that the wireless communication system was fundamentally sound and ready for integration with motor control hardware.

    Foundation for Complex Integration

    The SPI implementation process established critical embedded systems knowledge: interrupt service routine design principles, hardware-software integration using logic analyzers, RTOS utilization through FreeRTOS queues, and debugging methodology coordinating multiple tools for complete system visibility.

    The progression from theoretical SPI understanding to working inter-processor communication demonstrated how embedded systems development requires both hardware and software expertise operating together. Logic analyzer verification proved essential for distinguishing between “it seems to work” and “it definitely works correctly.”

    With wireless communication proven reliable, the STM32 integration phase awaits—bringing DMA complexity, precise timing constraints, and bit ordering challenges that will test this communication foundation under real motor control conditions. The systematic debugging methodology and RTOS architecture established here provide the engineering discipline necessary for tackling those advanced integration challenges.

    Transmitter Source Code
    Receiver Source Code
  • The Earth Rover: Engineering a Multi-MCU Control System

    The Earth Rover: Engineering a Multi-MCU Control System

    From Wireless Communication to Precision Motor Control

    After wrestling with RP2040 boot sequences and bare-metal register programming, I needed a project that would synthesize everything learned while pushing into genuinely uncharted territory. The Earth Rover emerged as that challenge: a modular, extensible rover system built around proven embedded technologies but demanding new levels of integration complexity.

    System Architecture Overview

    Communication Layer: ESP32-C3 devices implementing ESP-NOW protocol 

    Motor Control: STM32L432KC with a TB6612FNG driver

    Interface Protocol: SPI with DMA for high-speed data transfer 

    Control Input: Analog joystick with multiplexed ADC expansion

    The rover represents three distinct engineering challenges operating as a unified system. Unlike previous projects that explored single concepts, this demanded mastery of wireless protocols, real-time motor control, and inter-processor communication simultaneously.

    The Technical Evolution

    From Simple to Complex Communication

    The communication system evolved from basic ESP-NOW message passing to sophisticated 12-bit ADC transmission. Early implementations sent simple command tokens (LIGHT_ON, MOTOR_FORWARD) but rover control demanded continuous analog precision.

    ADC Resolution Challenge: Transmitting joystick positions as 12-bit values (0-4095) required careful attention to byte ordering and data integrity. ESP-NOW’s packet-based nature meant each transmission needed proper framing and error detection.

    Little Endian Encoding: ADC values split across byte boundaries demanded consistent endianness handling:

    c// Transmit 12-bit ADC as two bytes
uint16_t adc_value = 2048;            // Mid-scale
tx_data[0] = adc_value & 0xFF;        // LSB first
tx_data[1] = (adc_value >> 8) & 0xFF; // MSB second

    Hardware Constraint Solutions

    ADC Limitation Discovery: The ESP32-C3 provides only 3 usable ADC pins, insufficient for dual joystick control (4 analog axes required). This constraint drove the implementation of analog multiplexing.

    CD4053BE Integration: The triple 2-channel analog multiplexer expanded 3 ADC inputs to 6, enabling complete joystick interface plus auxiliary sensor inputs. The multiplexer selection logic required precise timing coordination with ADC sampling.

    Multiplexer Control Sequence:

    1. Set digital select lines for desired channel
    2. Allow 10μs settling time for analog switching
    3. Trigger ADC conversion
    4. Store result with channel identification
    5. Advance to next channel

    This seemingly simple expansion revealed the importance of analog signal integrity and timing precision in embedded systems.

    Motor Control Board Architecture

    STM32L432KC Selection Rationale

    Processing Requirements: Motor control demands real-time response to changing input conditions. The STM32L432KC’s Cortex-M4 core with FPU provides computational headroom for control algorithms while maintaining deterministic timing.

    FreeRTOS Integration: Unified RTOS architecture between ESP32-C3 (native FreeRTOS) and STM32 (ported FreeRTOS) enables consistent multitasking patterns across the system.

    Development Workflow Optimization: Previous experience with STM32CubeIDE revealed workflow friction with existing VIM-based development patterns. The solution: STM32CubeMX for initial code generation, then integration into CMake-based builds.

    TB6612FNG Motor Driver

    Bidirectional Control: The TB6612FNG drives two motors with independent speed and direction control. The rover’s dual-motor configuration provides complete maneuverability with a single driver IC.

    PWM Speed Control: Motor speed regulation through STM32 timer-generated PWM signals. Frequency selection (1kHz) balances motor response with electromagnetic interference considerations.

    Current Sensing: Driver IC current feedback enables torque monitoring and stall detection for advanced control algorithms.

    SPI Communication Protocol

    Controller-Peripheral Architecture

    ESP32-C3 as Controller: The wireless receiver aggregates joystick data and system commands, then dispatches motor control updates via SPI.

    STM32 as Full-Duplex Peripheral: Motor control board responds to commands while simultaneously reporting motor status, current consumption, and sensor feedback.

    DMA Implementation Challenges

    Buffer Overflow Mitigation: Initial implementations suffered data corruption during high-frequency updates. DMA buffering resolved timing issues but introduced synchronization complexity.

    Packet Synchronization: Misaligned data reception required packet header implementation (0x1234 sync pattern) for reliable frame detection.

    Manual Chip Select Control: Hardware SPI /CS proved unreliable for packet boundaries. External interrupt (EXTI) control of chip select provided precise transaction timing.

    Engineering Methodology

    Iterative Development Approach

    Component Isolation: Each subsystem developed and validated independently before integration. ESP-NOW communication verified separately from motor control logic.

    Logic Analyzer Validation: Every protocol implementation validated with logic analyzer captures. Signal integrity problems invisible to software debugging became immediately apparent.

    Documentation Discipline: Real-time engineering journal maintained throughout development. Every design decision, failed approach, and breakthrough documented with sufficient detail for reproduction.

    Tool Integration

    Development Environment: VSCode with CMake for both ESP-IDF (ESP32-C3) and STM32 projects. Unified build system across heterogeneous targets.

    Debugging Infrastructure: OpenOCD and ARM GDB for STM32 debugging. ESP-IDF monitor for ESP32-C3 development. Logic analyzer for protocol verification.

    Version Control Strategy: Shared repository for the time being as I develop and build mastery in embedded systems.

    Current Status and Challenges

    Operational Achievements

    • ESP-NOW wireless communication established and stable
    • ADC multiplexing functional with 6-channel capability
    • STM32 motor control board responsive to SPI commands
    • Single motor driver operational with PWM speed control

    Active Development Areas

    SPI Protocol Refinement: Packet synchronization and error recovery mechanisms under development. Current focus on robust communication in electrically noisy motor control environment.

    Control Algorithm Implementation: Basic motor drive functional. Advanced features (acceleration limiting, coordinated turning, obstacle avoidance) planned for subsequent phases.

    System Integration Testing: Individual subsystems validated. Complete system integration testing in progress.

    Project Significance

    The Earth Rover represents a convergence of multiple embedded systems disciplines: wireless communication, real-time control, analog signal processing, and inter-processor protocols. Unlike tutorial projects that demonstrate single concepts, this system demands simultaneous mastery of diverse technologies.

    More importantly, it revealed how hardware constraints drive innovative solutions. The ESP32-C3’s ADC limitation led to multiplexer implementation, which sparked fascination with analog switching principles. This curiosity about fundamental logic operations ultimately catalyzed the DINO CPU project.

    Engineering Philosophy: Complex systems emerge from the disciplined integration of well-understood components. The rover’s success depends not on exotic technologies, but on meticulous attention to interfaces, timing, and signal integrity.

    The journey from simple ESP-NOW message passing to precision multi-axis motor control demonstrates how embedded systems engineering scales from basic communication to sophisticated control systems through methodical complexity building.