What is CMSIS and how does it differ from vendor HALs?

CMSIS (Cortex Microcontroller Software Interface Standard) is an ARM-defined standard that provides two things: (1) a set of core access functions for Cortex-M processor features — NVIC configuration (NVIC_EnableIRQ(), NVIC_SetPriority()), SysTick setup, MPU/FPU control, and intrinsics like __DSB(), __WFI(), __REV(); and (2) device header files that define register struct typedefs and base addresses for a specific MCU (e.g., stm32f407xx.h). These headers are generated from SVD (System View Description) files that silicon vendors provide, ensuring every register, every bit field, and every peripheral instance is accurately mapped.

The critical distinction: CMSIS adds zero runtime overhead. It is purely a compile-time abstraction — #define macros, typedef structs, and static inline functions. When you write GPIOA->BSRR = (1 << 5), the compiler generates a single STR instruction to the absolute address. There is no function call, no parameter validation, no lock. CMSIS does not include any peripheral driver logic — it gives you named access to registers but does not tell you what sequence to write to them.

Vendor HALs (STM32 HAL, NXP MCUXpresso SDK, TI DriverLib) build on top of CMSIS. They add peripheral driver functions — HAL_UART_Transmit(), HAL_SPI_Init() — that encapsulate the register write sequences, handle error checking, manage state, and provide a higher-level API. This adds convenience but also runtime overhead: function calls, parameter validation, timeout loops, and internal state tracking. The result is larger code size and less predictable timing. In practice, almost every embedded project uses CMSIS (you cannot avoid it — it defines how you access the core and peripherals), but whether you also use the vendor HAL is a project-level decision based on code size, performance, and portability requirements.