Fee Driver Autosar

[Amice Golden]

RealTime Drivers (RTD) are a new and innovative drivers set supporting real-time software on AUTOSAR and non-AUTOSAR applications targeting Arm Cortex-M cores and ISO 26262 compliance for all software layers, providing full IP and features:

RTD also offers possible integration on the platform level of middleware (FATFS for EEP, FEE for FLS derived from MCAL) and stacks (LIN, NFC, TCIP). AUTOSAR functionalities (multicore, user mode) are also expanded to a non-AUTOSAR environment, previously only available for AUTOSAR.

Hello,

I want to configure autosar CAN driver using S32DS for S32K312, with 500 KB baudrate and Tx processing,Rx processing and busoff processing in interrupt mode. Can someone please explain what are the important parameters I need to configure and how will be the call flow from init to transmit and receive. Also how I can configure this 3 interrupts in Free RTOS.

Best Regards,

Ajay Yadav

For the flow from Init to Transmit, basically you need to understand CAN Driver, so follow AUTOSAR you will see the flow. Another short way to understand is, you find the example inside the driver, try to read the flow of code and write your own project.

AUTOSAR is a standardized automotive software architecture to establish the reuse of software within the automotive area. This is the baseline for enabling a transition from an ECU specific software development to an application oriented approach.

In addition to standardized modules AUTOSAR provides the possibility of complex driver for non-standardized hardware module. To efficiently exploit the hardware MCAL Complex Drivers are an essential component for hardware abstraction.

Are there AUTOSAR libraries available for the TMS570LC4357 for drivers such as CAN and SCI? What I am trying to understand is if the TI provided functions such as canTransmit and canGetData are AUTOSAR compliant and if not if there is a library available to use? I want to be able to write processor agnostic code that is AUTOSAR compliant.

This blog is part of our series on understanding AUTOSAR better. Our Automotive Product Engineering team, who has in-depth AUTOSAR expertise, will help us understand the essential components of the layered architecture of AUTOSAR.

MCAL is a software module that has direct access to all the on-chip MCU peripheral modules and external devices,which are mapped to memory. And it makes the upper software layers (Basic software layer, or BSW, Application Layer) independent of the MCU.

MCAL has a range of software modules designed to serve a particular purpose. Each Software Module (Driver) accesses the corresponding On-chip peripheral function. For instance, CAN Driver will ensure that CAN messages can be received and transmitted by the MCU.

For example, CAN BUS (MCAL) driver needs to be configured for in-vehicle networking application. Similarly, several drivers like LIN BUS, FlexRay, PWM, SPI, and Ethernet have to be configured based on specific requirements of an automotive application.

In such cases, this tool is not a part of Configuration Tool.AUTOSAR MCAL Driver DevelopmentDriver Static Code is the core MCAL driver that enables access to the on-chip peripherals of the microcontroller.The Driver Static Code file has an extension .c [dot c].

The AUTOSAR MCAL Driver Software Specification consists of every software requirement that needs to be met by the MCAL Driver. It consists of API details, parameters to be passed to the API and their return value.

Considering all these specifications, the Driver Static Code is developed.Source Code Testing and Validation of the AUTOSAR MCAL DriverThe validation of the MCAL Drivers is important to keep the bugs at bay. The validation process involves creating a test bench using an Integrated Development Environment (IDE) or a compiler.The PDF, Configuration Source File and the Driver Static Code are tested in this Test Environment.

One important point to be noted here is that AUTOSAR BSW is required for scheduling of the MCAL Driver verification. In its absence, stub files need to be created that replicates AUTOSAR BSW with similar APIs.

For instance, a separate test application needs to be written for CAN Driver to test if the ECU communication is happening uninterrupted. Similarly, test applications for memory functions, Input/Output, etc. also needs to be written.Conclusion

Different layers of AUTOSAR architecture are developed independent of each other and MCAL Drivers are no exceptions. This is how the required abstraction and thus the standardization is achieved.

MCAL Drivers also command a lot of importance, as they are the bridge between the upper layers of AUTOSAR architecture and the microcontroller unit.

Vaibhav is a digital-marketing professional with a deep-rooted interest in everything automotive. Regular collaborations with automotive tech guys keep him apprised of all new trends in the automotive industry. Besides digital marketing, Vaibhav is fond of writing and music.

More than 1 billion devices in over 100 million vehicles worldwide run embedded software developed by Elektrobit (EB). Much of this software was developed and verified using a standard V-model and the ASPICE process. While the devices work well, application software development was slowed by hand-coding and other labor-intensive manual tasks.

Our team set out to show that Model-Based Design could accelerate development of end-to-end, AUTOSAR Adaptive software systems. The project we chose was a prototype driver monitoring system that issues an alarm if the driver's eyes close and do not immediately reopen, indicating that the driver is falling asleep (Figure 1). To illustrate how efficiently we could develop the embedded software with Model-Based Design, we gave ourselves an ambitious deadline: design, implement, test, and verify the entire system in just three months. Using a traditional approach, the same project would have taken at least a year.

We began the project by defining requirements. High-level requirements included detecting closed eyes even when the driver is wearing glasses, keeping the false alarm rate below 3%, and sending alerts via Adaptive AUTOSAR to an EB human machine interface (HMI).

We generated MISRA-compliant C/C++ code for both the computer vision component and the filtering component. After compiling the computer vision component code, we deployed it directly to the first Raspberry Pi board. For the filtering component, we imported the generated code, including the ARXML files, into EB corbos Studio. We compiled the component in corbos Studio and deployed it as an AUTOSAR software component to the same Raspberry Pi. The computer vision and filtering components were linked via an interprocess communication (IPC) interface. A second Raspberry Pi board was used to run the EB corbos AdaptiveCore software base and EB GUIDE HMI to represent a vehicle instrument cluster.

Since the driver management system was a proof-of-concept prototype, there was no need to strictly follow ISO guidelines during development. In preparation for projects that do require ISO compliance, however, we used Model Advisor to check our models for requirements coverage and for compliance with ISO 26262, ISO 61508, and MISRA C:2012 standards.

Having demonstrated the ability of Model-Based Design to accelerate Adaptive AUTOSAR software development at EB, we are now working to expand its use and demonstrating it to automotive tier-1 suppliers and OEMs. Our team plans to incorporate security features and processor-in-the-loop testing into the workflow, and we are helping colleagues in other EB locations get started with Model-Based Design.

The SPI handler/driver provides the functionality and API for a monolithic SPI [Serial Peripheral Interface] handler/driver. This software module includes handling and driving functionalities. Main objectives of this monolithic SPI Handler/Driver are to take the best of each microcontroller features and to allow implementation optimization depending on static configuration to fit as much as possible to ECU needs.

The SPI handler/driver is part of the microcontroller abstraction layer (MCAL). It provides services for reading from and writing to devices connected via SPI busses. It also provides the required mechanism to configure the onchip SPI peripheral.

The SPI has a 4-wire synchronous serial interface. SPI Communication is enabled with a chip select wire (CS). SPI Communication is performed with a 3-wire interface consisting of wires for serial data Master-Output-Slave-Input (MOSI), serial data Master-Input-Slave-Output (MISO) and serial clock (CLK).

Depending on microcontrollers, the SPI peripheral could share registers with other peripherals. In this typical case, the SPI Handler/Driver has a relationship with MCU module for initialising and de-initialising those registers.

A Channel is a software exchange medium for data that are defined with the same criteria: Configuration Parameters, Number of Data elements with same size and data pointers (Source & Destination) or location.

A Job is composed of one or several Channels with the same Chip Select (is not released during the processing of Job). A Job is considered atomic and therefore cannot be interrupted by another Job. A Job has an assigned priority.

A Sequence is a number of consecutive Jobs but it can be rescheduled between Jobs using a priority mechanism. A Sequence communication is interruptible (by another Sequence communication) or not depending on a static configuration.

It shall be possible to define if the Chip Select handling is managed autonomously by the HW peripheral, without explicit chip select control by the driver, or the SPI driver shall drive the chip select lines explicitly as DIO.

If Chip Selects are done using microcontroller pins the SPI Handler/Driver has a relationship with PORT module. In this case, this specification assumes that these microcontroller pins are directly accessed by the SPI Handler/Driver module without using APIs of DIO module. Anyhow, the SPI depends on ECU hardware design and for that reason it may depend on other modules.

3a8082e126