Data Types, Qualifiers & Storage Classes - Embedded C/C++ for Automotive

Fixed-Width Integer Types (stdint.h / Platform_Types.h)

Type	Width	Range	AUTOSAR Alias	Typical Embedded Use
uint8_t	8-bit	0–255	uint8	GPIO register fields, CAN data bytes, flags
int8_t	8-bit signed	−128–127	sint8	Signed sensor offsets, signed status
uint16_t	16-bit	0–65535	uint16	ADC raw values, timer counts, CAN IDs
int16_t	16-bit signed	−32768–32767	sint16	Signed sensor readings (temperature, current)
uint32_t	32-bit	0–4 294 967 295	uint32	Timer compare values, addresses, CRC results
int32_t	32-bit signed	±2 147 483 648	sint32	Accumulated sums, fixed-point scaled values
uint64_t	64-bit	0–18.4×10¹⁸	uint64	Timestamp (STM nanoseconds), large counters

⚠️ Never use plain int/short/long in automotive code

The sizes of int, short, and long are implementation-defined and change across compilers and architectures. On a 32-bit Aurix, int is 32 bits; on an 8-bit AVR it is 16 bits. MISRA-C:2012 Rule 6.1 requires that bit fields use explicitly-sized types. Always use uint8_t/int16_t etc. from <stdint.h> or AUTOSAR Platform_Types.h.

Type Qualifiers: volatile, const, restrict

Cqualifiers.c

/* volatile: tells the compiler the value can change outside its control */
/* Without volatile, compiler may cache the register value in a CPU register */
volatile uint32_t * const PORTA = (volatile uint32_t *)0xF0001000u;

/* Reading GPIO input without volatile: compiler may read once and cache */
/* With volatile: each access generates a load instruction */
uint8_t read_button(void) {
    return (uint8_t)((*PORTA >> 3u) & 0x01u);  /* bit 3 = button */
}

/* const: value must not be modified; helps compiler place data in flash */
static const uint16_t ADC_FULLSCALE = 4095u;
static const float    VREF_VOLTS    = 3.3f;

/* const + volatile: a read-only hardware status register */
/* const: software must not write it; volatile: hardware can change it */
static volatile const uint32_t * const STATUS_REG =
    (volatile const uint32_t *)0xF0002000u;

/* restrict: pointer is the only way to access that object — enables optimisation */
/* MISRA Rule 8.6 and ISO C99 restrict keyword */
void vector_add(uint32_t * restrict dst,
                const uint32_t * restrict src,
                uint32_t len)
{
    for (uint32_t i = 0u; i < len; i++) {
        dst[i] = dst[i] + src[i];  /* no aliasing possible → loop vectorisable */
    }
}

Storage Classes and Linkage

Storage Class	Keyword	Location	Lifetime	Linkage	Embedded Use
Automatic	(default / auto)	Stack	Function scope	None	Local variables, loop counters
Static (local)	static	BSS/Data	Program lifetime	None (file-local)	Persistent state between function calls; ISR counters
Static (file)	static (file scope)	BSS/Data	Program lifetime	Internal	Module-private globals; MISRA: prefer over extern globals
External	extern	BSS/Data	Program lifetime	External	Cross-module shared variables; use sparingly
Register	register	CPU register (hint)	Function scope	None	Rarely used; modern compilers ignore it

AUTOSAR Platform Types and Std_ReturnType

Cautosar_types.c

/* AUTOSAR Platform_Types.h: standard types used across all BSW modules */
#include "Platform_Types.h"
#include "Std_Types.h"

/* Std_ReturnType: the standard function return code */
/* E_OK = 0x00u; E_NOT_OK = 0x01u */
Std_ReturnType Sensor_ReadTemperature(sint16 *tempOut)
{
    if (tempOut == NULL_PTR) {          /* NULL_PTR = ((void *)0) in AUTOSAR */
        return E_NOT_OK;
    }
    /* Read ADC, scale, store */
    *tempOut = (sint16)((ADC_Read(ADC_CHANNEL_TEMP) * 330) / 4095) - 40;
    return E_OK;
}

/* boolean type: TRUE/FALSE (not C99 _Bool) */
boolean IsEngineRunning(void)
{
    return (boolean)(g_engineRpm > 0u ? TRUE : FALSE);
}

/* uint8 array: CAN data buffer — 8 bytes exactly */
typedef struct {
    uint8  data[8];
    uint8  dlc;
    uint16 id;
} CanFrame_t;

Summary

Fixed-width integer types are mandatory in automotive embedded C: they make sizes explicit, enable portability across 8/16/32-bit targets, and satisfy MISRA-C:2012 Rule 6.1. The volatile qualifier is essential for hardware register access and shared variables in ISR/task contexts — omitting it causes the compiler to optimise away reads/writes that must occur. AUTOSAR Std_ReturnType and Platform_Types.h are the portable layer used by all BSW modules; application code should use the same types for consistency.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.