Acronym · Embedded Software & Tools
MCAL (Microcontroller Abstraction Layer)
The lowest AUTOSAR basic software layer, containing the drivers that touch microcontroller registers directly for ADC, PWM, SPI, CAN, watchdog and flash. It presents standardised interfaces upward so higher layers stay device independent.
- Type
- Acronym
- Domain
- Embedded Software & Tools, Automotive software
Notes
Supplied by the microcontroller vendor and often the first thing a silicon supplier must deliver to win an automotive socket.
Overview
MCAL, the Microcontroller Abstraction Layer, is the lowest layer of AUTOSAR Classic Platform basic software, made up of the drivers that access a microcontroller's registers and on-chip peripherals directly. Its job, as AUTOSAR puts it, is to make the higher software layers independent of the particular microcontroller. Because it is tied so closely to the silicon, the MCAL for a given automotive microcontroller is normally written and supplied by the chip vendor.
How it works
AUTOSAR groups the MCAL into module families. Microcontroller drivers cover the clock and power unit, watchdog, general-purpose timers and core self-tests. Memory drivers handle internal flash and EEPROM. Communication drivers cover on-board buses such as SPI and I2C and vehicle networks such as CAN, LIN, FlexRay and Ethernet. I/O drivers handle ports, digital I/O, ADC and PWM, and crypto drivers give access to on-chip security hardware such as an HSM. Each module has an AUTOSAR specification that fixes its upward interface, so the layers above call the same functions whichever chip is underneath; only the implementation below is chip-specific.
An MCAL is configured rather than edited. Tools such as EB tresos read a parameter definition for each module and generate source files that map the chosen settings, such as baud rates, channel lists and pin functions, onto the chip's registers. Above the MCAL, the ECU abstraction layer adds drivers for external devices on the board, accessing them through the MCAL.
For safety-relevant ECUs the MCAL is part of the safety case. TI, for example, describes its MCAL package as safety-certified driver modules rated ASIL B or D depending on the device, developed under an ISO 26262 compliant process, with drivers that implement the hardware safety mechanisms listed in the device safety manual.
Examples
- TI's MCAL package for AM263x microcontrollers, which implements the AUTOSAR 4.3.1 driver specifications and is configured with EB tresos.
- A CAN driver in the MCAL that the AUTOSAR communication stack above uses without knowing which CAN controller is fitted.
- An ADC driver configured to sample a set of sensor channels on a timer trigger for a motor control ECU.
- A crypto driver that exposes an on-chip HSM to the AUTOSAR crypto stack for secure onboard communication.
Why it matters
Car makers and tier-one suppliers often expect an AUTOSAR MCAL before they will design in a new automotive microcontroller, so its quality, AUTOSAR release level and safety status are part of the chip's competitiveness. MCAL developers at the silicon vendor write and test it, while AUTOSAR integrators and classic software engineers at customers configure it and build on it.
Related terms
Part of the Embedded Software & Tools glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 4 pages of the Hub. In each group, the pages that mention it most come first.
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary