jordi bigorra fibla micro-controller embedded software...
TRANSCRIPT
Jordi Bigorra Fibla
MICRO-CONTROLLER EMBEDDED SOFTWARE BENCHMARK PROCESS & TOOL
BACHELOR'S DEGREE FINAL PROJECT
Supervised by Prof. Enric Vidal Idiarte Company tutor Antoni Lacasta Sullà
Degree in Industrial Electronics and Automation Engineering
Tarragona
2015
Index
- 1 -
INDEX
SYMBOLS AND ABBREVIATIONS.............................................................................................................. - 3 -
1 INTRODUCTION .................................................................................................................................... - 5 -
2 OBJECTIVES .......................................................................................................................................... - 6 -
3 STATE OF THE ART ................................................................................................................................ - 6 -
4 BASIC CONCEPTS .................................................................................................................................. - 7 -
4.1 AUTOMOTIVE OPEN SYSTEM ARCHITECTURE (AUTOSAR) ........................................................................... - 7 -
4.1.2 Background ............................................................................................................................ - 7 -
4.1.2 Motivation and goals .............................................................................................................. - 9 -
4.1.3 Key features ......................................................................................................................... - 10 -
4.2 MICROCONTROLLER ABSTRACTION LAYER (MCAL) ................................................................................... - 12 -
5 BENCHMARKING ................................................................................................................................ - 17 -
6 MICROCONTROLLER ........................................................................................................................... - 18 -
6.1 CENTRAL PROCESSING UNIT ................................................................................................................ - 18 -
6.2 MEMORY ....................................................................................................................................... - 20 -
6.2.1 Random Access Memory (RAM) ............................................................................................ - 20 -
6.2.2 Read Only Memory (ROM) .................................................................................................... - 20 -
6.2.3Flash memory ........................................................................................................................ - 20 -
6.3 INPUT/OUTPUT PORTS ....................................................................................................................... - 21 -
6.3.1 Pulse Width Modulation (PWM) ............................................................................................ - 21 -
6.3.2 Input Capture Unit (ICU) ....................................................................................................... - 22 -
6.3.3 Digital Input Output (DIO) ..................................................................................................... - 22 -
6.3.4 PORT .................................................................................................................................... - 23 -
6.3.5 Analog to Digital Converter ................................................................................................... - 24 -
6.4 TIMERS AND COUNTERS...................................................................................................................... - 28 -
6.4.1 Watchdog............................................................................................................................. - 30 -
6.5 POWER SUPPLY CIRCUITRY .................................................................................................................. - 31 -
6.6 BUSES OF COMMUNICATION ................................................................................................................ - 31 -
6.6.1 Local Interconnect Network .................................................................................................. - 31 -
6.6.2 Serial Peripheral Interface ..................................................................................................... - 32 -
6.6.3 Controller Area Network (CAN) ............................................................................................. - 35 -
7 DEVELOPMENT OF THE PROJECT ........................................................................................................ - 38 -
7.1 V MODEL ........................................................................................................................................ - 38 -
7.2 TRAINING PERIOD ............................................................................................................................. - 40 -
7.3 DESIGN .......................................................................................................................................... - 41 -
7.4 IMPLEMENTATION ............................................................................................................................ - 44 -
7.4.1 Source Code .......................................................................................................................... - 46 -
7.5 INTEGRATION .................................................................................................................................. - 71 -
7.5.1 Mandatory configuration ...................................................................................................... - 72 -
7.5.2 Independent configuration .................................................................................................... - 76 -
7.5.3 Compiler and MCAL .............................................................................................................. - 81 -
7.6 SOFTWARE VALIDATION...................................................................................................................... - 84 -
7.7 EVALUATION ................................................................................................................................... - 86 -
Index
- 2 -
7.8 DELIVERY PHASE ............................................................................................................................... - 93 -
7.9 ANALYSIS OF THE RESULTS ................................................................................................................... - 94 -
8 CONCLUSIONS .................................................................................................................................... - 95 -
9 BIBLIOGRAPHY ................................................................................................................................... - 97 -
Symbols and abbreviations
- 3 -
Symbols and abbreviations
AUTOSAR AUTomotive Open System Architecture
OEM Original Equipment Manufacturers
MCAL Microcontroller Abstraction Layer
CPU Central Processing Unit
MCU MicroController Unit
OS Operating System
RTE Runtime Environment
GPT General Purpose Timer
WDG Watchdog
DEM Diagnostic Event Manager
FLS Flash memory
FEE Flash Electrically Erasable Programmable Read-Only
SPI Serial Peripheral Interface
LIN Local Interconnect Network
CAN Control Area Network
ICU Input Capture Unit
PWM Pulse Width Modulation
ADC Analog to Digital Converter
DIO Digital Input Output
ROM Read Only Memory
RAM Random Access Memory
ALU Arithmetical Logical Unit
CU Control Unit
DAC Digital to Analog Converter
ID Identifier
Symbols and abbreviations
- 4 -
MOSI Master Output Slave Input
MISO Master Input Slave Output
CS Chip Select
SCK Serial Clock
CRC Cyclic Redundancy Check
ACK Acknowledgement
PLL Phase-locked loop
VFB Virtual Function Bus
Introduction
- 5 -
1 Introduction
The traditional way to evaluate the computing power of microcontrollers has been to design
a piece of software, that executed on several devices, provides the metrics that allow an
objective comparison.
In a first approach, the benchmarking software can be restricted to the CPU of the
microcontroller. The differences among different CPU’s are “hidden” under the compiler. A
single piece of ANSI C/C++ source code can be compiled for any CPU, and executed on it.
During the execution, the tester can collect data about the resources used and the time
required for the execution.
Even the most powerful CPU can get saturated with IRQ’s and with the execution of
complex low level drivers, if the peripherals need a lot of software management. On the
other hand, an MCU equipped with smarter peripherals but a slower CPU, can perform better
and also improve the current consumption.
The problem of involving the peripherals in a benchmark is that the special function registers
of every microcontroller are unique. Even if Lear defined an API, the implementation of this
low level driver layer would rely on the microcontroller manufacturer. The implementation
of a software library just for the execution of a benchmark, is not economically feasible, and
therefore the benchmark of microcontrollers has traditionally not included the peripherals.
AUTOSAR provides OEM’s, Tier1’s and MCU manufacturer’s with a common and
independent interface between the microcontroller and the rest of the software. AUTOSAR’s
MCAL is the third level of the platform where MCU’s can be completely evaluated. Moving
the benchmark software from the CPU to above the MCAL, provides a wider view of the
performance of the MCU.
Objectives and state of the art
- 6 -
2 Objectives
From an early time this project has had three clear objectives, each one related to each other.
Firstly, designing and developing an embedded software benchmark to evaluate the platform
composed of microcontroller, compiler and MCAL. Secondly, participating in the process
and tools definition for benchmarking of embedded software suppliers. Finally, analysing
and understanding results from different microcontrollers and suppliers.
3 State of the art
During the last decade there has been a steady growth in automotive electronic systems. The
future prediction is that most of the current vehicle electronic systems will be enhanced and
expanded. So, in the next years cars will offer more facilities based on the technology
development.
Microcontrollers have a key job to manage electronic systems. Due to the creation and
development of the AUTomotive Open System Architecture (AUTOSAR) and the
Microcontroller Abstraction Layer, the automotive software has changed its operating.
Nowadays, almost all the projects shall combine microcontrollers, compilers and
AUTOSAR MCAL, assuring a good performance of the platform.
Basic concepts
- 7 -
4 Basic concepts
4.1 Automotive Open System Architecture (AUTOSAR)
4.1.2 Background
The AUTomotive Open System Architecture (AUTOSAR) partnership is an alliance of
Original Equipment Manufacturers (OEM), which are responsible to make a part or
subsystem used in another company end’s product, and Tier 1 automotive suppliers, which
are responsible to develop software and hardware for OEM’s. They both work together to
develop and establish a de-facto open industry standard for automotive electrical/electronic
(E/E) architecture which will serve as basic infrastructure for the management of functions
within both future applications and standard software modules.
Figure 4.1 AUTOSAR logo
Initial discussions on the common challenge and objectives were held by BMW, Bosch,
Continental, DaimlerChrysler and Volkswagen in August,2002 and the partners were joined
soon afterwards by Siemens VDO.
A joint technical team was set up in November, 2002, to establish the technical
implementation strategy. The partnership between the Core Partners was formally signed off
in July, 2003. Ford Motor Company joined as a Core Partner in November, 2003. Peugeot
Citroën Automobiles S.A. and Toyota Motor Corporation joined as Core Partners in
December, 2003. General Motors became Core Partner in November, 2004.
In February 2008 Siemens VDO became part of Continental. Since this Siemens VDO is no
longer a self-contained Core Partner of AUTOSAR.
The AUTOSAR scope includes all vehicle domains. The AUTOSAR standard will serve as
a platform upon which future vehicle applications will be implemented and will also serve
to minimize the current barriers between functional domains. It will, therefore, be possible
to map functions and networks of the different control nodes in the system, almost
independently from the associated hardware.
Basic concepts
- 8 -
The partnership actively involves third parties in its development by means of various
agreements, which will have specific roles and responsibilities associated with them. Each
tier of the partnership has specific rights and duties.
The members of the partnership are:
Original equipment manufacturers (OEM): vehicle manufacturers
Tier 1 group: software and hardware developers, which are suppliers of OEM’s.
Tier 2 group: standard software, tools and services and semiconductors developers,
which are suppliers of Tier 1 group.
Figure 4.2 Groups of the automotive area
Basic concepts
- 9 -
4.1.2 Motivation and goals
The main common objective is creating a development base for industry collaboration on
basic functions while providing a platform which continues to encourage competition on
innovative functions. The AUTOSAR standard will be used as the platform upon which
future vehicle applications will be implemented and will also be really useful to minimize
the current barriers between functional domains.
Motivation:
Management of E/E complexity associated with growth in functional scope
Flexibility for product modification, upgrade and update
Scalability of solutions within and across product lines
Improved quality and reliability of E/E systems
Goals:
Fulfilment of future vehicle requirements, such as, availability and safety, software
updates and maintainability
Increased scalability and flexibility to integrate and transfer functions
Higher penetration of "Commercial off the Shelf" SW and HW components across
product lines
Improved containment of product and process complexity and risk
Cost optimization of scalable systems
Implementation and standardization of basic system functions as an OEM wide
"Standard Core" solution
Scalability to different vehicle and platform variants
Transferability of functions throughout network
Integration of functional modules from multiple suppliers
Consideration of availability and safety requirements
Redundancy activation
Maintainability throughout the whole "Product Life Cycle"
Increased use of "Commercial off the shelf hardware"
Software updates and upgrades over vehicle lifetime
Basic concepts
- 10 -
4.1.3 Key features
As for modularity and configurability:
Definition of a layered basic software architecture for automotive electronic control
units in order to encapsulate the HW dependencies
Consideration of HW dependent and HW independent SW modules
Enable the integration of basic SW modules provided by different suppliers to
increase the functional reuse
Enable the transferability of functional SW-components within a particular E/E-
system at least at the final software linking process
Resource optimized configuration of the SW infrastructure of each ECU depending
on the function deployment
Scalability of the E/E-system across the entire range of vehicle product lines
As for standardized interfaces
Standardization of different APIs to separate the AUTOSAR SW layers
Facilitate encapsulation of functional SW-components
Definition of the data types of SW-components
Standardization of interfaces of basic SW modules of the SW infrastructure
As for Runtime Environment (RTE)
Provision of inter- and intra-ECU communication across all nodes of a vehicle
network
Located between the functional SW-components and the basic SW-modules
All entities connected to the AUTOSAR RTE must comply with the AUTOSAR
specification
Enables the easy integration of customer specific functional SW-modules
As for acceptance tests:
Standardization of test case specifications to test a basic software and RTE
implementation at application and bus level.
Basic concepts
- 11 -
To achieve the technical goals, modularity, scalability, transferability and re-usability of
functions, AUTOSAR provides a common software infrastructure for automotive
systems of all vehicle domains based on standardized interfaces for the different layers
as shown in the picture below.
Figure 4.3 AUTOSAR diagram
Modularity of automotive software elements enables tailoring of software according to the
individual requirements of electronic control units and their tasks
Scalability of functions ensures the adaptability of common software modules to different
vehicle platforms to prohibit proliferation of software with similar functionality.
Transferability of functions optimizes the use of resources available throughout a vehicle´s
electronic architecture.
Re-usability of functions helps to improve product quality and reliability and to reinforce
corporate brand image across product lines.
Basic concepts
- 12 -
4.2 Microcontroller Abstraction Layer (MCAL)
To avoid direct access to microcontroller registers from higher level software, the access to
the hardware is routed through the Microcontroller Abstraction Layer (MCAL).
MCAL is a hardware specific layer that ensures a standard interface to the components of
the Basic Software. It manages the microcontroller peripherals and provides the components
of the Basic Software, being independent on the microcontroller. MCAL is responsible to
implement notification to mechanisms to support the distribution of commands, responses
and information to different processes. Moreover, MCAL makes the upper software layer
independent of the microcontroller unit (MCU).
Figure 4.4 MCAL block diagram
The red area is the microcontroller abstraction, the MCAL.
The green area is the Electronic Control Unit (ECU) abstraction layer, which
provides interfaces to the drivers in the MCAL and drivers for external devices.
Microcontroller
Micro-contro-
ller drivers
Memory drivers
Comm. drivers
I/O drivers
Complex drivers
I/O hardware abstracti-
on
Comm. hardware abstracti-
on
Memory hardware abstracti-
on
Onboard hardware abstracti-
on
Memory services
Comm. services
AUTOSAR Runtime Environment (RTE)
Application Layer
Basic concepts
- 13 -
The purple area is the Services layer, which provides basic services for application
and basic software modules: OS functionalities, vehicle network communication and
management services, memory and diagnostic services and ECU state management.
The orange area is the Runtime Environment (RTE), which provides communication
services to the AUTOSAR software components and/or sensor/actuator components.
It allows the AUTOSAR software components to be independent.
The grey area is the Application Layer, which is outside of the scope of the
AUTOSAR standard.
AUTOSAR provides OEM’s, Tier1’s and MCU manufacturer’s with a common and
independent interface between the microcontroller and the rest of the software. AUTOSAR’s
MCAL is the third part of the platform where MCU’s can be completely evaluated. Moving
the benchmark software from the CPU to above the MCAL, provides a wider view of the
performance of the MCU.
Description of the MCAL software module until the AUTOSAR standard specification and
auxiliary material version 4.2, released in March 2015:
Microcontroller drivers
GPT driver General Purpose Timer driver
Device driver using on-chip MCU timer
Initializes GPT and performs timer count
WDG driver Watchdog driver
On-chip WDG device driver
Initializes WDG and performs WDG mode
settings
MCU driver Micro Controller Unit
Device driver that performs MCU settings
Initializes clocks and performs power
mode settings
BASE driver Base driver
It contains common files and definitions
needed by the MCAL. It establishes a
dependency for all other MCAL modules
Basic concepts
- 14 -
DEM driver Diagnostic Event Manager driver.
Responsible for processing and storing
errors and associated data.
ECU State
Manager driver
Electronic Control Unit State Manager
driver.
Manages common aspects of ECU states.
Watchdog If driver Watchdog Interface driver.
In case of more than one watchdog driver
being used, this driver allows the watchdog
manager to select the correct watchdog
driver.
Memory drivers
FLS driver Flash driver
Initializes Flash and reads/writes/erases to
Flash memory
FEE driver Flash EEPROM driver
Flash EEPROM emulation driver
Initializes FEE and reads/writes to FEE
memory
Flash test driver Flash test driver
The driver is intended to be integrated in
the overall safety concept.
Communication drivers
SPI
handler/driver
Serial Peripheral Interface
handler/driver
Device driver for on-chip clock serial
function
Initializes SPI, performs SPI input/output
and SPI I/O buffer settings
LIN driver Local Interconnected Network driver
Basic concepts
- 15 -
Initializes LIN, performs LIN input/output
CAN driver Control Area Network driver
Initializes CAN, performs CAN I/O
CANInterface
driver
Control Area Network Interface
Represents the interface to the services of
the CAN driver for the upper
communication layers.
Provides a unique interface to manage
different CAN hardware devices types.
FlexRay driver FlexRay driver
Initializes FlexRay, performs FlexRay I/O
Ethernet driver Ethernet driver
Initializes Ethernet driver, performs
Ethernet driver input/output
I/O drivers
ICU driver Input Capture Unit driver
Device driver using on-chip MCU timer
Initializes ICU, measures PWM
waveforms, etc.
PWM driver Pulse Width Modulation driver
Device driver using on-chip MCU timer
Initializes PWM, outputs PWM
waveforms
ADC driver Analog to Digital Converter driver
Device driver using for on-chip ADC
Initializes ADC, starts/stops AD
conversion, sets AD conversion result
buffer, reads AD conversion results, etc.
DIO driver Digital Input Output driver
MCU port device driver
Performs port signal input/output
Basic concepts
- 16 -
PORT driver PORT driver
MCU port device driver
Performs MCU pin settings (I/O, shared
functions)
The two pictures below are examples of the MCAL’s representation performed by two
different Tier 2 companies, Renesas and Freescale:
Renesas MCAL Block diagram
Figure 4.5 Renesas MCAL block diagram
Freescale MCAL block diagram:
Figure 4.6 Freescale MCAL block diagram
Benchmarking
- 17 -
5 Benchmarking
Benchmarking is a process of comparing one’s business processes and performance metrics
to industry bests or best practices from other companies. The dimensions typically measured
are time, quality and cost. The performance is measured by using a specific indicator
resulting in a metric of performance which is compared to others. Benchmarking usually
occurs across in all types of companies such as public, private as well as industries.
Benchmarking may belong to different sectors, but the benchmark developed in this project
is integrated into the automotive sector. This project works from the point of view of a
company that buys a massive quantity of microcontrollers each year. Then, the
benchmarking is focused on the microcontrollers provided by different suppliers, being them
analysed to make a good decision. Furthermore, the compiler and the MCAL are also
analysed, so all the three elements have to assure both a good individual and collective
performance. Understanding and running standard benchmarks can give designers greater
insight into and control over their applications. The metrics obtained from the process and
evaluated by the company are the memory map and the time of execution of the code.
In this project benchmarking is not applied in an internal product but through all the
microcontrollers likely to be bought by Lear. The main purpose is to gather the data
necessary to make the right business decision.
Any benchmarking has some common phases:
Determining the benchmark focus: microcontrollers
Planning and research: development of the project
Gathering data: obtained from the evaluation performed by Lear’s engineers as well
as supplier’s engineers.
Analysis: after having gathered the data, the results are analysed.
Microcontroller
- 18 -
6 Microcontroller
A microcontroller (MCU) is a small computer on a single integrated circuit containing a
processor core, memory and programmable input and output peripherals. Microcontrollers
are embedded inside some other device, usually a consumer product, so as to control the
features and actions of the device. They are dedicated to one task and to run a single specific
program, which is stored in read only memory (ROM) and does not usually changes.
Figure 6.1 Microcontroller
As for their applications, powerful and carefully chosen electronics embedded in the
microcontrollers can control various processes and devices such as industrial automation,
electric current or engine performance.
Most microcontrollers are composed of different elements, which are explained in the
following sections.
The benchmark developed evaluates the MCU driver.
6.1 Central Processing Unit
The Central Processing Unit (CPU) is the unit that monitors and controls all processes within
the microcontroller. It consists of several smaller subunits, being the most important the
following:
Arithmetical Logical Unit (ALU): performs mathematical and logical operations
Control Unit (CU): manages the components of the computer and does the task to
read and interpret instructions and transform them into signals to activate other parts
of the computer.
Microcontroller
- 19 -
Internal registers: an electronic circuit which can store the state of one or more bytes.
The accumulator or the program counter are examples of internal registers:
o Accumulator: it is responsible to store all data upon which some operations
should be executed and stores the results ready for use.
o Program counter: it is the engine running the program and points to memory
addresses that contain the next instruction to be executed. The value of the
program counter can be changed at any moment to jump to a new memory
location. This happens when branches and subroutines can be executed.
The benchmark developed includes a CPU benchmark, which is a collection of intensive
computing routines designed to extract metrics about the efficiency of the CPU of a given
microcontroller.
Figure 6.2 Microcontroller’s basic structure
The evaluation is performed by using the MCU driver, which provides services for basic
microcontroller initialization, power down functionality, reset and microcontroller specific
functions required by other MCAL software modules. The initialization services allow a
flexible and application related MCU initialization in addition to the start-up code, which is
very MCU specific.
Microcontroller
- 20 -
6.2 Memory
Microcontrollers come with several different types of memory, being the amount of them
different depending on the device.
6.2.1 Random Access Memory (RAM)
RAM is a form of computer data storage. A random-access memory device allows data items
to be read and written in roughly the same amount of time regardless of the order in which
data items are accessed. RAM is volatile, which means that the contents of the memory are
lost when the power is shut off. RAM memory is more quickly than Flash memory but
microcontrollers do not have very much of them built into them because of its high cost.
The RAM memory is evaluated in the benchmark.
6.2.2 Read Only Memory (ROM)
ROM is a memory typically used to store programs and data that does not change over the
time and that have to be read many times. Many microcontrollers have lot of ROM.
6.2.3Flash memory
Flash is a non-volatile memory that can be electrically erased and reprogrammed in a very
efficient way.
The Flash memory is evaluated in the benchmark by using the Flash driver. It
provides services for reading, writing and erasing flash memory and a
configuration interface for setting, resetting the write, erase protection if
supported by the underlying hardware. A driver for an internal flash memory
accesses the microcontroller hardware directly and is located in the
microcontroller abstraction layer. An external flash memory is usually connected
via the microcontroller’s data, address busses. Therefore, the flash driver uses the
handlers for those busses to access the external flash memory device. The driver
for an external flash memory device is located in the ECU abstraction layer.
Microcontroller
- 21 -
6.3 Input/output ports
In order to make the microcontroller useful, it is necessary to connect it to peripheral devices.
Each microcontroller has one or more registers, the ports, connected to the microcontroller
pins. They are called input/output because they can change their functionality depending on
the necessities.
6.3.1 Pulse Width Modulation (PWM)
A pulse width modulation, PWM, is a technique used to encode a message into a pulsing
signal. Although this modulation technique can be used to encode information for
transmission, its main use is allowing the control of the power supplied to electrical devices.
The term duty cycle describes the proportion of on time to the regular interval or period time.
Figure 6.3 PWM signal in two different polarities
MCAL provides a PWM driver, which is evaluated by the benchmark. This driver provides
functions for initialization and control of the microcontroller internal PWM stage. The PWM
module generates pulses with variable pulse width. It allows the selection of the duty cycle
and the signal period time.
Microcontroller
- 22 -
6.3.2 Input Capture Unit (ICU)
The input capture unit, ICU, is a peripheral that has the purpose to deal with input signals in
embedded systems, recording a timestamp in memory when an input signal is received. The
unit is an integral part of one or more of the microcontroller’s timers.
The MCAL provides an ICU driver to manage the peripheral which is evaluated in the
benchmark. This driver is a module using the ICU for demodulation of a PWM signal,
counting pulses, measuring the frequency and duty cycle and generating simple and wakeup
interrupts.
The ICU driver provides services for:
Signal edge notification
Controlling wakeup interrupts
Periodic signal time measurement
Edge time stamping, usable for the acquisition of non-periodic signals
Edge counting
Figure 6.4 ICU operating
6.3.3 Digital Input Output (DIO)
The MCAL provides a DIO driver, which provides services for reading and writing to/from
DIO channels (pins), DIO ports and DIO channel groups. The behaviour of those services is
synchronous. This module works on pins and ports which are configured by the PORT driver
for this purpose.
Microcontroller
- 23 -
6.3.4 PORT
The PORT driver provides the service for initializing the whole PORT structure of the
microcontroller. Many ports and port pins can be assigned to various functionalities such as
ADC, SPI, PWM, general purpose I/O and CAN.
For this reason, there shall be an overall configuration and initialization of this port structure.
The configuration and mode of these port pins is microcontroller and ECU dependent.
This PORT driver module shall complete the overall configuration and initialisation of the
port structure.
The diagram below identifies the PORT and DIO driver functions and the structure of the
PORT and DIO drivers within the MCAL software layer.
Figure 6.5 PORT and DIO drivers inside the MCAL
2
1
3
Microcontroller
- 24 -
The first box represents the area of the MCAL software, the second one the registers of the
microcontroller and the third the hardware of the device. To make it clear, imagine writing
the level of a LED. In the first area, the PORT and DIO drivers provide the MCAL functions
to store the information about the pin direction, input or output, its mode of operation as well
as the action to be performed, writing. The second area would write this information in the
microcontroller’s registers. Finally, the third area would switch on the particular LED.
6.3.5 Analog to Digital Converter
The analog to digital converter is an electronic integrated circuit that converts a continuous
physical quantity, usually voltage, to a digital number that represents the quantity’s
amplitude. In other words, a continuously variable (analog) signal is changed, without
altering its essential content, into a multi-level (digital) signal.
The resolution of the converter indicates the number of discrete values it can produce over
the range of analog values. The resolution determines the magnitude of the quantization of
error inherent in the conversion, and therefore determines the maximum possible average
signal to noise for an ideal ADC.
The values are stored electronically in binary form, so the resolution is usually expressed in
bits and the number of discrete values available is assumed to be power of two. Most
converters sample with 6 to 24 bits of resolution, being the converters of 8, 10, 12 and 16 bit
the most common in microcontrollers.
There are many types of ADC, being the following the most used:
Digital ramp ADC (ramp compare)
A common manner to do that is applying the analog voltage to one terminal of a
comparator and triggering a binary counter which drives a Digital to Analog
Converter (DAC). The output of the DAC is applied to the other terminal of the
comparator.
Since the output of the DAC increases with the counter, it will trigger the comparator
at some point when its voltage exceeds the analog input. The transition of the
comparator stops the binary counter, which at that point holds the digital value
corresponding to the analog voltage.
Microcontroller
- 25 -
Figure 6.6 Digital ramp ADC
Successive approximation ADC
The successive approximation ADC is much faster than the digital ramp ADC
because it uses digital logic to converge on the value closest to the input voltage. At
each successive step, the converter compares the input voltage to the output of an
internal DAC which might represent the midpoint of a selected voltage range. Also
at each step, the approximation is stored in a successive approximation register. The
steps are continued until the desired resolution is reached.
Figure 6.6 4-bit SAC
Microcontroller
- 26 -
Flash ADC
The direct-conversion ADC is the fastest way to convert an analog signal to a digital
signal. This type of ADC has a bank of comparators sampling the input signal in
parallel. The comparator bank feeds a logic circuit that generates a code for each
voltage range. It usually has only 8 bits of resolution of fewer, since the number of
comparators needed is 2N-1, being N the number of comparators, which requires a
large and expensive circuit. This type of ADC has the great disadvantage that the
price is expensive since many comparators are required.
Figure 6.6 3-bit Flash ADC
Sigma delta ADC
Sigma Delta ADC are used predominately in lower speed applications requiring a
trade-off of speed for resolution by oversampling, followed by filtering to reduce
noise. 24 bit Sigma Delta converters are common in Audio designs, instrumentation
and Sonar.
Microcontroller
- 27 -
ADC type comparison:
The AUTOSAR driver initializes and controls the internal Analog to Digital Converter
Unit(s) of the microcontroller. It provides services to start and stop a conversion respectively
to enable and disable the trigger source for a conversion. Furthermore it provides services to
enable and disable a notification mechanism and routines to query the status and result of a
conversion.
The ADC module works on so called ADC Channel Groups, which are built from so called
ADC Channel. An ADC Channel Group combines an analog input pin, the needed ADC
circuitry itself and conversion result register into an entity that can be individually controlled
and accessed via the ADC module.
Type Speed (relative) Cost (relative)
Dual slope Slow Med
Flash Very fast High
Successive approximation Medium-Fast Low
Sigma-delta Slow Low
Microcontroller
- 28 -
6.4 Timers and counters
The task of timers and counters in a microcontroller is counting synchronously with the
microcontroller clock. The number of counts they can reach depends on the number of bits
of the timer/counter.
Number of bits Counts
8 0…255
16 0…65535
32 0…4294967295
Sometimes, due to timer’s limitations or the purpose of an application, it is necessary to
count at different frequency. When this occurs, microcontroller offers a feature called
prescaling. For example, with a 64 MHz CPU and a prescaler configured at 32, when the
system clock has reached 64000000 counts the timer’s value is 2000000.
The MCAL provides a driver called General Purpose Timer, which initializes and controls
the internal GPT of the microcontroller, which has a fixed bit up-counter. The GPT driver is
evaluated in the benchmark.
The General Purpose Timer driver provides services and configuration parameters for:
Starting and stopping hardware timers
Getting timer values
Controlling time triggered interrupt notifications
Controlling time triggered wakeup interrupts, if supported by hardware.
The unit of the timer are ticks, a neutral unit. The tick duration of a timer channel depends
on channel specific settings as well as on system clock and settings of the clock tree
controlled by the MCU module. Working with ticks allows for measuring different devices
under the same conditions.
Microcontroller
- 29 -
The configured timer can work in two different ways:
One shot mode: when the timer reaches the target time, the timer shall stop
automatically and maintain its timer value unchanged until it is restarted.
Figure 6.7 GPT operating in one shot mode
Continuous mode: if the timer reaches the target time, the timer shall continue
running with the value 0 at next timer tick, So, the time interval of the recurrence is
target time + 1. In addition, if supported by hardware, it shall be possible to realize a
free running timer, which means that a timer rolls over automatically by hardware if
the target time is set to the maximum value the timer is able to count.
Figure 6.8 GPT operating in continuous mode
Microcontroller
- 30 -
6.4.1 Watchdog
A watchdog timer (WDT) is a timer used to detect and recover from computer malfunctions,
in other words, to avoid a system collapse. During normal operation, the computer restarts
the watchdog timer to prevent it from timing out. When a time out occurs, a reset is
performed.
The Watchdog (WDG) driver provides services for initialization, changing the operation
mode and setting the trigger condition (timeout). An internal watchdog driver belongs to the
MCAL, whereas an external watchdog driver belongs to the onboard device abstraction
layer.
The operating of the WDG is based in two different timers. Each timer is provided by two
different drivers: GPT and WDG. Each timer has a different timeout, being the one of the
GPT the shortest. Once timer of the GPT ends, the one of the WDG is refreshed. So, if the
program works well, the timeout of the WDG will never occur. In case something happens
and the timeout of the WDG occurs, the system will perform a reset since the program
execution is not ok.
The picture below shows the temporary evolution of the WDG.
Figure 6.8 GPT evolution
Microcontroller
- 31 -
Figure 6.9 GPT evolution
6.5 Power supply circuitry
The power supply circuitry provides electrical energy to all the microcontroller units.
6.6 Buses of communication
In this project three different buses of communication have been used and evaluated: the
Local Interconnect Network (LIN), the Serial Peripheral Interface (SPI) and the Control Area
Network (CAN). It is necessary to point out that CAN has had a key task in the project as
later will be explained.
6.6.1 Local Interconnect Network
The Local Interconnect Network (LIN) is a serial network protocol used for communication
between components in vehicles. It was developed to create a standard for low-cost, low-
end multiplexed communication in automotive networks. LIN provides cost-efficient
communication in applications where the bandwidth and versatility of the Control Area
Network (CAN) are not required. The area in which LIN is used is body electronics.
LIN is a broadcast serial network that uses a master/slave approach that comprises a master
and up to 16 slaves. All messages are initiated by the master with at most one slave replying
to a given message identifier. The master node can also act as slave by replying to its own
messages. The sequencing of message frames is fixed in a schedule and controlled by the
master.
Microcontroller
- 32 -
Figure 6.10 LIN message frame
The message header consists of a break used to identify the start of the frame and the sync
field used by the slave node for clock synchronization. The identifier consists of a 6-bit
message ID and 2-bit parity field. Upon reception and interpretation of the identifier, one
slave begins the response of the message, which consists of one to eight bytes of data and a
checksum of 8 bits.
The MCAL provides a driver which is evaluated in the benchmark. This driver performs the
hardware access and offers a hardware independent API to upper layer. It can support more
than one channel, so LIN driver can handle one or more channels as long as they are
belonging to the same LIN hardware unit.
6.6.2 Serial Peripheral Interface
The Serial Peripheral Interface is a synchronous serial communication interface specification
used for short distance communication. Two or more serial devices are connected to each
other in full-duplex mode, which means that master can send data to slave and slave can also
send the data to the master at the same time. The devices connected to each other are either
Master or Slave. It is not usual to have more than one master.
The master and slave are connected by means of four wires. Each of these wires carries a
particular signal defined by the SPI bus protocol. These four signals are:
Master Output Slave Input (MOSI): this is the signal which goes from the output of
the master to the input of the Slave.
Master Input Slave Output (MISO): this is the signal which goes from the output of
the slave to the input of the master.
Serial Clock (SCK/SCLK): this is the output of the clock generator for master and
clock input for slave.
Slave Select (SS): this is discusses in the next section of this post.
Microcontroller
- 33 -
The following diagram explains the hardware setup for a one master- one slave
configuration:
Figure 6.10 Hardware setup
What differs SPI from other serial ports is that it is synchronous, which means that it uses
separate lines for data and a clock that keeps both sides in perfect sync. The clock is an
oscillating signal that tells the receiver exactly when to sample the bits on the data line, either
the rising or the falling edge of the clock signal. When that edge is detected by the receiver,
it immediately looks at the data line to read the next bit.
The data transfer operation is the following:
The initial state, before any clock pulse arrives
Figure 6.11 Initial state
Microcontroller
- 34 -
The output of the master shift register is connected to the input of the slave shift
register, representing the MOSI, and the output of the slave shift register is connected
to the input of the master shift register, representing the MISO. As it was said before,
the clock is used to synchronize the data transfer.
As soon as a clock pulse arrives, the shift registers come into operation and the data
in the registers is shifted by one bit towards the right as it follows:
Figure 6.12 Data register shift
Since the master and he slave are connected forming a ring buffer, the evicted bit
occupies the MSB position of the other device. So, bit A0 gets evicted from master
occupying the MSB position of the slave and the bit B0 gets evicted from the slave
occupying the MSB in master shift register. The process is repeated until all the bits
are transmitted having the following state:
Figure 6.13 Final state after transmission
Microcontroller
- 35 -
As showed in the images above both master and slave place the data to be transmitted in
their shift registers before the communication starts. Master generates clock pulses, and after
each one, one bit of information is transferred from master to slave and vice-versa. The full-
duplex communication is proved because, at the end, master and slave have exchanged their
data.
MCAL provides a driver of SPI, which is evaluated in the benchmark. This driver provides
services for reading from and writing to devices connected via SPI busses. It provides access
to SPI communication to several users and the required mechanism to configure the onchip
SPI peripheral. The general behaviour of the driver can be asynchronous or synchronous
according to the level of functionality selected.
6.6.3 Controller Area Network (CAN)
The Controller Area Network (CAN) is a vehicle bus standard designed by Bosch to allow
the communication of microcontrollers and devices with each other in applications without
a host computer.
CAN is mainly used for embedded applications in automotive applications and provides:
Multi master capability, which allows the design of distributed and redundant
systems
Broadcast communicaction, which reduces bandwith requirements
Sophisticated error detection functions, which increases communication reliability.
Unique fault confinement, which guarantees network-wide data consistency.
Reduction of the quantity of wires
Reliable communication between Engine Control Units (ECUs)
Message priority
Error detection
CAN communication is based in frames that send the information. The following image
shows the base frame format for a data frame:
Microcontroller
- 36 -
Figure 6.14 CAN data frame
Start of frame denotes the start of frame transmission. It has a length of 1 bit.
The message identifier is unique for each frame and also represents the message
priority. It has a length of 11 bits.
Remote Transmission Request (RTR) has a dominant value when a frame is
transmitted. In CAN bus 0 is dominant and 1 recessive. It has a length of 1 bit.
The control field has a length of 6 bytes and contains three diferent fields:
o Identifier extension must be dominant. It has a length of 1 bit.
o Reserved bit, which must be dominant. It has a length of 1 bit
o Data length code represents the number of bytes of data, which can vary from
0 to 8 bytes. It has length of 4 bits.
The data field contains the data to be transmitted and has a length that can vary from
0 to 8 bytes.
The Cyclic Redundancy Check (CRC) field has a length of 16 bits and includes two
different fields inside itself:
o CRC field performs the error detection task and is 15 bits length.
o CRC delimiter must be recessive and is 1 bit length.
The Acknowledgement (ACK) field includes two different fields inside itself and has
a length of 2 bits:
o ACK slot. A transmitter sends a recessive value and a receiver asserts a
dominant value.
o ACK delimiter must be recessive
Microcontroller
- 37 -
The End of Frame (EOF) field sends 7 consecutive recessive values to end the frame.
When the format of the frame is extended, the frame includes a second identifier of 18 bits
length.
The MCAL provides a CAN driver, which is evaluated in the benchmark. This driver
provides services for initialising transmissions and calls the callback functions of the CanIf
module for notifying events, independently from the hardware. Moreover, it provides
services to control the behaviour and state of the CAN controllers to the same CAN hardware
unit.
Development
- 38 -
7 Development of the project
7.1 V model
In Lear Corporation, most software projects follow the V-model for software development
processes.
Figure 7.1 V model
The various phases of the V-model are the following:
Requirements such as Business Requirements Specifications (BRS) and System
Requirements Specifications (SRS). In this model, before starting the development a
system plan is created.
In this particular project, the requirement is develop an embedded software to
evaluate the platform composed of microcontroller, compiler and MCAL drivers.
The High Level Design (HLD) focuses on the system architecture and design. This
provides an overview of the solution, platform, system, product and process. An
integration test plan is created in this phase as well in order to test the pieces of the
software systems ability to work together.
The Low Level Design (LLD) is the phase in which the software components are
designed. It defines the actual logic for each and every component of the system.
Development
- 39 -
The implementation is where the coding takes place. Once coding is ready, the path
of executions continues up the right side where the test plans developed earlier are
now put to use.
The advantages of the V-model are multiple:
Simple and easy model to follow
All the testing activities happen well before coding, what represents a great save of
time.
Proactive defect tracking. Defects are found at early stage.
Works well in small projects where requirements are easily understood.
Despite of them, there also are disadvantages:
Rigid and not quite flexible.
The software is developed while the implementation phase, so no early prototypes
are produced.
If any change happens in a midway, the test documents along with requirement
documents have to be updated.
There are various situations in which the V-model can be applied:
This model should be used for small to medium sized projects where requirements
are clearly defined and fixed. The benchmark fulfils this sentence.
The V-shaped model should be chosen when ample technical resources are available
with needed technical expertise.
Development
- 40 -
This project has been developed from scratch and it follows the structure of the main steps
of the V-model. So, the project has had the following phases:
Figure 7.2 Project diagram
7.2 Training period
First of all it was necessary a training period to get into the various topics of the project:
AUTOSAR, MCAL, software architecture, automotive microcontrollers and learning to
develop a long and applied project.
Training
period
Design
Implementation
Integration
SW validation
Evaluation Delivery to µC
suppliers
Development
- 41 -
7.3 Design
Software design is the process of requirements’ transformation into some suitable form,
which helps the programmer in the software implementation and the coding. The responsible
of this phase figures out all the possibilities and techniques and makes the decision of which
one is better.
Any software project has a requirement specification from which start the process of design.
In this particular project, the requirement is evaluating the platform composed by
microcontroller, compiler and microcontroller abstraction layer, MCAL. All three elements
must have a good performance because, for instance, having a powerful microcontroller with
a poor MCAL is not what is aimed by Lear Corporation. Above this requirement, there is
the key point of the project: the benchmark has to be adaptable to any platform. So, the
design and the source code have to be as abstract as possible without losing strength to
evaluate the devices. AUTOSAR and MCAL are basic concepts to achieve this level of
abstraction.
The focus of this project is on the architectural design, which is the highest abstract version
of the system. In other words, the engineer thinks the idea for the solution. From the
architectural point of view, the microcontroller is seen as the image below:
Figure 7.3 MCAL blocks structure
Development
- 42 -
So, to fulfil the requirements, the solution for the project is evaluating as many modules of
the microcontroller as possible. This evaluation provides the quality of the microcontroller
peripherals as well as of the MCAL. A peripheral, an independent area of the
microcontroller, is responsible to do specific tasks. Later, in the integration part, the compiler
is chosen depending on the hardware used.
Once what to do is decided, a first idea of how to do it appears. Without giving much details,
because this will be explained in the following section, the evaluation of the three elements
is carried out in two different manners:
Measuring the time of execution of particular sections of the code, provides an
important data related with the microcontroller, the MCAL and the compiler. The
execution of the tests is performed more than once because the time of execution of
some of them may differ each time they are executed. For instance, the erasing of
flash memory never lasts the same amount of time. As a result of that, it is advisable
to execute the tests many times and measure both the maximum and the average time
of execution. The most interesting measurement is the maximum time, although the
average time may give information in case something wrong happens. Theoretically,
the difference between maximum and average time should be insignificant.
Analysing the memory map. Most compilers have the option to create a memory map
of the code generated. So, with that information the amount of RAM and Flash
required can be evaluated. Microcontrollers have more Flash memory inside than
RAM memory, although RAM is more quick than Flash.
So, at this early time of the project, the idea is to evaluate as many peripherals as possible to
achieve the goals of the project.
AUTOSAR and MCAL offer many drivers to evaluate different peripherals and buses of
communications, being the following the chosen to be analysed: CAN, ADC, DIO, FLS,
GPT, ICU, LIN, MCU, PORT, PWM, SPI, WDG. Apart from them, the CPU, RAM memory
and the microcontroller unit (MCU) will also be analysed.
Development
- 43 -
The architecture of the benchmark is the following:
Figure 7.4 Benchmark’s architecture
The benchmark acts as a scheduler for the rest of the software components. Each engineer
responsible to do the integration must adapt the peripheral configuration to match the
hardware setup connected to the microcontroller.
Development
- 44 -
7.4 Implementation
At this stage of the project, the design and architecture decided in the previous phase has to
be developed. After considering many options, it was concluded that the best option was
creating different tests focused in all the peripherals and modules decided to be evaluated.
As it was mentioned in the previous section, the time of execution of each function will be
measured in the following way:
Figure 7.5 Time measurement diagram
At this moment, the benchmark is the union of two different evaluations focused on different
targets:
The CPU benchmark is a collection of intensive computing routines that are designed
to extract metrics about the efficiency of the CPU of a given microcontroller. This
software component is hardware independent. Therefore, there are only requirement
regarding the environment where it is executed. It must be run on real silicon, not on
a simulator.
The MCAL benchmark is intended to evaluate the overall performance of the
platform composed of microcontroller, compiler and AUTOSAR MCAL. In order to
guarantee some interaction among the different peripherals of the microcontroller,
Lear requests the following hardware assembly:
ibd [SysML Internal Block] Configuration_HW [Time of functions]
MainFunction1
Time_1
Function2
Time_2
Function_X
Time_X
Development
- 45 -
Figure 7.6 Hardware assembly
o An ICU timer connected to a PWM generator
o One CAN hardware controller configuration, which shall be connected to a
CANcase or similar
o Two SPI interfaces connected with each other: MOSI0 MISO1,
MISO0 MOSI1, SCLK0 SCLK1
o Two input/output pins connected to an ADC input. Both inputs shall be part
of the same ADC group. Their output voltage could be regulated by a
potentiometer, if supported by hardware.
All the information obtained has to be stored in some way. After analysing different options,
such as using a 4-channel oscilloscope to view the time, the decision made was to use the
CAN bus. The reasons of that decision were many. On the one hand, studying and using a
very important bus of communications used in the automotive area, can provide me a good
insight about this environment. On the other hand, CAN offers software tools to show the
results in a very visual and easy-interpretative interface.
ibd [SysML Internal Block] Configuration_HW [Hardware setup_benchmark]
Spi0Spi1
PwmIcu
CAN0_TX
Adc
CAN0_RX
Pin_1 Port3
Lin_Tx
Lin_Rx
MCU
Spi0Spi1
PwmIcu
CAN0_TX
Adc
CAN0_RX
Pin_1 Port3
Lin_Tx
Lin_Rx
Hardware configuration
VoltageDivisor0
Can
CanCase
Can«trace»
«trace»
ADC Group
Development
- 46 -
7.4.1 Source Code
The benchmark is based on a main program. Its execution and all the tests are managed
inside the main following a defined structure as shown in the graph below:
Figure 7.7 Source code diagram
The lbmMcal_Startup function has been created to initialize all the modules required at first.
It includes MCU, DIO and PORT drivers.
All the tests are named following a template: lbmMcal_testX, being X the test number. None
of them use any argument.
Development
- 47 -
The lbmMcal_test1 is the first test and it is executed just once. This is because it initializes
the rest of modules, and this task is just needed once. One of the modules initialized is the
GPT, which is used to perform the time measurements. The function
Gpt_GetTimeElapsed(channel) is the service for querying the time already elapsed.
Although the module could work in one-shot mode, it will be configured in continuous
mode, in which the function returns the timer value relative to the start of the channel
(Gpt_StartTimer(channel)). The argument called by value is the channel of the module that
is being used. All time units are ticks, a neutral unit.
Channel states and state transitions of the GPT:
Figure 7.8 GPT timer status
Querying of time elapsed for a timer channel in continuous mode:
Figure 7.9 Querying of time elapsed
Development
- 48 -
After this measurement, the first CAN transmission of time can be performed. From this
moment, a loop is executed 255 times since the variable testCounter is an 8-bit variable and
counts from 1 to its maximum, 255. When its value is 255 and is incremented, it becomes to
0 and breaks the condition to get into the loop. Inside the loop, the rest of tests, are performed
and its time of execution is sent by using the Transmission function. When the loop ends,
the standby mode is set so as to evaluate the current consumption in this operating mode.
With one pin configured to show the voltage usage and a hardware assembly consisting on
a resistor, the current consumption can be evaluated as a result of using the Ohm’s law.
7.4.1.1 CAN Transmission
The function Transmission performs the writing and transmission of the CAN data frame.
.
Figure 7.10 Transmission diagram
Development
- 49 -
The MCAL offers a structure type to provide the following parameters of the frame:
ID: frame identifier
swPduHandle: each handle represents a link protocol data unit (L-PDU), which is a
constant structure with information for transmission and reception processing
length of the data
sdu: the service data unit. This is a pointer to the data that is transported inside the
L-PDU
typedef struct
{
Can_IdType id,
PduIdType swPduHandle,
uint8 length,
uint8 * sdu
} Can_PduType;
So, a variable of the type Can_PduType has been created:
Can_PduType Can_Pdu;
To write the measured values in the frame it is necessary to create a structure to adapt to the
requirements. The data field of a CAN frame is 8 bytes length. To have the same precision
in both the maximum and the average time measurement, 8 bytes will be used for the
maximum execution time and the rest for the average execution time. So, a structure named
T_Can_PduType_Data has been created.
typedef struct{
uint32 averageRunTime;
Gpt_ValueType maxRunTime;
}T_Can_PduType_Data;
Its variables are:
averageRunTime, 4 byte length/32 bit length
maxRunTime, declared as a Gpt_ValueType, a type of the MCAL which is 4 byte
length/32 bit length.
Development
- 50 -
The CAN data field distribution is the following:
After creating and initializing the structure, the variable Can_PduType_Data is created of
this type:
T_Can_PduType_Data Can_PduType_Data;
In the CAN initialization, apart from the module initialization, the following actions are
performed:
Assignment of the frame’s handle, which indicates the sub-module message buffer
for reception and transmission. To make the code easier to understand, a macro is
used:
#define CAN_HANDLE 1
Can_Pdu.swPduHandle = (PduIdType)CAN_HANDLE;
The data, which is changeable, is stored in the variable Can_PduType_Data of type
T_Can_PduType_Data created before. So, the address of this variable is stored into
Can_Pdu.sdu:
Can_Pdu.sdu = &Can_PduType_Data;
Assignment of the size of the data field. To do so, the unary operator sizeof is used:
Can_Pdu.length = sizeof(T_Can_PduType_Data);
The parameters of Transmission are called by value and are the following:
The number that identifies the test executed, test_number. Each test has a particular
number. To make easier the code and results interpretation, an enumerated type
named t_test_index has been created. Then, each variable of the typedef enum takes
a number from 0 to n, being n the number of tests +1.
typedef enum{
test_init_peripherals,
test_pwm_write,
AVERAGE
TIME [3]
AVERAGE
TIME [2]
AVERAGE
TIME [1]
AVERAGE
TIME [0]
MAXIMUM
TIME [3]
MAXIMUM
TIME [2]
MAXIMUM
TIME [1]
MAXIMUM
TIME [0]
Development
- 51 -
test_pll_ckeck,
test_dio_write,
test_dio_flip,
test_flash_read,
test_flash_write,
test_flash_erase,
test_pwm_read,
test_memcopy8,
test_memcopy8_pointers,
test_memcopy16,
test_memcopy32_align,
test_memcopy32_unalign,
test_sum,
test_product,
test_division,
test_product_float,
test_division_float,
test_adc_conversion,
test_spi_transmission,
test_dft_calculation,
test_diferential_calculation,
test_lin_transmission,
test_wdg_refresh,
test_max,
}t_test_index;
The number of executions of the main loop, testCounter.
The time measured just before the execution of the test, preTestTime.
Development
- 52 -
Firstly, the current time is measured just in the moment when entering in Transmission
function. Then, the total time of execution of the test is obtained making the difference with
the current time and the previous one, which has been called by value from the main.
Figure 7.11 Total time obtaining diagram
Frame building:
With the total time of execution, the following actions are developed for each test:
Get the maximum time value comparing the current total time and the previous
maximum one and writing of it in the data field:
Can_PduType_Data.maxRunTime= maxTime[test_number];
Get the average time value and writing of it in the data field:
Can_PduType_Data.averageRunTime = (uint32)( totalTime[test_number]
/ (testCounter) );
For both the maximum and the average time, an array of the number of tests has been created
to make easier the task to manage the measurements of each test:
static uint32 maxTime[test_max];
static uint32 totalTime[test_max];
Write and transmission:
Assign the identifier of the test to the frame:
Can_Pdu.id = test_number;
Development
- 53 -
Execute the write frame function until its return is CAN_OK. The first argument is
the identification of which HW-transmit handle shall be used for transmit. Implicitly,
this is also the information about the controller to use because the handles for
transmission’s numbers are unique inside one hardware unit. The second and last
argument is the pointer to SDU user memory, DLC and identifier.
Can_Write( (Can_HwHandleType)1, &Can_Pdu );
Wait until the frame is sent. The CAN transmission is configured by interrupt and a
callback function is called when the frame is sent. It informs the user about the status
of the transmission. Inside of it, the variable canTx_end is set to 1. Meanwhile, in the
Transmission subroutine the execution is blocked while this variable’s value is
different to 1. When the frame is sent, the variable is set to 0 again to get ready for
the next transmission task.
Development
- 54 -
Figure 7.12 CAN write diagram
Development
- 55 -
7.4.1.2 Test description
In this benchmark, 25 different tests have been developed. Each one of them is going to be
detailed in the following pages:
Test 0
Initialization of the MCU driver and measurement of that time. This measurement is done
by writing the level of one channel just after all the API’s related with the MCU driver are
finished. To do so, the DIO and PORT driver are required and initialized.
Figure 7.13 Test 0 diagram
Development
- 56 -
Firstly, the MCU is initialized with the Mcu_Init function. Its argument is a pointer to
configuration structure. As it will be explained in more detail in the integration section, all
the modules initialization’s argument will be a NULL_PTR. After the initialization, the
following sequence is followed:
Initialize the Phase-Locked Loop (PLL) and MCU specific clock options with the
Mcu_InitClock function. The argument of this function are the clock settings
configured.
Verify the PLL status until it is locked with the Mcu_GetPllStatus function.
Activate the PLL clock to the MCU clock distribution with the
Mcu_DistributePllClock function.
Then, two more modules are initialized so as to measure, approximately, the startup time of
a particular platform. PORT and DIO are initialized in the same way as the MCU, with the
Port_Init and the Dio_Init functions. Then, one level of a pin is written to high level with
the Dio_WriteChannel function. Its arguments are the channel identifier (which has to be
configured as output in the PORT module, task developed in the integration phase) and the
channel desired level, high or low.
Dio_WriteChannel((Dio_ChannelType)DioConf_DioChannel_Pin_startup, (
Dio_LevelType) STD_HIGH);
Test 1
Initialization of the other drivers: GPT, CAN, FLS, PWM, ICU, ADC, SPI, WDG and LIN.
From the moment the GPT driver is initialized the times are measured using the function
provided by AUTOSAR, Gpt_GetTimeElapsed, which provides the elapsed time since the
start of the timer.
Test 2
Write a PWM with a particular duty cycle. Depending on the value of the TestCounter
variable, the duty cycle of the PWM signal set different values: 40%, 60%, 70% and 80%.
Development
- 57 -
The Pwm_SetDutyCycle function is used to perform the test and its parameters are the PWM
channel as well as the duty cycle value.
Pwm_SetDutyCycle((Pwm_ChannelType)PwmConf_PwmChannel_Pwm_1,(uint16)
DC_40);
Test 3
Verification that the PLL of the microcontroller is correctly locked. The Mcu_GetPllStatus
function is used to get the status of the PLL. The function has no parameters.
Test 4
Write of the level of two different channels. The Dio_WriteChannel function performs the
test and its parameters are the configured channel as well as the level to set to the channel,
low or high.
Dio_WriteChannel((Dio_ChannelType)DioConf_DioChannel_Led1,
(Dio_LevelType)STD_LOW);
Test 5
Flip the level of the two channels previously written. The Dio_FlipChannel function flips
the channel’s level and its parameter is the channel identifier.
Dio_FlipChannel((Dio_ChannelType) DioConf_DioChannel_Led1);
Development
- 58 -
Test 6
Erase of Flash memory (16384 bytes). The integration phase has to modify the default
memory addresses so as to adapt to the particular MCU memory map.
Figure 7.14 Test 6 diagram
Firstly, the Fls_Erase function is executed. This function starts an asynchronous job of erase
writing in the register the job, MEMIF_JOB_PENDING, although it is actually performed
by the Fls_MainFunction. The parameters of the function are the target address in flash
memory and the number of bytes to erase. Then, there is a do-while structure to assure that
the job is performed. As it was said before, the Fls_MainFunction performs the job. Then,
the Fls_GetStatus function is performed so as to know the Fls module status. This return
may be: MEMIF_UNINIT when the module has not yet been initialized, MEMIF_IDLE
when the module is idle and MEMIF_BUSY when the module is busy. So, if the return of
the function is MEMIF_IDLE, the erase job as well as the test have been finished. If not, the
return is MEMIF_BUSY, the job still has to finish and the loop will be executed again until
the return is the expected.
Development
- 59 -
Test 7
Reading of flash memory and storage of the data read in ram memory. (16384 bytes). The
integration phase has to modify the default memory addresses so as to adapt to the particular
MCU memory map.
Figure 7.15 Test 7 diagram
The structure of the test is the same of the erase one, changing the Fls_Erase function for
the Fls_Write one.
Test 8
Writing of data in Flash memory. (16384 bytes). The integration phase has to modify the
default memory addresses so as to adapt to the particular MCU memory map.
Development
- 60 -
Figure 7.16 Test 8 diagram
The structure of the test is the same of the erase one, changing the Fls_Erase function for
the Fls_Read one. The read function passes a pointer to target the data buffer in which the
data read will be stored.
Test 9
Measurement of the duty cycle of a PWM signal generated in the test 2. With the
Icu_StartSignalMeasurement function starts the measurement of signals beginning with the
configured default start edge which occurs first after the call of this service. Inside the test
9, the user gets aware of the duty cycle value. This task is performed by the
Icu_GetDutyCycleValues function, which reads the coherent active time and period time for
the given ICU channel. One of the parameters of this function is a pointer to a buffer where
the results shall be placed. This results are the high and the period time, from which the duty
cycle can be obtained. Finally, the Icu_StopSignalMeasurement stops the signal
measurement of the given channel.
Development
- 61 -
Figure 7.17 Test 9 diagram
Test 10
Copy of a package of data of 8-bit from ram to ram.
Test 11
Copy of a package of data of 8-bit from ram to ram using pointers.
Test 12
Copy of a package of data of 16-bit from ram to ram.
Test 13
Copy of a package of data of 32-bit aligned from ram to ram.
Test 14
Copy of a package of data of 32-bit unaligned from ram to ram.
Test 15
Execution of a sum.
Development
- 62 -
Test 16
Execution of a product.
Test 17
Execution of a division.
Test 18
Execution of a float product.
Test 19
Execution of a float division.
Development
- 63 -
Test 20
ADC conversion. Measurement of the time to setup the buffers, to start the group conversion,
get the group status and write the conversions in a buffer.
Figure 7.18 Test 20 diagram
This test performs various tasks, the conversion of two different ADC channels and the
reading of the results of a group conversion.
The procedure to make a group conversion is always the same:
Execute the Adc_SetupResultBuffer function, which initializes the group specific
ADC result buffer pointer as configured to point to the address that is passed as
Development
- 64 -
parameter (dataBufferAdc). The first parameter is the numeric ID of requested ADC
channel group.
Adc_SetupResultBuffer((Adc_GroupType) AdcConf_AdcGroup_AdcGroup_0,
(Adc_ValueGroupType*) &dataBufferAdc);
Execute the Adc_StartGroupConversion function, which starts the conversion of all
channels of the requested ADC channel group. The only parameter of this function
is the numeric ID of requested ADC channel group.
Into a do-while loop, execute the Adc_GetGroupStatus function, which returns the
conversion status of the requested ADC channel group. The possible returns are:
o ADC_IDLE, when the conversion of the specified group has not been started
yet.
o ADC_BUSY, when the conversion of the specified group has started and is
still going on
o ADC_COMPLETED, when a conversion round, which is not the final one, of
a specified group has been finished.
o ADC_STREAM_COMPLETED, when the result buffer is completely filled.
For each channel of the selected group the number of samples to be acquired
is available.
The loop is executed until the return of the Adc_GetGroupStatus function is
ADC_STREAM_COMPLETED.
The other action performed is reading the group conversion results and storing them in
a data buffer.
Adc_ReadGroup((Adc_GroupType) AdcConf_AdcGroup_AdcGroup_0,
(Adc_ValueGroupType*) &adc_read);
This test does not measures the whole time of execution of the lbmMcal_test20 but the
time of execution of the following functions because of they are used in many different
professional applications:
o Adc_SetupResultBuffer
o Adc_StartGroupConversion
o Adc_GetGroupStatus
o Isr_Adc_EndOfGroupConversion0 (interrupt)
Development
- 65 -
Test 21
SPI transmission of 128 bits. Configuration with one master and one slave.
Figure 7.19 Test 21 diagram
This test performs two different tasks. On the one hand, transmitting data on the SPI bus. On
the other hand, reading data from a particular SPI handler.
The procedure to transmit data is the following:
Firstly, it is necessary to write the data to be transmitted into the buffer of a specific
channel. This job is performed by the Spi_WriteIB function (IB stands for Internal
Buffer), whose parameters are the channel identifier and a pointer to the source data
buffer. In this test the buffer is 128 bit length.
Development
- 66 -
Then, the transmission of the given sequence is performed in an asynchronous way
to be as quick as possible. The Spi_AsyncTransmit function performs this job and its
only parameter is the sequence ID.
As the objective is to save time and resources, the ISR of end of queue (EOQ) of the
particular physical unit has been configured to know in real time when the whole data has
been transmitted.
Finally, the data sent is also read. This task is performed by the Spi_ReadIB function, which
stores the data at a particular memory location. Its parameters are the channel ID to be read
as well as a pointer to the memory location that will be written with the data in the internal
buffer.
As in the ADC test, the SPI ones measures particular execution times:
The time to write data in the internal buffers
The time spent into the ISR. Getting knowledge of this time is really interesting for
future applications of the driver
The time to transmit the whole data
Test 22
Calculation of a discrete Fourier transform (DFT) of a discrete-time sequence directly. This
test includes cosines, sinus, calculations with floating points as well as imaginary numbers,
which is quite demanding for the CPU.
Test 23
Calculation of a second order differential equation through numerical procedures. This tests
also evaluates the CPU.
Development
- 67 -
Test 24
LIN transmission of 8 bytes.
The MCAL offers a structure type to provide the following parameters of the frame:
typedef struct
{
Lin_FramePidType Pid;
Lin_FrameCsModelType Cs;
Lin_FrameResponseType Drc;
Lin_FrameDlType Dl;
uint8* SduPtr;
} Lin_PduType;
PID: LIN frame identifier
Cs: checksum model type, enhanced or classic model.
DRC: response type. It may be master response, when it is generated from a master
node; slave response, when it is generated from a remote slave node and slave to
slave, when the response is generated from one slave to another slave.
Dl: data length
SduPtr: pointer to the service data unit (SDU).
Then, a variable named dataBufferLin has been created of this type:
Lin_PduType dataBufferLin;
Then, the structure has been filled with the following parameters:
o The ID is 0. A variable named LinPid was defined as 0x0 to make easier the
interpretation of the code.
#define LinPid 0x0
[…]
dataBufferLin.Pid= LinPid;
o The data length is 8 bytes. A variable named LinDataLength was defined as
0x08 to make easier the interpretation of the code.
#define LinPid 0x0
[…]
dataBufferLin.Dl= LinDataLength;
o The classic checksum model is used.
dataBufferLin.Cs= LIN_CLASSIC_CS;
Development
- 68 -
o The response is generated from the master.
dataBufferLin.Drc= LIN_MASTER_RESPONSE;
o dataBuffer contains the data to be transmitted.
dataBufferLin.SduPtr= dataBuffer;
Figure 7.20 Test 24 diagram
Development
- 69 -
Once the structure’s parameters are defined, it is necessary to verify the operational state of
the bus. There is a boolean variable named sleep that when is true, indicates the bus is in
sleep operating mode. When this happens, the bus is set to the normal operating mode using
the Lin_Wakeup function, which generates a wake up pulse to recover the bus from the sleep
mode. Its parameter is the LIN channel to be addressed. This function will be executed in a
do-while loop until its return is E_OK, which indicates the action has been successfully
performed. Just before leaving the sleep variable is set to 0.
Once the bus is set in normal operating mode, the Lin_SendFrame function sends a LIN
frame:
(void)Lin_SendFrame((uint8) LinHWCh_0, (Lin_PduType*)
&dataBufferLin);
The parameters of the function are the LIN channel to be addressed as well as the pointer to
the PDU that contains all the information of the frame.
To get the status of the LIN driver, the Lin_GetStatus function returns the state of the current
transmission, reception or operation status. When the reception of a slave response is
successful then this service provides a pointer to the buffer where the data is stored. This
function is executed in a do-while loop until its return is LIN_TX_OK, which indicates a
successful transmission.
do
{
linStatus=Lin_GetStatus((uint8) LinConf_LinChannel_LinChannel_0,
(uint8**) &linSduPtr);
}while(linStatus != LIN_TX_OK);
The parameters of the function are the LIN channel to be checked and the pointer to pointer
to a shadow buffer where the current SDU is stored.
Finally, the Lin_GoToSleep function is executed so as to instruct the driver to transmit a go-
to sleep command on the addressed LIN channel and the boolean sleep variable is set to 1.
The sleep command is very used in the automotive area to reduce the unnecessary resources’
consumption.
Development
- 70 -
Test 25
Refresh of the timeout of the watchdog module.
At the end of tests, the microcontroller is set in low-power mode to study the power
consumption in both normal and low-power operation.
Development
- 71 -
7.5 Integration
In general, system integration is the process of bringing together the component subsystems
into one system and ensuring that the subsystems works together as a system. In this
particular project, the integration phase corresponds to the part of the project in which the
microcontroller and the MCAL are configured so as to satisfy the requirements. To develop
this phase, it is strongly necessary to have a good knowledge of the microcontroller features
to both optimize and strengthen them. During the development of this project, as two
different devices have been evaluated, the integration has been carried out twice. This is a
phase that will have to be carried out for each platform intended to be evaluated because it
is hardware dependent.
Each MCAL supplier provides an integration tool to configure the MCAL and the
microcontroller all together. For instance, ST provides the EB Tresos and Renesas the ECU
Spectrum.
The tool I have used to do the integration has been the EB Tresos.
Figure 7.21 EB Tresos environment
- At the left side, the project with all the configurable modules.
- In the centre, there is an example of configuration. Particularly, this shows the
configuration of one channel of the GPT module called “Gpt_ChannelWdg”
Development
- 72 -
- Once the configuration of a module is ready, the procedure to generate code is always
the same. Firstly, saving the configuration. Then, making a verification of the project.
This step is really useful because warns about errors and its reason. And finally
generating the code. It is the basic infrastructure from which starting with promoted
by AUTOSAR and MCAL.
7.5.1 Mandatory configuration
To evaluate the platforms under the same conditions, some configuration to be done in the
integration phase has been defined as mandatory requirements.
MCU
The configuration of the MCU driver is up to the responsible to do the integration of the
benchmark. It would be convenient to prepare a configuration capable to work as quickly as
possible.
PORT
Configured as output:
1 PWM channel
2 channels in GPIO mode
1 channel in CAN mode (Tx)
1 SPI channel (SCLK, MOSI and SS signal mode)
1 channel in LIN mode (Tx)
Configured as input:
1 ICU channel
2 ADC channels
1 SPI channel (MISO)
1 channel in CAN mode (Rx)
1 channel in LIN mode (Rx)
Development
- 73 -
GPT
Two channel configuration:
GptChannel_TimeMeasurement
o GptChannelTickFrequency: up to the integrator
o Channel mode: continuous
GptChannel_Wdg
o GptChannelTickFrequency: up to the integrator
o Channel mode: continuous
CAN
One CAN configurations:
Configuration 1 (Tx):
o HW channel: channel that implements the CAN protocol
o Can Rx Processing Type: Interrupt
o Can Tx Processing Type: Interrupt
o Can BusOff Processing Type: Polling
o Can Controller Prescaller: 4
o Can Controller Baudrate: 125 Kbps
o Can Propagation Segment: 2
o Can Phase Segment 1: 5
o Can Phase Segment 2: 5
o Can Resynch Jump Width: 3
o Can Filter Mask: 0 (don’t care)
Can HW objects:
CanHWObject_0:
o Transmit MB type
o Standard ID message
Development
- 74 -
FLS
One Fls configuration:
Fls Max Read Normal Mode: 1024 bytes
Fls Max Write Fast Mode: 256 bytes
Fls Max Write Normal Mode: 256 bytes
The sectors required to do the read/write/erase tasks must be defined in the sectors
area. Virtual addresses must be used while doing the integration.
PWM
One channel configuration
Channel class: variable period
HW channel: up to the responsible to do the integration.
Period default units: Hz
Period default: 1000
Polarity: high
ICU
One channel configuration:
HW channel: up to the responsible to do the integration.
Measurement mode: mode signal measurement
Signal measurement property: duty cycle
ADC
One ADC configuration:
Adc priority mechanism: HW_SW
Adc transfer type: interrupt
Group access mode: mode single
Group conversion mode: one shot
Group conversion type: normal
Trigger source: SW
Development
- 75 -
SPI
One SPI configuration:
Buffers allowed: only internal (IB)
Transmission: asynchronous
Structure of the transmission: one channel, one job and one sequence
External device configuration
o Baudrate: 1MHz (1 Mbit/s)
Channel configuration
o Data width: 8 bits
o Number of buffers: 16
o Data sent: 128 bits
LIN
One LIN configuration:
1 channel
Channel baudrate: 10 Kbps
Break Length: 13 bits
WDG
One WDG configuration:
Default mode: slow mode
External trigger counter: GptChannel_Wdg
Operation mode: Reset on timeout
Development
- 76 -
7.5.2 Independent configuration
Besides the mandatory configurations for benchmark, there are other that are up to the
integrator of the benchmark. So, they will be configured in a particular way depending on
the microcontroller used.
Examples of module’s configuration:
GPT
The benchmark uses a flexible and neutral unit, the tick, to measure the time of
execution of each test. This is due to the evolution of the microcontrollers, which
year by year improve their features.
For instance, the current results are of the order of microseconds. It could have been
decided to set a timer of 1 MHz to perform the measurements. But, what would
happen in the future, when microcontrollers will be so fast that the time of execution
of one test is less than the minimum measurable time, 1 microsecond? We would not
have enough resolution to perform the measurement and it would be incorrect,
because 0.9 microseconds and 0.1 microseconds would be considered as equal times.
So, the tick duration is up to the integrator of the benchmark, who is responsible to
configure it assuring as precision as possible.
Figure 7.21 GPT integration
o Identifier of the GPT channel: 1
o Hardware channel: a microcontroller has different timer modules
implemented. For this particular device the timer used was the System Timer
Module (STM), which has one 32-bit up counter with an 8-bit prescaler
o Channel mode: continuous
Development
- 77 -
o Tick frequency: depending on the system clock, this parameter determines
the measurement’s precision. For this particular device, the channel tick
frequency is set to 10 MHz.
ADC
In the integration phase the ADC channels are configured. Moreover, the channels
can be grouped inside ADC groups.
Figure 7.22 ADC integration
o ADC channels: AdcBatteryVoltage, AdcDiagnostics, AdcAuxiliary…
o ADC channel ID: a particular identifier is assigned to each channel to identify
it.
o ADC channel resolution: the resolution of the conversion can be chosen.
Typical values are 10 and 12-bit channel resolution
PORT
All the pins necessaries to develop the benchmark are configured on this module.
The direction (input, output or both) is selected as well as the mode configuration.
One or more modes can be possible for a single pin, so depending on the necessities
one pin is configured in one mode or other.
Development
- 78 -
Figure 7.23 PORT integration
o PORT name: BLD_LIN_EN, SC_RSTSBC_SI_CS0…
o PORT Pin ID: each configured port has a particular ID
o PORT pin PCR: each pin has a Port Configuration Register (PCR) in the
module that allows selection of the output functions that is connected to the
pin.
o PORT pin mode: each pin has different modes to work with. This feature
choses this mode for the configured pin
o PORT pin direction: input, output and input/output.
o PORT pin level: high or low
PWM
The Pulse Width Modulation module offers the possibility to configure a channel to
generate a signal. It is possible to configure the channel in different ways, choosing
the value of the duty cycle, the value of the period, whether it is fixed or variable and
the polarity of the signal. Moreover, the clock reference for the signal is chosen.
Development
- 79 -
Figure 7.24 PWM integration
o PWM Channel Class: class of the channel. PWM_VARIABLE_PERIOD is the
parameter that shall change the period for all the channels of that submodule.
o PWM Channel ID: identifier of the configured channel
o PWM HW channel: specification of the hardware timer channel to be used
o PWM polarity: high or low
o PWM duty cycle default: the default value for DC used for the initialization
of the channel.
o PWM idle state: parameter that represents the state of the pin when the output
is set to idle
Development
- 80 -
FLS
For writing, erasing and reading flash memory it is necessary to configure the
necessary sectors and allow their access. Each microcontroller has a memory map in
which there is a sectors list. Each sector that is accessed has to be configured in the
integration phase to avoid system errors. It is usual to have to work with virtual
addresses.
Figure 7.25 FLS integration
o Sector name: FlsSecotr_L0_BM, FlsSector_L1_BL…
o FLS physical sector: configures the physical flash device sector
o FLS page size: parameter to set the size of one page in this sector. In this
particular case, 8 byte.
o FLS sector size: parameter that sets the total size of one sector. This
parameter is hardware dependent.
o FLS sector start address: parameter that defines the start address of a
particular sector. In some MCAL versions, the addresses are virtual. This
means that the value set in the configuration is not the real hardware address
because no gaps between sectors are allowed in the configuration. The
MCAL is the responsible to obtain the real hardware address.
Development
- 81 -
Regarding interrupts, the following have been configured. It is necessary to say that the
interrupts’ configuration is also hardware dependent:
One timer interrupt to generate the PWM signal
One timer interrupt to measure the duty cycle using the ICU
One interrupt of end of group conversion for the ADC
Two timer interrupts for the timers of the GPT
One interrupt for the CAN. Reception (Rx)
Two interrupts for LIN. Transmission (Tx) and reception (Rx)
7.5.3 Compiler and MCAL
Apart from the module’s configuration, at this phase it is necessary to make the decision
about the compiler and the MCAL version to use.
Compilation process
The decision about what compiler to use is strongly related with the CPU of the
microcontroller used. In other words, the CPU has a determinant influence on the decision
of choosing a particular compiler. Then, with all the possibilities, the application of the
project, the price and the licenses available are important aspects to take into consideration
when making the final decision.
For this project, as two different microcontrollers have been evaluated, two different
compilers have been used: the C1 and the C2.
The MCAL provides more than 261 files. Obviously, the task of compiling the source code
manually may be tedious. As a result of that, it has been necessary to create a makefile to
automatize the process of compilation and save time.
A makefile is a special format file that together with the make utility help to automatically
build and manage the project compilation.
At first, the files available are of type .c and .h. When the integration task is developed, the
integration tool generates the .xdm files, which contains the information of each module
configured and modify the configuration .c and .h files (moduleName_cfg.c/
moduleName_cfg.h). This is the basic infrastructure from which start working, the
AUTOSAR MCAL.
Development
- 82 -
Then, the compilation has to be carried out. A make executable file calls the makefile
developed. This file executes the compiler, the assembler and the linker providing them the
path of all the files needed as well as the file’s relationships. As a result of these processes,
the object files (.o) are created. Moreover, when the whole compilation is right, an executable
and linkable file (.elf) of the source code is created. With it, the .cmm executable file can be
created and loaded to the microcontroller so as to run the program.
Example of files generation, applied to some files of the Flash driver:
Figure 7.26 Compilation process
MCAL
In Lear Corporation most projects use the Microcontroller Abstraction Layer (MCAL)
because of their advantages as well as because all the car makers use it for their projects.
As the benchmark has to be able to evaluate the newest devices, it is strongly convenient to
use an up to date MCAL version. The MCAL I have used for the two integrations I have
developed has been the 4.0.3 with the software version 0.9.0, and it was released on August
2014.
Development
- 83 -
Table resuming the two integrations carried out and its main features:
Platform 1 Platform 2
Microcontroller M1 M2
MCAL (Autosar
Version)
4.0.3 4.0.3
MCAL (SW
version)
0.9.0 0.9.0
Compiler C1 C2
Development
- 84 -
7.6 Software validation
As it was explained before, the V-model includes a system verification and validation phase.
So, before starting delivering the benchmark it was necessary to verify the software
development and the requirement’s fulfillment.
The validation has been carried out through an M1 microcontroller of ST company.
There have been two basic elements, apart from the microcontroller, to develop the
validation phase:
Debugger software tool: Trace 32
Trace 32 is an in circuit emulator, based on systems that use JTAG. It offers powerful
debugging tools: easy high-level and assembler debugging, display of internal and
external peripherals on, on chip break and trigger support, flash programming and
multiprocessor debugging.
Figure 7.27 Debugging process
Development
- 85 -
Debug module: Power debug interface usb-2
Figure 7.28 Debugger tool
The Lauterbach power debug is the tool used to perform the connection between the
computer and the evaluation board. This is a really powerful software tool to debug
programs in real time.
Once the validation of the software is completed, the evaluation of any platform can be
carried out and its results can be taken into consideration for future decisions.
Development
- 86 -
7.7 Evaluation
Once the software validation is finished, the platform’s evaluation is carried out. As this
phase is hardware dependent, it will be necessary to be developed for each platform
evaluated. We will get the data to know deeply the features of the platform composed of
microcontroller, MCAL drivers and compiler.
I have evaluated two different platforms (microcontroller, compiler, MCAL):
M1 (64 MHz) , C1, MCAL 4.0.3
M2 (160, 120 MHz), C2, MCAL 4.0.3
Moreover, one Tier 2 supplier performed the benchmark with one of its products, mixing
different CPU’s and options of compilation:
M3 (80 MHz - size optimization), C3, MCAL 4.1.3
M3 (80 MHz – speed optimization), C3, MCAL 4.1.3
M3 (96 MHz - size optimization), C3, MCAL 4.1.3
M3 (96 MHz – speed optimization), C3, MCAL 4.1.3
As it was expected, the difference between the maximum and the average time are not really
significant. So, the results represent the maximum time of execution of each time.
The results are presented considering both the CPU and the MCAL benchmark.
Development
- 87 -
CPU benchmark
The first table shows the maximum times of execution of the CPU benchmark in two
different platforms. The M2 microcontroller has three different CPUs, one working at 160
MHz and the two rest at 120 MHz. So, the CPU benchmark has evaluated the two CPU types
of this particular microcontroller.
Time in µs M1 M2 (160MHz) M2 (120 MHz)
Memcopy8 1308,2 137,5 183,83
Memcopy8 pointers 1308 167 222,76
Memcopy16 1316,5 150,3 200,8
Memcopy32 align 855,9 175,95 234,967
Memcopy32_unalign 915,5 139,05 185,93
Sum 1845,5 213,65 285,2
Product 2117,8 163,55 218,1
Division 4353,7 475,63 634,3
Product float 8267,9 208,87 277,77
Division float 10262,7 557,28 742,96
The second table shows the results of the M3 microcontroller working with different
configurations.
Time in µs 80 MHz
Osize
80 MHz
Ospeed
96 MHz
Osize
80 MHz
Ospeed
Memcopy8 716,3 296,7 599,4 247,3
Memcopy8 pointers 767 635,8 641,9 529,9
Memcopy16 716,2 303 599,3 252,6
Memcopy32 align 716,2 239 599,3 199,2
Memcopy32_unalign 894,7 463 748,6 385,9
Sum 1124,2 424,6 940,6 353,9
Product 1022,2 520,6 855,3 433,9
Division 2196,1 1481,6 1837,4 1234,7
Product float 6272,4 5662,2 5247,6 4718,6
Division float 8092,1 7420,4 6769,9 6183,8
Development
- 88 -
MCAL benchmark
The first table shows the maximum times of execution of the MCAL benchmark in two
different platforms. For the MCAL benchmark, the CPU of the M2 used has been the one of
160 MHz.
Time in µs M1 M2
PWM write 26,8 22,05
PLL check 4,2 5,07
DIO write 3,4 5,95
DIO flip 7,3 7,7
Flash read 949,3 1030,93
Flash write 78482,8 94608,6
Flash erase 280402 171734,6
PWM read 14,1 8,97
ADC conversion 2,6 1,35
SPI transmission 57 22,23
DFT calculation 7913317
,5
3367398,4
Diff. calculation 1900004
,1 904763,12
LIN transmission 13361 7144,91
WDG refresh 7,7 4,87
Development
- 89 -
The second table shows the results of the M3 microcontroller working with different
configurations.
Time in µs
80
MHz
Osize
80 MHz
Ospeed
96 MHz
Osize
96 MHz
Ospeed
PWM write 7,7 7,5 6,4 6,3
PLL check 3,3 3,2 2,9 2,8
DIO write 4,7 4,4 4 3,8
DIO flip 5,2 5,1 4,4 4,3
PWM read 5,5 5,.3 6,5 6,2
ADC conversion - - - -
SPI transmission - - - -
DFT calculation - - - -
Diff. calculation - - - -
LIN transmission - - - -
WDG refresh - - - -
Note: for the tests of Flash and the ones comprised between Adc_Conversion and Wdg_Refresh,
the supplier has still not given the results.
Development
- 90 -
Apart from the numerical results, some tests generate signals that have been showed in a
digital oscilloscope to verify the signal generated is correct:
Test 2: generation of a PWM signal
Features: fixed period (1000 Hz) and variable duty cycle
o 50 % DC signal
Figure 7.29 PWM signal
o 80 % DC signal
Figure 7.30 PWM signal
Development
- 91 -
Test 21: SPI transmission
Features: 128 bits sent, 1 Mbps baudrate and 16 buffers
Figure 7.31 SPI transmission
Test 24: LIN transmission
Features: 8 bytes sent, classic checksum model and the master generates the response
Figure 7.32 LIN transmission
Development
- 92 -
CAN transmission
Features: 125 Kbps baudrate
Figure 7.33 CAN transmission
Figure 7.34 CAN registers
This is a screenshot of the registers of the CAN module. Trace 32 offers the
possibility to debug the code and see in real time the registers of each module. In this
situation, MB1 is the mailbox of transmission from which the information is sent.
Inside of the mailbox there are the identifier of the test, in the register ID, as well as
the data sent, which is contained in the registers Byte 0-3 and Byte 4-7. The test
identifier is 1, the average time is 295 ticks (0x127 hexadecimal) and the maximum
time is 298 ticks (0x12A).
Development
- 93 -
7.8 Delivery phase
This phase, specific of my project, is the one in which I deliver all the files and
documentation necessary for the benchmark to the supplier’s engineer responsible to do the
integration and evaluation phases.
The deliverable files are the following:
Source file, which has been developed in C language.
Makefile to manage the compilation of all the files.
Integration manual.
CAN data base. The results interpretation may be tedious without any interface. So,
I have developed a CAN data base to make easier the interpretation of the results.
For each frame sent, it shows in real time the frame identifier, the name of the test as
well as the data containing the times measurement. The data base looks like the
picture below:
Figure 7.35 CAN data base
Development
- 94 -
7.9 Analysis of the results
In this phase the results of the different microcontrollers obtained are analysed so as to set
the basis for making a good decision. Studying deeply the results, conclusions can be
obtained and the best product chosen.
The conclusions we can obtain from the results obtained until now:
The difference between CPU’s is shown in the results. As it was expected, M2
microcontroller’s performance is better than the M3, whose performance is better
than the one of the M1 device.
The erase of Flash memory is the Flash test that clearly lasts more time. Knowing
that time is important because it has many real applications.
The most demanding tests for the CPU, the differential and DFT calculation show
the great difference between the M1 and the M2 microcontroller.
Discovery of unexpected results. The read and write tests of the M2 last a little more
than in the M1. This was not expected at all. This is one of the great advantages of
this benchmark, going a little further and discover unexpected things to take into
consideration when making a decision.
The importance of the compilation as well as the options of compilation. The most
suitable options of compilation may help to strengthen the qualities of a device.
The same microcontroller, the M3, has different results depending on the option of
compilation chosen, speed and size optimization. Depending on the application, a
particular option is chosen.
See the examples below:
o The test of peripherals’ initialization lasts 6% less when the option of
compilation is speed than when it is size in the 80 MHz CPU.
o The test memcopy 32 alignment lasts 67% less when the option of
compilation is speed than when it is size both in 80 and 96 MHz CPU.
o The test sum lasts 63% less when the option of compilation is speed than
when it is size both in 80 and 96 MHz CPU.
Conclusions
- 95 -
8 Conclusions
This project had a clear purpose to achieve, developing a benchmark to evaluate the platform
composed of microcontroller, compiler and MCAL. This three of a kind is really usual in
the software automotive area, and it is getting more and more important to know clearly that
the platform used is the best and more suitable for a particular project. Once the project has
been finished, it can definitely be concluded that the goal has been achieved.
As a result of the development of that project, the company where I developed the project,
Lear Corporation, gets some benefits. Firstly, the best tool to evaluate any platform to be
used. Secondly, knowing the quality of the technical support of the suppliers before start
working with them. And finally, this is completely an innovative project internally in the
company since the previous benchmark just evaluated the CPU. Apart from the inner
innovation, this project is also novel in the automotive market, which represents a market
competitive advantage for the company towards the competitors.
Figure 8.1 Lear’s benchmark comparision
Personally, the experience of developing my final degree project in Lear Corporation has
been highly positive. Regarding hard skills, I have learned to automatize repetitive processes,
which may represent an important save of time. Moreover, I have acquired a good insight
into the topics of the automotive engineering, such as automotive microcontrollers, buses of
communications and software professional tools. Finally, I have improved my programming
skills. As for soft skills, I have learned to manage a real and long-term project on my own,
as well as solving problems. Moreover, I have acquired the basis of what is being in a
2008 benchmark 2015 benchmark
Conclusions
- 96 -
professional environment, including team work inside the company and interaction with
microcontroller’s suppliers.
Bibliography
- 97 -
9 Bibliography
http://www.autosar.org/ 18/03/2015
http://www.autosar.org/about/basics/ 18/03/2015
http://www.autosar.org/specifications/ 18/03/2015
http://en.wikipedia.org/wiki/AUTOSAR 18/03/2015
http://en.wikipedia.org/wiki/Analog-to-digital_converter 18/03/2015
http://www.ami.ac.uk/courses/ami4655_micros/ 18/03/2015
http://www.digikey.com/es/articles/techzone/2011/jul/understanding-microcontroller-
performance-analysis-techniques 18/03/2015
http://inst.cs.berkeley.edu/~ee249/fa08/Lectures/handout_canbus2.pdf 19/03/2015
http://www.can-cia.org/index.php?id=systemdesign-can-physicallayer#c2068 19/03/2015
https://support.dce.felk.cvut.cz/pub/hanzalek/_private/ref/canphy.pdf 19/03/2015
http://ocw.um.es/ingenierias/sistemas-embebidos/ 19/03/2015
http://en.wikipedia.org/wiki/CAN_bus/ 19/03/2015
http://vector.com/vi_canoe_en.html 23/03/2015
http://www.mikroe.com/chapters/view/64/ 22/05/2015
http://code2flow.com/ 28/05/2015
http://www.searchsoftwarequality.techtarget.com/ 5/06/2015
www.embedded-systems-portal.com/ 7/06/2015
Lear Corporation internal documentation.