The Software Tech Stack

This document outlines the hardware and software technologies utilized by the ART TU Cluj software department. Familiarize yourself with these architectures and tools, as they form the foundation of our firmware development cycle.

Hardware architectures

Our custom PCBs revolve strictly around the STM32 ecosystem. You will be writing firmware targeting the following microcontroller families, depending on the module's power and performance requirements.

MCU Family	Architecture	Primary Application in the Vehicle
STM32G4 Series	ARM Cortex-M4	Mixed-signal heavy modules and power distribution systems.
STM32H5 Series	ARM Cortex-M33	High-performance compute nodes requiring faster processing capabilities and advanced peripherals.
STM32L5 Series	ARM Cortex-M33	Ultra-low power applications, continuous state monitoring, and isolated inverter nodes.

Documentation

Do not rely solely on the HAL definitions. Always download and reference the specific Reference Manual and Datasheet for the exact MCU part number you are programming.

Firmware & Languages

Our execution environment is built for determinism and hardware-level control.

• C (C99/C11): The primary language for all low-level hardware abstraction, peripheral initialization, and interrupt service routines.
• C++ (C++14/17): Utilized in higher-level application layers to implement object-oriented architectures, mostly in applications in which we are forced to work with it (e.g. TouchGFX)
• Eclipse ThreadX (Azure RTOS): The Real-Time Operating System driving our task scheduling.

RTOS Rationale

ThreadX provides deterministic context-switching and a minimal memory footprint. It is more feature rich than FreeRTOS and has way more integration with STM32 MCUs (such as NETXDUO or other such packages).

Toolchain & Environment

A standardized development environment across all eight team members is critical to prevent build discrepancies.

Editor & Build Tools

• Visual Studio Code: The universal editor for the department.
• STM32CubeIDE Extension: The bridge between VS Code and the ST build tools.
• ARM GCC Toolchain: The compiler targeting our Cortex-M processors.
• CMake / Make: Build system generators for compiling the source trees.

Flashing & Debugging

• ST-Link V2 / V3: Hardware programmers for flashing the .elf/.bin files.
• OpenOCD / GDB: The backend tools powering live debugging sessions. These allow us to halt execution, step through threads, and inspect register states directly on the hardware. We used the integrated debugging layers from the STM32 VSCode extension.

Communication Protocols

The vehicle operates as a distributed system, with modules exchanging critical state data continuously.

1. CAN 2.0B / FDCAN: The primary vehicle bus. Used for robust, differential module-to-module communication.
2. I2C: Implemented for slower, onboard management tasks like polling EEPROMs or SoC monitoring on LV batteries.
3. UART / USART: Used for the inverters (translated to RS232 after) and the GPS module.

Version Control & Documentation

Our code must be tracked and understandable by any team member picking up a board.

• Git & GitHub: The central repository for all source code.
• Vitepress: You're looking at it...

Team Rule: Code merged into the main branch must compile without warnings, pass any relevant software-in-the-loop tests, and include updated Doxygen-like headers for newly introduced functions.