ECU implementing Controlboard

From ConceptCar
Revision as of 12:04, 19 October 2009 by Dulcineia (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search ECU implementing Controlboard

The Controlboard is implemented over an AT91SAM7A2 board. It was presented in Figure 2.3 in the Data Processing level.

Table of Contents Control board overview Control board overview

As stated above, the Controlboard has bigger computational power than the other Sensor and Actorboards and it is responsible for the vehicle intelligence, executing computation-intensive tasks, allowing the implementation of more complex applications as driver assistance systems.

The board does not have direct access to any sensors or actuators, but relies on the other boards to provide sensory input and apply actuator settings.

The current firmware of this ECU offers an elegant and quick solution to load external executables via a bootloader from an SD-Card. Through a half-automated process executables can be created from Simulink™ models [reference Simulink]. The process, tools and further information are presented in details in Chapter 3.

Table 1.7 presents the CAN messages for the Controlboard.

Table 1.7: Controlboard's CAN messages
CAN ID Semantics Interval Conversion
0x122 Throttle value for engine control. Conversion result is percentage of controller’s maximum value, +100% means full speed, -100% is full stop, 0% is neither brake nor speedup. Simulink Model’s step time
0x125 Desired steering angle (α) for the steering servo. Negative values mean “steer left”. Value range is -30° to 30°. Simulink Model’s step time

The following Sections describe the Controlboard in details, its hardware, signals, platform software, run-time environment and bootloader. Those details are very important to understand the next steps, where the process to develop applications to the Concept Car is described. Hardware description

The AT91SAM7A2 board is based on the ARM7TDMI embedded processor with a 32-bit RISC architecture, 16-bit instruction set and low power consumption. It is composed by an on-chip 16K bytes internal SRAM, 2 UART interfaces, SPI Interface, 4 Channel 16-bit PWM (Pulse Width Modulation), 4 CAN Controllers, Timer Counter, LEDs (Light-Emitting Diode), GPIO (General Purpose Input/Output), ADC (Analog-to-Digital Converter), Buttons, Ethernet, Buzzer and several others resources described in [reference AT91SAM7A2]. Figure 2.6 shows the AT91SAM7A2 board. Signal Flow

As mentioned above, the AT90CAN128 Actor Board can operate based on two different sources to generate its PWM output. For that, the board offers a selection switch/jumper to choose between those models. By that one can select whether it uses direct input from the Sensor Boards or works based on the pre-processed data from the ARM7 board. Software description

The ARM7 board itself is not intended to directly access sensors or actors, it should merely process data from the CAN bus and produce control messages for the Actor Board. To enable access to all functionalities and components of the board C source code is provided. The source code eases the task of accessing board peripherals and makes software development a bit easier. Besides the resources listed above there is also code for dealing with interrupts, timers, SD Cards and so on.

The software of the board consists of a bootloader and of the application software. Platform software and run-time environment

The platform software is the basic software provided to access the board’s resources. The AT91SAM7A2 board provides basic software for the following hardware resources:

  • SPI
  • CAN
  • LED
  • GPIO
  • ADC
  • Buttons
  • Ethernet
  • Buzzer

The source code eases the task of accessing board peripherals and makes software development a bit easier. Besides the resources listed above there is also code for dealing with interrupts, timers, SD Cards and so on. Bootloader

The bootloader is the boards’ base software and is responsible for two main tasks: deal with low level configuration of the platform (PLL setup, AMC, GIC, peripherals, etc.), load the user application from SD Card into the main memory.

The bootloader is located on the external ash memory. It scans for a SD card and checks if it finds an appropriate filesystem with the specific application file on it. If the file is found on the card, it will be copied to the external SRAM and will be executed from there. There is no multi-tasking operating system with syscalls or similar.

The basic steps during bootloader execution are listed below:

  • Setup memory map
  • Setup interrupt vectors in internal RAM
  • Setup execution modes stack
  • Setup PLL
  • Initialize its data section
  • Configure peripherals
  • Load user application from SD Card
  • Branch to user application

The user application is loaded into the RAM starting from RAM address 0x00000000. This address is mapped to address 0x40600000 on the ARM processor. After loading the application to 0x40600000 the bootloader configures the Stack Pointer (SP) to point to address 0x40808ffc, which is the top of user application stack. Between application and stack more than 1MB is available. The bootloader also configures the interrupt mode stacks the processor uses when handling an interrupt or exception. This stack begins at address 0x409ffffc and extends until 0x409ffd08 with a size of 0xfc for each mode (Interrupt, Fast interrupt, Abort exception (data abort and prefetch abort) and Undefined exception).

The complete memory map before and after the boot is presented in the following.

  • a) Memory map

The board has a 4MB RAM memory accessed by the ARM processor. The access to this memory is configured by the ARM's AMC, which defines the address range for the external memory. Figure 2.7 presents the memory map before boot and Figure 2.8 the memory map after boot. Figure 2.9 presents the External RAM Memory map. For further details on the memory map please check the datasheet. User level

The user level code is responsible for executing more complex tasks and should not concern about low level details. For this reason there are peripheral access functions in order to provide simple communication to peripherals from user code. Any customization can be done on the user part and there are only a few restrictions on modifying user code. Actually the primary use of the board is for Simulink models execution but also other applications that are not derived from a Simulink model can be executed.

The application development and deployment process is explained in detail in Chapter 3.