RTA Knowledge Base

Skip to end of banner
Go to start of banner

Getting started with MCAL configurations using RTA-CAR

Contents 

Introduction

The Microcontroller Abstraction Layer (MCAL) is a layer of SW that provides an abstraction of microcontroller hardware to higher-lever software layers. It helps in achieving portability and scalability in embedded software development by abstracting the hardware-specific details.

This documentation aims to guide user's introduction to MCAL modules and how to generate and take over the MCAL configurations ETAS BSW and Starter Kit, first let's talk about MCAL modules.

MCAL Modules

Can (Controller Area Network)

CAN module provides functionalities for communication between electronic control units (ECUs) in a distributed network. It implements the CAN protocol and facilitates reliable data transmission in applications.

Responsibilities:

  • Sending and receiving CAN messages
  • Configuring message identifiers, message filters, and message buffering
  • Handling error conditions and managing error counters
  • Implementing bus-off recovery mechanisms.

Compiler 

The Compiler module integrates the microcontroller specific compiler toolchain into the development environment. It ensures compatibility between the source code and the target microcontroller architecture.

Responsibilities:

  • Translating high-level source code written in programming languages (e.g., C, C++) into machine-readable binary code.
  • Optimizing code size and performance for the target microcontroller.
  • Managing compiler options and settings for the project.

DIO (Digital Input/Output)

The DIO module provides an abstraction layer for digital input and output operations. It enables interfacing with external digital devices such as sensors, switches, LEDs, and relays.

Responsibilities:

  • Configuring GPIO pins for input or output mode.
  • Reading digital input states.
  • Writing digital output states.
  • Configuring interrupt generation on GPIO pins.

FLS (Flash Memory)

The FLS module provides functionalities for accessing non-volatile flash memory. It allows storing and retrieving data persistently in the microcontroller's flash memory.

Responsibilities:

  • Erasing flash memory sectors.
  • Writing data to flash memory.
  • Reading data from flash memory.
  • Performing flash memory wear-leveling and error handling.

GPT (General Purpose Timer)

The GPT module provides timer functionalities for time measurement, event counting, and pulse generation. It facilitates time-sensitive operations and timing-related tasks in embedded systems.

Responsibilities:

  • Configuring timer channels and modes.
  • Starting, stopping, and resetting timers.
  • Capturing and comparing timer values.
  • Generating timer interrupts.

IRQ (Interrupt Handling)

The IRQ module manages interrupt handling and prioritization in the microcontroller. It ensures timely and efficient handling of external and internal interrupts.

Responsibilities:

  • Configuring interrupt vectors and priorities.
  • Enabling and disabling interrupt sources.
  • Servicing interrupt requests.
  • Nesting and prioritizing interrupts.

McalLib (MCAL Library)

The McalLib module comprises a collection of pre-defined functions and macros that abstract hardware-specific functionalities of the microcontroller. It serves as a standardized interface for accessing hardware peripherals and features.

Responsibilities:

  • Providing APIs (Application Programming Interfaces) for accessing MCAL components.
  • Abstracting hardware-specific details.
  • Promoting code reusability and portability across different microcontroller platforms.

MCU (Microcontroller Unit)

The MCU module represents the core functionality of the microcontroller, including its CPU, memory, and various hardware peripherals. It acts as the central processing unit for executing application code and managing system resources.

Responsibilities:

  • Executing application code and firmware.
  • Managing CPU resources and execution flow.
  • Providing interfaces for accessing hardware peripherals.
  • Handling system initialization and startup routines.

PORT (Port Interface)

The PORT module provides an abstraction layer for managing port pins and their configurations. It facilitates interfacing with external devices through GPIO (General Purpose Input/Output) pins.

Responsibilities:

  • Configuring pin directions (input or output).
  • Configuring pin modes (e.g., push-pull, open-drain).
  • Configuring pin characteristics (e.g., pull-up, pull-down).
  • Providing APIs for reading and writing pin states.

ResourceM (Resource Management)

The ResourceM module manages system resources such as memory, timers, and interrupts. It ensures efficient allocation and utilization of resources to meet the requirements of the application.

Responsibilities:

  • Managing memory allocation and deallocation.
  • Managing timer and peripheral resource allocation.
  • Arbitrating access to shared resources.
  • Handling resource conflicts and contention.

WDG (Watchdog Timer)

The WDG module provides watchdog timer functionalities for monitoring system integrity and detecting software faults or failures. It helps in ensuring the reliability and robustness of embedded systems.

Responsibilities:

  • Configuring watchdog timer parameters (e.g., timeout period).
  • Starting and stopping the watchdog timer.
  • Resetting the microcontroller in case of watchdog timeout.
  • Handling watchdog timer interrupts.


Prerequisites

Before Proceeding, ensure the following prerequisites are met:

  • Installing Tresos and having the right modules and plugins
  • RTA-CAR with the desired microcontroller project imported

MCAL Configuration with RTA-CAR

The RTA-CAR ConfGen feature generates a generic configuration for the MCAL modules that are relevant to the existing System description. E.g., it shall generate a Can MCAL configuration if there is a CAN network description in the System. These configurations are generic and are not specific to any hardware. They also do not generate any MCAL code via the RTA-CAR. They only serve as references to the configurations present in related BSW modules. There is also a possibility to create some dummy MCAL config within the RTA-CAR project to fulfil the references for the supporting BSW modules.

These generated MCAL configurations within RTA-CAR can be used to configure the actual MCAL itself. For example, look at the below steps on how we can takeover the configuration within RTA-CAR to configure a CAN driver in a Tricore TC399 MCAL project.

Step 1. Please start by importing your projects to Tresos and RTA-CAR. 

Step 2. To get the MCAL modules in Tresos, double-click ApplicationECU.

Then all the modules available should be seen.


Step 3. Navigate by double-clicking on Can module under Can_17_McmCan

Step 4. In RTA-CAR please navigate to CanGeneral by Bsw Modules> Can> Can General

 

Step 5. Here, what we aim to do is, matching the settings from BSW editor to Tresos.  This was just an example of the CAN module. (This process could be applied to all the MCAL modules.)


  • No labels