Telemetry Core

Architectural Overview

Telemetry Core is an embedded telemetry software platform designed for real-time sensor processing, task orchestration, and telemetry communication on ARM Cortex-M4 microcontrollers, specifically targeting the STM32 family. The architecture follows an event-driven Producer-Consumer pattern and separates sensor acquisition, telemetry processing, communication, and event handling into dedicated tasks.

To accelerate development and validate the concurrent application logic before hardware integration, the project currently executes as a host-based RTOS simulation on PC. The simulation layer reproduces the core task, queue, mutex, semaphore, and timing concepts using standard C++ concurrency primitives rather than executing the native FreeRTOS kernel directly. This allows task interactions, telemetry processing, synchronization, logging, and graceful shutdown behavior to be exercised in a desktop environment before deployment to embedded hardware.

+-------------------------------------------------------------------------------+
|                         PC-Based RTOS Simulation                              |
|                                                                               |
|  +--------------------+        Sensor Queue       +-------------------------+ |
|  |    Sensor Task     | ------------------------> |   Processing Task      | |
|  |                    |                           |                         | |
|  | Mock Temperature   |                           | Telemetry Processing    | |
|  | Sensor             |                           | Status Evaluation       | |
|  +--------------------+                           +-----------+-------------+ |
|                                                               |               |
|                                                               | Telemetry      |
|                                                               | Queue          |
|                                                               v               |
|                                                  +-------------------------+  |
|                                                  | Communication Task      |  |
|                                                  |                         |  |
|                                                  | Serialization / Output  |  |
|                                                  +-------------------------+  |
|                                                                               |
|  Simulated Interrupt --------> Semaphore --------> Event Handler             |
+-------------------------------------------------------------------------------+

Component Architecture & Task Decomposition

The system decouples sensor acquisition from downstream telemetry processing and communication through distinct tasks and bounded synchronization primitives.

Observed Facts

• The application implements a Producer-Consumer pipeline using dedicated sensor and telemetry queues.
• A mock temperature sensor generates sensor readings consumed by the processing task.
• Telemetry processing evaluates temperature thresholds and creates structured telemetry packets.
• The communication task consumes telemetry packets, serializes them, and writes the result through a mutex-protected output path.
• A simulated interrupt task periodically signals an event semaphore consumed by a dedicated event-handler task.
• The platform provides task, queue, mutex, and semaphore abstractions through a host-side RTOS simulation layer.
• The project uses C++17 and CMake, with an ARM arm-none-eabi toolchain configured for Cortex-M4 targets.

Architectural Details

• Sensor Task (Acquisition Layer): Periodically reads the mock temperature sensor, creates a SensorReading structure, and publishes the result to the sensor queue.
• Inter-Task Communication (IPC): Bounded queues, a mutex, and a semaphore provide thread-safe communication and synchronization between independent tasks. Queue operations can report conditions such as QUEUE_FULL and SYSTEM_SHUTDOWN.
• Processing Task: Blocks until a sensor reading is available, processes the reading through the telemetry processor, evaluates the system status, and publishes a TelemetryPacket to the telemetry queue.
• Communication Task: Blocks until a telemetry packet is available, serializes the packet into a compact textual representation, and writes the result through a mutex-protected logging/output path.
• Event Handler: Waits on a semaphore released by the simulated interrupt task and records the corresponding event through the logging system.
• Shutdown Handling: Queues and semaphores can be explicitly aborted to wake blocked operations and allow worker tasks to terminate cleanly.

Software Stack & Build Environment

Key Engineering Decisions

Event-Driven vs. Continuous Polling Design

The architecture avoids a traditional single super-loop by separating functionality into independent tasks and using blocking synchronization primitives for inter-task communication. Processing and communication tasks wait for queue data, while the event handler waits for a semaphore signal.

The sensor task itself operates periodically with a simulated 100 ms delay, while the interrupt simulation periodically generates an event. This provides a practical event-driven task model while retaining deterministic periodic sensor acquisition.

Dual-Target Build System via CMake

CMake provides the project build structure for both the native PC simulation and the ARM cross-compilation direction. The ARM toolchain uses arm-none-eabi-gcc / arm-none-eabi-g++ and configures Cortex-M4-specific compiler flags, including Thumb mode and hardware floating-point settings.

The current repository does not yet contain a full STM32 firmware target with device-specific startup code, linker scripts, or STM32 HAL integration; the ARM toolchain represents the project's cross-compilation foundation for future hardware integration.

Abstracted Hardware Access

The application separates sensor and platform functionality through dedicated interfaces and a simulated hardware implementation. The current temperature sensor is a mock implementation, while the telemetry and task-processing logic remains independent of physical STM32 peripherals.

This structure allows the simulated sensor and platform components to be replaced progressively by hardware-specific drivers during STM32 integration.

Observability, Testing, and Memory Safety

• Host-Based Validation: Running the application on a PC allows concurrent task behavior, queue communication, telemetry processing, synchronization, logging, and shutdown handling to be developed without requiring physical microcontroller hardware.
• Bounded Synchronization: The sensor and telemetry queues use fixed capacities, while mutexes and semaphores explicitly coordinate access to shared resources and event delivery.
• Concurrency Protection: Shared output is protected by a mutex, and queue-based communication separates producer and consumer execution paths rather than relying on direct shared-data exchange.
• Graceful Shutdown: Blocking queues and semaphores provide explicit abort mechanisms so waiting tasks can be released and terminated safely.
• Structured Logging: The platform provides INFO, WARN, ERROR, and DEBUG logging paths for observing system behavior during simulation.
• Current Validation Scope: The repository currently provides the simulation and core application logic; dedicated unit-test infrastructure, sanitizer configuration, and static allocation of native FreeRTOS task control blocks are not part of the current implementation.