Inner Pages

Abstract
Car infotainment is a very advancing area in automotive industry. In-

fotainment includes information-based media content and entertainment in
an eort to enhance passenger experience. The scope is endless. And cur-
rently they oer multiple options like AM/FM or satellite radio, CD/DVD
player for music and video, navigation system, multimedia, GPS, vehicle sta-
tus information, internet, Bluetooth, etc. The feature set is expanding. New
technological developments have advanced and converged to allow for more
services, entertainment and connectivity. Automotive-specic platforms and
OSs are available which enables multiple concurrent applications and a uid
user experience for car infotainment.
The Sound Subsystem is a major part of the infotainment system. It in-
cludes microphone, speakers, converters, audio processing devices, etc. There
are several options for audio. Passengers can stream audio from the Internet,
play back music from USB, Bluetooth, CD/DVD players, AM/FM radio etc.
SSI (Serial Sound Interface) is used for the transfer of digital audio data and
SPI (Serial Peripheral Interface) for transferring commands and messages in
the sound subsystem. SSI and SPI are standard serial interfaces. This project
includes the design and development of T-kernel RTOS based device drivers
for SSI and SPI devices in a latest Car Infotainment based SoC platform.
Also includes the study of various protocols involved in enabling smartphone
USB connectivity in an RTOS based development system.
Contents
1 INTRODUCTION 1
1.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 LITERATURE SURVEY 3
3 SYSTEM OUTLINE 6
4 SPI & SSI PROTOCOL 9
4.1 RSPI : SPI Controller . . . . . . . . . . . . . . . . . . . . . . 10
4.2 SPI Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1 8-bit Serial transfer for CPHA = 0 . . . . . . . . . . . 15
4.2.2 8-bit serial transfer for CPHA = 1 . . . . . . . . . . . 16
4.2.3 32-bit MSB First Transfer . . . . . . . . . . . . . . . . 16
4.2.4 16-bit MSB rst transfer . . . . . . . . . . . . . . . . . 17
4.2.5 8-bit MSB First Transfer . . . . . . . . . . . . . . . . . 18
4.2.6 2-bit LSB First Transfer . . . . . . . . . . . . . . . . . 19
4.2.7 16-bit LSB First Transfer . . . . . . . . . . . . . . . . 19
4.2.8 8-bit LSB First Transfer . . . . . . . . . . . . . . . . . 20
4.3 Serial Sound Interface (SSI) Protocol . . . . . . . . . . . . . . 21
4.4 Serial Sound Interface (SSI) . . . . . . . . . . . . . . . . . . . 21
1
4.5 SSI Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 RTOS CONCEPTS 29
5.1 General RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 T-Kernel RTOS . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.1 T-kernel RTOS Functions . . . . . . . . . . . . . . . . 31
6 SYSTEM DESIGN 39
6.1 Sound Application Framework For PLAY . . . . . . . . . . . . 39
6.2 High Level Design . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.1 Design Of Sound Subsystem Driver . . . . . . . . . . . 40
6.2.2 Sound Sub System Driver Design Flow Chart . . . . . 42
6.3 Low Level Design . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.1 Design Of Sound Driver . . . . . . . . . . . . . . . . . 52
6.3.2 Design Of SPI Driver . . . . . . . . . . . . . . . . . . . 55
6.3.3 Design Of SSI Driver . . . . . . . . . . . . . . . . . . 58
7 SYSTEM IMPLEMENTATION & RESULTS 62
7.1 Host PC Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2 Target Board Setup . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8 SOFTWARE & HARDWARE TOOLS 68
8.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.1.1 RTOS:T-kernel . . . . . . . . . . . . . . . . . . . . . . 68
8.1.2 Toolchain : RVDS 4.1(Real View Development Suite
v4.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.1.3 Debugger : eBinder v1.9 + Partner Jet loader . . . . . 71
8.1.4 Database:Tortoise Subversion SVN 1.7 . . . . . . . . . 71
8.1.5 Microsoft Visual C++ 2008 Express Edition . . . . . . 71
8.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9 CONCLUSION 73
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
List of Figures
3.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Master Slave SPI Implementation . . . . . . . . . . . . . . . . 10
4.2 SPI Master to Audio Codec Interfacing . . . . . . . . . . . . . 11
4.3 SPI Module Block Diagram (For 1 channel) . . . . . . . . . . 12
4.4 Transfer format(CPHA = 0) . . . . . . . . . . . . . . . . . . . 15
4.5 Transfer format (CPHA =1) . . . . . . . . . . . . . . . . . . . 16
4.6 32-bit MSB First transfer . . . . . . . . . . . . . . . . . . . . 17
4.7 16-bit MSB First Transfer . . . . . . . . . . . . . . . . . . . . 18
4.8 8-bit MSB First Transfe . . . . . . . . . . . . . . . . . . . . . 18
4.9 2-bit LSB First Transfer . . . . . . . . . . . . . . . . . . . . . 19
4.12 SI Half Duplex System . . . . . . . . . . . . . . . . . . . . . . 21
4.13 SSI Full Duplex System . . . . . . . . . . . . . . . . . . . . . 22
4.14 SSI Master interfaced to Audio Codec . . . . . . . . . . . . . . 23
4.15 Block Diagram of Serial Sound Interface . . . . . . . . . . . . 24
4.16 SSI Philips Protocol . . . . . . . . . . . . . . . . . . . . . . . 26
4.17 Padding zeros after data word length . . . . . . . . . . . . . . 27
4.18 No padding for System word length = data word length . . . . 27
4.19 MSB-rst and Left-aligned format . . . . . . . . . . . . . . . . 28
4
4.20 MSB-rst and Left-aligned format . . . . . . . . . . . . . . . . 28
5.1 RTOS kernel services . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Format of Messages using a MailBox . . . . . . . . . . . . . . 36
6.1 Sound Subsystem Driver block diagram . . . . . . . . . . . . . 41
6.2 Sound initialise() . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3 Sound open() . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4 Sound write() . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5 Sound read() . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.6 Sound cancel() . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.7 Sound close() . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.8 Sound uninitialise() . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1 Build Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.2 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.3 Loading the executable le to eBinder . . . . . . . . . . . . . . 65
7.4 Download to board using eBinder . . . . . . . . . . . . . . . . 66
7.5 Running the executable using eBinder . . . . . . . . . . . . . 66
7.6 Audio Jack connected to board . . . . . . . . . . . . . . . . . 67
7.7 Play running . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
List of Tables
5.1 Task Management APIs . . . . . . . . . . . . . . . . . . . . . 32
5.2 Task Synchronisation APIs . . . . . . . . . . . . . . . . . . . . 32
5.3 Semaphore APIs . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Event Flag APIs . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Mailbox APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.6 Interrupt Handler APIs . . . . . . . . . . . . . . . . . . . . . . 38
6
Sound Subsystem Driver Development for Car Infotainment System
Chapter 1
INTRODUCTION
Car Infotainment System includes information and entertainment services.
Information services are navigation, engine diagnostics, etc. Entertainment
services include audio, video, games, etc. All the services that we now have
in Smart phones and tablets can be provided by a Car Infotainment Sys-
tem. The Sound Subsystem of an Infotainment System takes care of the
audio requirements inside the car. The Sound Subsystem hardware includes
interfaces like SPI and SSI, ADC and DAC. It also includes microphones,
headset, speaker and other audio processing devices. SPI devices are used
for the transfer of audio commands and SSI is used for audio data transfer.
Also there is Bluetooth, USB and display interfaces to enable connecting to
Smart phones. Now users can stream audio from Internet, play back music
from USB, SD Card, CD/DVD players. And most importantly users can
now use their smart phones to listen to music inside the car by connecting
to the infotainment hardware.
This project includes Sound Subsystem driver development for SPI and
SSI devices and the driver runs on a Multimedia Framework. The driver
Department of Electronics and Communication, SJCET 1
will be POSIX-compliant and RTOS based and developed using C language.
The driver is developed for the embedded platform Eagle using ARM Cortex
A9 chip as the main processor. It is a 32-bit processor and is Little-Endian.
It has lot of peripherals like SPI, SSI, I2C, DMA, visual display control,
etc. The SPI and SSI Controllers in the hardware have features such as low
power consumption, multiple channel support, Tx/Rx FIFO support, noise
suppression and high performance.
1.1 Objective
To meet the audio requirements of the user in a car infotainment system
with optimizations on power, performance, noise suppression.
1.2 Scope
This project includes the design and development of device drivers for lat-
est SSI and SPI devices in market having lower power consumption, multiple
channel support, Tx/Rx FIFO support and noise suppression.
Chapter 2
LITERATURE SURVEY
For selecting a serial interface for transferring commands in the Sound Sub-
system, SPI and I2C protocols were compared in the initial stage and SPI
was selected as the Control Interface. Then the current infotainment plat-
form and previous platform was compared to identify the improved hardware
resources in current platform. The current platform is the Eagle platform
with an ARM Cortex A9 processor. Next, the dierent RTOSs used in info-
tainment were compared and the advantages of T-kernel RTOS used in the
project were identied. The detailed survey is given below.
In [12] A.K. Oudjida gives a comparative study on FPGA implementation
of I2C and SPI protocol. Both I2C and SPI are used for low bandwidth data
transfers. In comparison to I2C, SPI has a higher transfer rate, lower design
cost, full duplex communication and lower power consumption.
In [13] a comparison on Eagle Platform and the previous development
platform is given. Eagle platform has an ARM Cortex A9 as core processor
with 400MHz operating frequency. SH726X platform used SH-2A core with
maximum operating frequency of 144MHz. The new platform has improved
features like 10MB integrated SRAM, Serial high speed ash interface with
Execute-in-Place(XiP), support for booting from QSPI ash memory, 5chan-
nel SPI interface, 6channel SSI interface. SH7267 platform only supported 2
channel SPI interface and 4 channel SSI interface. The new platform includes
a Quad-SPI ash interface and external serial ash memory. This combina-
tion gives a performance improvement over previous implementations when
data-intensive applications like audio and graphics are used.
Both platforms had the latest SPI and SSI controllers in market. The
features include multiple channel support, lower power consumption, noise
suppression. The SPI Controller has features such as 5 channels, master mode
and slave mode selectable, programmable bit length, clock polarity, and clock
phase, consecutive transfers, MSB rst/LSB rst selectable, maximum trans-
fer rate: 33.33 Mbps. The SSI controller has 6 channel bidirectional serial
transfer, duplex communication (channels 0, 1, 3, and 5), support of various
serial audio formats, support of master and slave functions, generation of
programmable word clock and bit clock, multi-channel formats, support of
8, 16, 18, 20, 22, 24, and 32-bit data formats, support of eight-stage FIFO
for transmission and reception, etc.
The dierent RTOSs used in infotainment are QNX Neutrino, Windows
CE, Nucleus RTOS, VxWorks, etc. T-kernel RTOS is a traditional RTOS
which has monolithic architecture. This is the major dierence from other
RTOSs available in market. The other RTOSs have a microkernel archi-
tecture. The dierence between monolithic and microkernel architecture is
in that, in microkernel except for a few kernel services, all other services
like le systems and networking and other drivers runs in memory-protected
user space, whereas in monolithic, most services including le systems are
in kernel-space. The disadvantage of monolithic is that if any fault occurs
in le system or drivers the entire system may be aected. In microkernel,
these services run in isolated spaces without interrupting other services and
kernel. Thus microkernel provides memory protection, but there is over-
head caused by this feature as there is constant switching between user
space and kernel space which aects speed of system. Monolithic kernels
are faster and requires less context switching. The advantage of T-kernel
is that being a monolithic kernel, it oers more speed compared to a mi-
crokernel. Also it provides dynamic management of kernel objects and has
less memory constraints. So when compared to the existing sound systems
like ALSA(Advanced Linux Sound Architecture) for Linux OS, the T-kernel
RTOS based sound system is a customized ecient implementation with less
memory constraints and less bugs.
Chapter 3
SYSTEM OUTLINE
This gure shows the six layers, the hardware layer, driver layer, middle-
ware, framework layer, logical layer, application layer. The RTOS manages
the transfer between layers. If the use case is to play music from an audio
le present in a USB pendrive, then rst the pendrive is connected to the
boards USB port. The le from USB is automounted to the le system in
middleware layer. When play is called by the application, the audio les
from middleware layer is loaded to the application. Then, the logical layer
checks if the audio le format is supported or not. If the audio le format is
not supported, a message is displayed to the user that the audio le format
is not supported. Otherwise, the le is decrypted in framework layer and
passed to the driver layer. The driver layer decides whether the le goes to
SPI or SSI. Then SPI device is opened for transferring commands and SSI for
transferring audio to the DAC. From DAC, the analog audio is provided to
the speaker. Another use case is recording which can be explained similarly.
Figure 3.1: Block Diagram
What comes under each layer is described below:
1. Hardware layer
Includes the SPI and SSI controllers and the peripherals interfaced
to it, USB device and USB host controller, Audio Codec, Speaker,
Microphone, etc.
2. Driver layer
Includes the kernel mode driver for SPI and SSI Controller. Also USB
driver and DAC Control resides here.
3. Middleware
Includes the le system, USB Stack and Driver Abstraction layer(IOIF)
4. Framework layer
Includes POSIX library, audio libraries and decoders
5. Logical layer
Supports HMI for the user requirements.
Chapter 4
SPI & SSI PROTOCOL
The Serial Peripheral Interface (SPI) is a three or four wire bidirectional
synchronous serial data link standard. SPI operates in full-duplex mode with
a master device initiating communications and a slave device responding.
Data is passed in data frames which may consist of various number and size
of data words. Each signal line of the SPI bus is unidirectional, with the
primary signals being SCLK (serial clock), SS (slave select), MOSI (master-
out, slave-in), and MISO (master-in, slave-out). Therefore, a minimal system
consists of a single master and a single slave device. Figure shows a Single
Master Single Slave SPI system. Here the SS signal will be always active.
Multiple slave devices may be present on the bus simultaneously with the
individual slave enabled by the use of an SSL (slave select) signal. Each slave
will normally have its own unique select line.
In the hardware, there is a SPI Controller, RSPI which is described next.
Figure 4.1: Master Slave SPI Implementation
4.1 RSPI : SPI Controller
The SoC in Eagle platform has a SPI peripheral controller which enables
high-speed serial communication with multiple processors and peripheral de-
vices.
Features :
Five channels
Master mode and slave mode selectable
Programmable bit length, clock polarity, and clock phase can be se-
lected.
consecutive transfers
MSB rst/LSB rst selectable
Maximum transfer rate: 33.33 Mbps
Peripheral devices(SPI) can be connected to each SPI channel. The pe-
ripherals can be any SPI device like SD card, Serial ash memory, LCD,
ADC/D
Figure 4.2: SPI Master to Audio Codec Interfacing
Fig 4.2 shows SPI Peripheral Controller(master) interfaced to Audio Codec
(slave). SPI is used for conguring the audio codec for Power Management,
Volume Control of PGA inputs from microphone, Headphone & Speaker vol-
ume control, DAC & ADC Sample rate clock. The audio codec includes
ADC, DAC, PGA (Programmable Gain Amplier), Filters, Microphone in-
puts, Speaker and headphone outputs.
Fig 4.3 shows the block diagram of the SPI module. It includes a SPI
controller, a transmit FIFO, receive FIFO, baud rate generator, etc.
Figure 4.3: SPI Module Block Diagram (For 1 channel)
The dierent registers in SPI Controller are described below:
1. Control register
Includes functions to enable transmit interrupt, receive interrupt, error
interrupt; select master/slave mode
2. Slave Select Polarity register
Sets the polarity of slave select.
0 : 0-active
1 : 1-active
3. Pin control register
Sets MOSI idle value when SSL is inactive
4. Status Register
Includes receive buer full ag, transmit buer empty ag, transmit
end ag, mode fault error ag and overrun error ag
5. Data register
32-bit register for transmission and reception. Accessed in bytes, words,
and longwords.
6. Bit Rate register
Sets bit rate in master mode
7. Data Control register
Includes functions to enable dummy data transmission in master mode,
select access width(bytes, words or longwords).
8. Clock Delay register
Sets a delay from SSL active to clock oscillation
9. Slave Select Negation Delay register
Sets a delay from transmission of nal clock edge to negation of SSL
10. Next-Access Delay register
Sets a non-active period after termination of a serial transfer
11. Command register
Each channel can access 4 command registers sequentially in master
mode. The functions include: clock delay enable, SSL negation delay
enable, next-Access delay enable, LSB/MSB-rst, data length setting,
SSL level keeping, bit rate division setting, clock polarity and clock
phase
12. Sequence Control register
Sets the pattern when the module is performing sequential operations
in master mode. The 4 command registers are accessed sequentially
based on this pattern
13. Sequence Status register
Indicates the command register in use during a sequential operation
14. Buer Control register
Includes functions like transmit buer data reset, receive buer data
reset, transmit buer data triggering number, receive buer data trig-
gering number
15. Buer Data Count Setting register
Indicates the number of bytes to be transmitted in transmit buer and
the number of bytes received in receive buer
4.2 SPI Operation
4.2.1 8-bit Serial transfer for CPHA = 0
Fig 4.4 shows the transfer format for CPHA = 0. CPHA = 0 implies
sampling is done at odd edges of RSPCK clock. During sampling time module
fetches transfer data into shift register. For CPHA = 0, driving of valid data
to MOSI and MISO starts at SSL assertion. The rst RSPCK change timing
that occurs after SSL assertion is the rst transfer data fetching timing. The
change timing for MOSI and MISO is 12 RSPCK cycle after transfer data
fetch timing.
t1 : RSPCK delay
t2 : SSL negation delay
t3 : Next Access delay
Figure 4.4: Transfer format(CPHA = 0)
4.2.2 8-bit serial transfer for CPHA = 1
Fig 4.5 shows the transfer format for CPHA = 1. CPHA =1 implies
sampling is at even edges. When CPHA = 1, driving of invalid data to
MOSI and MISO starts at SSL assertion. The driving of valid data starts
at rst RSPCK change timing after SSL assertion. After this timing data is
updated at every 1 RSPCK cycle. The transfer data fetch timing is always
12 RSPCK cycle after data update timing.
Figure 4.5: Transfer format (CPHA =1)
4.2.3 32-bit MSB First Transfer
Fig 4.6 shows the 32-bit MSB First Transfer. The CPU or DMA controller
writes T31 to T00 to transmit buer of SPDR. If shift register is empty, this
module copies data in transmit buer to shift register. When serial transfer
starts, this module outputs data from MSB(bit 31) in shift register, and shifts
in the data from LSB(bit 0). After 32 RSPCK cycles, data R31 to R00 is
stored in shift register. If receive buer does not have a space for receive
data length, another serial transfer is not started. If another serial transfer
is started before CPU or DMA controller writes to transmit buer, received
data R31 to R00 is shifted out from shift register.
Figure 4.6: 32-bit MSB First transfer
4.2.4 16-bit MSB rst transfer
Fig 4.7 shows the 16-bit MSB First transfer. The CPU or DMA controller
starts, this module outputs data from bit 15 in shift register, and shifts in
data from LSB(bit 0). After completion of serial transfer, data that existed
before transfer is retained in bits 31 to 16 in shift register. The module copies
data from shift register to receive buer.
Figure 4.7: 16-bit MSB First Transfer
4.2.5 8-bit MSB First Transfer
Fig 4.8 shows the 8-bit MSB First transfer. The CPU or DMA controller
starts, this module outputs data from bit 7 in shift register, and shifts in
data from LSB(bit 0). After completion of serial transfer, data that existed
before transfer is retained in bits 31 to 8 in shift register. The module copies
data from shift register to receive buer.
Figure 4.8: 8-bit MSB First Transfe
4.2.6 2-bit LSB First Transfer
Fig 4.9 shows the 32-bit LSB First transfer. The CPU or DMA controller
module reverses order of bits of data in transmit buer, copies it to shift
register. When serial transfer starts, this module outputs data from MSB
(bit 31) in shift register, and shifts in data from LSB(bit 0). After 32 RSPCK
cycles, the module copies data from shift register to receive buer.
Figure 4.9: 2-bit LSB First Transfer
Fig 4.10 shows 16-bit LSB rst transfer. The CPU or DMA controller
module reverses order of bits of data in transmit buer, copies it to shift
register. When serial transfer starts, this module outputs data from MSB
(bit 31) in shift register, and shifts in data from bit 16. After 16 RSPCK
cycles, the module copies data from shift register to receive buer.
Fig 4.11 shows 8-bit LSB rst transfer. The CPU or DMA controller writes
T07 to T00 to transmit buer of SPDR. If shift register is empty, this module
reverses order of bits of data in transmit buer, copies it to shift register.
When serial transfer starts, this module outputs data from MSB (bit 31) in
shift register, and shifts in data from bit 24. After 8 RSPCK cycles, the
module copies data from shift register to receive buer.
4.3 Serial Sound Interface (SSI) Protocol
The SSI protocol basically consists of 3 lines : SDATA, BCLK, WCLK.
The clocks are generated by master which can be a transmitter or receiver.
The SDATA line carries multiplexed data channels. In a 2 channel case, the
SDATA will carry the left and right channels of audio data. Fig 4.12 shows a
half duplex SSI system. In this case, either transmission or reception occurs
at the any time. Fig 4.13 shows a full duplex system. Here, transmission
and reception can occur at the same time
Figure 4.12: SI Half Duplex System
4.4 Serial Sound Interface (SSI)
The SSI is designed to send or receive audio data interface with various
devices oering SSI bus compatibility. It also provides additional modes
for other common formats, as well as support for multi-channel mode. The
SoC has a SSI which handles the audio data through the sound subsystem.
Figure 4.13: SSI Full Duplex System
During audio playback, it transports digital audio to the audio codec which
is connected to external speakers or headsets.
Features :
Six-channel bidirectional serial transfer
Duplex communication (channels 0, 1, 3, and 5)
Support of various serial audio formats
Support of master and slave functions
Generation of programmable word clock and bit clock
Multi-channel formats
Support of 8, 16, 18, 20, 22, 24, and 32-bit data formats
Support of eight-stage FIFO for transmission and reception
Fig 4.14 shows the SSI interfaced to codec. During audio playback, it
transports digital audio to the audio codec which is connected to external
speakers.
Figure 4.14: SSI Master interfaced to Audio Codec
Fig 4.15 shows SSI Block Diagram. It includes a control circuit, trans-
mit FIFO, receive FIFO, bit counter, etc. In full duplex channels, channels
0,1,3,5 SSIDATA can be used independently as SSITxD for transmission and
SSIRxD for reception.
The dierent registers in SSI module are described below:
1. Control register
Includes functions to enable transmit underow interrupt, transmit
overow interrupt, receive underow interrupt, receive overow inter-
rupt, idle mode interrupt: select clock source, number of channels per
system word, number of system words per TDM frame, data word
length, system word length, serial bit clock direction, serial WS direc-
tion, serial bit clock polarity, serial WS polarity, data alignment, serial
Figure 4.15: Block Diagram of Serial Sound Interface
data delay, mute enable, transmit enable.
2. Status register
Includes transmit underow error interrupt ag, transmit overow error
interrupt ag, transmit channel number, transmit serial word number,
idle mode status.
3. Transmit data register
32-bit register holds data to be transmitted
4. Receive data register
32-bit register holds received data
5. FIFO control register
Includes transmit data trigger number, transmit interrupt enable, trans-
mit FIFO data register reset
6. FIFO status register
Indicates number of bytes stored in transmit data register, transmit
data empty, receive data full
7. Transmit FIFO data register
Consists of 8 stages of 32-bit registers for storing data to be transmitted
8. Receive FIFO data register
Consists of 8 stages of 32-bit registers for holding received data
9. TDM mode register
Includes functions to enable TDM mode, WS continue mode, set receive
direct data mute
10. Frequency change control register
Include functions to enable frequency change detection interrupt enable
11. Frequency change mode register
Sets maximum and minimum number of cycles of peripheral clock
12. Frequency change status register
Indicate current cycle count of peripheral clock
4.5 SSI Operation
The SSI bus (Inter-IC Sound bus) shown in g 4.16 is a 3-wire, half-duplex
serial link for connecting digital audio devices. The bus has three lines -
continuous serial clock (SCK), word select (WS), serial data (SD) and the
device generating SCK and WS is the master. The word select line indicates
the channel being transmitted: WS = 0 for channel 1 (left) and WS = 1 for
channel 2 (right).
Serial data is transmitted in twos complement with the MSB rst. The
MSB is transmitted rst because the transmitter and receiver may have dif-
ferent word lengths. It isnt necessary for the transmitter to know how many
bits the receiver can handle, nor does the receiver need to know how many
bits are being transmitted.
Figure 4.16: SSI Philips Protocol
When the system word length is greater than the transmitter word length,
the word is truncated (least signicant data bits are set to 0) for data trans-
mission, as shown in Fig 4.17 If the receiver is sent more bits than its word
length, the bits after the LSB are ignored. On the other hand, if the receiver
is sent fewer bits than its word length, the missing bits are set to zero in-
ternally. And so, the MSB has a xed position, whereas the position of the
LSB depends on the word length.
The transmitter always sends the MSB of the next word one clock period
after the WS changes as shown in Fig 4.18. This allows the slave transmitter
Figure 4.17: Padding zeros after data word length
to derive synchronous timing of the serial data that will be set up for trans-
mission. Furthermore, it enables the receiver to store the previous word and
clear the input for the next word.
Figure 4.18: No padding for System word length = data word length
Fig 4.19 shows the MSB-rst and Left-aligned format. Here data is trans-
mitted and received in the order of serial data and padding bits.
Figure 4.19: MSB-rst and Left-aligned format
Fig 4.20 shows the MSB-rst and Right-aligned format. Here data is trans-
mitted and received in the order of padding bits and serial data.
Figure 4.20: MSB-rst and Left-aligned format
Chapter 5
RTOS CONCEPTS
5.1 General RTOS
RTOS is a real-time operating system that supports real-time applications
and embedded systems by providing logically correct result within the dead-
line required. The kernel of an RTOS provides an abstraction layer between
the application software and hardware. This abstraction layer comprises of
six main types of common services provided by the kernel to the application
software. Figure shows the six common services of an RTOS kernel. For
Eagle platform, T-kernel RTOS is used.
5.2 T-Kernel RTOS
T-Kernel is a real-time operating system for embedded system use, ap-
plicable to a wide range of systems large and small. T-Kernel comes from
uITRON and it is older than GNU/Linux, managed by T-engine forum un-
der T-license. T-kernel is a traditional proven RTOS than any other in the
market which were supposed to run on some custom architectures. T-Kernel
Figure 5.1: RTOS kernel services
is so scalable that it can cover with a single kernel architecture a wide array
of systems.
The factors why T-kernel is chosen are:
1. Licensing terms (which aect cost) if we manufacture bulk of same
hardware with RTOS
2. Performance in custom hardware/arch and enhanced speed in ARM
architecture
3. Limitations are less and familiar to all developers as the same was used
from past 20 years.
4. More stable and bugs are less
5. Great debugging features(task level debugging/scheduler level) with
nice GUI options and proling also possible
6. File systems support
7. T-Kernel also has a function not provided in ordinary real-time ker-
nels: the dynamic management of kernel objects such as tasks and
semaphores to facilitate the addition of miscellaneous middleware and
device drivers.
8. T-kernel 2.0 provides time management functions in microseconds. Most
audio tasks require clocks with a resolution that is at least in the mi-
crosecond range.
5.2.1 T-kernel RTOS Functions
T-Kernel/OS provides the following functions:
1. Task Management Functions
2. Task Synchronization Functions
3. Synchronization and Communication Functions
4. Interrupt Management Functions
5.2.1.1 Task Management Functions
Task management functions are functions that directly manipulate task
states. Functions are provided for creating, for task starting and exit. A
task is an object identied by an ID number called a task ID.
The APIs under Task Management service are:
Table 5.1: Task Management APIs
API Functions
tk cre tsk Create Task
tk sta tsk Start Task
tk exd tsk Exit and Delete Task
5.2.1.2 Task Synchronization Functions
Task synchronization functions achieve synchronization among tasks by
direct manipulation of task states. They include functions for task sleep and
wakeup, for changing a task state to SUSPENDED state, for delaying task.
Table 5.2: Task Synchronisation APIs
APIs Functions
tk slp tsk Sleep Task
tk wup tsk Wakeup Task
tk sus tsk Suspend Task
tk rsm tsk Resumes a task in a SUSPENDED state
tk dly tsk Delay Task
5.2.1.3 Synchronization and Communication Functions
Synchronization and communication functions use objects independent of
tasks used to synchronize tasks and achieve communication between tasks.
The objects available for these purposes include semaphores, event ags, and
mailboxes.
1. Semaphore
A semaphore is an object indicating the availability of a resource and
its quantity as a numerical value. A semaphore is used to realize mutual
exclusion control and synchronization when using a resource. Functions
are provided for creating and deleting a semaphore, acquiring and re-
turning resources corresponding to semaphores. A semaphore is an
object identied by an ID number. The ID number for the semaphore
is called a semaphore ID.
A semaphore contains a resource count indicating whether the cor-
responding resource exists and in what quantity, and a queue of tasks
waiting to acquire the resource. When a task returns m resources,
it increments the semaphore resource count by m. When a task ac-
quires n resources, it decreases the semaphore resource count by n. If
the number of semaphore resources is insucient, a task attempting
to acquire resources goes into WAITING state until the next time re-
sources are returned. A task waiting for semaphore resources is put in
the semaphore queue. To prevent too many resources from being re-
turned to a semaphore, a maximum resource count can be set for each
semaphore.
Table 5.3: Semaphore APIs
APIs Functions
tk cre sem Create Semaphore
tk del sem Delete Semaphore
tk sig sem Signal Semaphore
tk wai sem Wait on Semaphore
2. Event Flag
An event ag is an object used for synchronization, consisting of a
pattern of bits used as ags to indicate the existence of the correspond-
ing events. Functions are provided for creating and deleting an event
ag, for event ag setting and clearing, event ag waiting. An event
ag is an object identied by an ID number. The ID number for the
event ag is called an event ag ID.
In addition to the bit pattern indicating the existence of correspond-
ing events, an event ag has a queue of tasks waiting for the event ag.
The event ag bit pattern is sometimes called simply event ag. The
event notier sets or clears the specied bits of the event ag. A task
can be made to wait for all or some of the event ag bits to be set. A
task waiting for an event ag is put in the queue of that event ag.
Table 5.4: Event Flag APIs
APIs Functions
tk cre g Create Event Flag
tk del g Delete Event Flag
tk set g Set Event Flag
tk clr g Clear Event Flag
tk wai g Wait Event Flag
3. Mailbox
A mailbox is an object used to achieve synchronization and commu-
nication by passing messages in system (shared) memory space. Func-
tions are provided for creating and deleting a mailbox, sending and
receiving messages in a mailbox. A mailbox is an object identied by
an ID number. The ID number for the mailbox is called a mailbox ID.
A mailbox has a message queue for sent messages, and a task queue
for tasks waiting to receive messages. At the message sending end,
messages to be sent go in the message queue. On the message receiving
end, a task fetches one message from the message queue. If there are
no queued messages, the task goes to WAITING state for receipt from
the mailbox until the next message is sent. Tasks waiting for message
receipt from a mailbox are put in the task queue of that mailbox.
Since the contents of messages using this function are in memory
space shared both by the sending and receiving sides, only the start
address of a message located in this shared space is actually sent and
received. The contents of the messages themselves are not copied. T-
Kernel manages messages in the message queue by means of a linked
list. An application program allocate space at the beginning of a mes-
sage to be sent called the message header. The message header and the
message body together are called a message packet. When a system
call sends a message to a mailbox, the start address of the message
packet (pk msg) is passed in a parameter.
Figure 5.2: Format of Messages using a MailBox
When a system call receives a message from a mailbox, the start
address of the message packet is passed in a return parameter. If mes-
sages are assigned a priority in the message queue, the message priority
(msgpri) of each message must be specied in the message header as
shown in gure
The user puts the message contents not at the beginning of the packet
but after the header part (the message contents part in the gure).
Table 5.5: Mailbox APIs
APIs Functions
tk cre mbx Create Mailbox
tk del mbx Delete Mailbox
tk snd mbx Send Message to Mailbox
tk rcv mbx Receive Message from Mailbox
tk rcv mbx u Receive Message from Mailbox (in microseconds)
tk ref mbx Reference Mailbox Status
5.2.1.4 Interrupt Management Functions
Interrupt management functions are for dening and manipulating han-
dlers for external interrupts and CPU exceptions.
An interrupt handler runs as a task-independent portion. System calls
can be invoked in a task independent portion in the same way as in a task
portion, but the following restriction applies to system call issuing in a task-
independent portion. A system call that implicitly species the invoking
task, or one that may put the invoking task in WAITING state cannot be is-
sued. Error code E CTX is returned in such cases. During task-independent
portion execution, task switching (dispatching) does not occur. If system call
processing results in a dispatch request, the dispatch is delayed until process-
ing leaves the task independent portion. This is called delayed dispatching.
Table 5.6: Interrupt Handler APIs
APIs Functions
tk def int Dene Interrupt Handler
tk ret int Return from Interrupt Handler
Chapter 6
SYSTEM DESIGN
6.1 Sound Application Framework For PLAY
//Audio le is opened for play
fp

fopen(a.wav,r)
//Sound driver function to initialise SOUND module is called
sound initialise()
//Sound driver function to open a sound channel0 is called
device ID = sound open(ch0,O WRONLY)
//Function to set bit rate, LSB or MSB rst, MOSI idle value, SSL polarity,
Serial data alignment, sampling rate, etc is called
sound ioctl()
//Audio le is read into a buer
fread(&buer,sizeof(buer),1,fp)
//Audio le is parsed to obtain audio data
data = parse()
//Function to write audio to headset is called
sound write(data.ssich0)
//After Play, audio le is closed
fclose(fp)
//Function to close sound channel is called
sound close()
//Function to uninitialise sound module is called
sound uninitialise()
6.2 High Level Design
6.2.1 Design Of Sound Subsystem Driver
The design of Sound Subsystem driver is shown in gure. First, the appli-
cation layer calls one of the functions init, uninit, open, close, ioctl, cancel,
read, write. These functions will be dened in IOIF layer. From IOIF,
associated sound driver functions like sound init, sound uninit, sound open,
sound close, sound ioctl, sound cancel, sound read, sound write will be called.
The Sound driver manages the device operation by controlling the SPI and
SSI drivers. During playback, audio is sent to the codec via SSI, and the
analog audio is fed to the speaker. SPI provides commands to congure the
codec. During recording, analog audio from microphone is oversampled in
the codec and the digital audio samples written to a sound le.
Figure 6.1: Sound Subsystem Driver block diagram
6.2.2 Sound Sub System Driver Design Flow Chart
Figure 6.2: Sound initialise()
Figure 6.3: Sound open()
Figure 6.4: Sound write()
Figure 6.5: Sound read()
Figure 6.6: Sound cancel()
Figure 6.7: Sound close()
Figure 6.8: Sound uninitialise()
6.3 Low Level Design
6.3.1 Design Of Sound Driver
1. sound initialise()
This function is called to initialise Sound driver. The function will:
Check module is uninitialized, if already initialized return error
Initialise a semaphore to be used by open() and close()
semid1 = tk cre sem(&csem info open)
semid2 = tk cre sem(&csem info close)
Initialise SPI and SSI channels
spi init()
ssi init()
Return driver instance or error code
2. sound open()
This function is called to open a sound channel ready for use. The
function will:
Check module is initialised
Check le mode ags are valid. Either:
O RDONLY for audio input(microphone)
O WRONLY for audio output(speaker/headphone)
O RDWR to support both
Check requested channel 0 is valid
Lock the open() access semaphore
ercd = tk wai sem(semid1,1,TMO FEVR)
Check the channel is not already open
Power up DAC
Open SSI driver, channel 0
handle SSI = ssi open(ch0,O WRONLY)
Open SPI driver, channel 0
handle SPI = spi open(ch0,O WRONLY)
Initialise channels state to READY
Unlock open() access semaphore
ercd = tk sig sem(semid1,1)
Return a handle or error code
3. sound ioctl()
This function is called when conguring the sound module.
spi ioctl()
ssi ioctl()
IOCTL SOUND GET SSI HANDLE : Get SSI handle for sound
driver
IOCTL SOUND MUTE : Mute/unmute audio
SNDCTL DSP CHANNELS : Set DAC to mono or stereo
SNDCTL DSP SPEED: Set sample rate. Either 11.025KHz, 22.050KHz,
44.100KHz
SNDCTL DSP SETFMT : Switch between big and little endian
samples
SOUND MIXER WRITE PCM : Set DAC attenuation
SNDCTL DSP GETFMTS : Find out which sound data formats
are supported(S16 LE and S16 BE)
Returns an error code
4. sound write()
This function called to write data to a sound device.
Channel state is changed to ACTIVE
Call ssi write() for audio data
Call spi write() for commands
If Play has to be stopped, call sound cancel()
5. sound read()
This function will be called to read data from a serial/microphone/audio
in.
Channel state is changed to ACTIVE
Call ssi read()
If playback, Call ssi write()
6. sound cancel()
The function is called to cancel a write or read request.
The function will:
Send Cancel Event
Cancel Event received in Tx/Rx task
Tx/Rx task blocked
7. sound close()
The function is called to close a sound channel after use. The function
will:
Lock close() access semaphore ercd = tk wai sem(semid2,1,TMO FEVR)
Check channel 0 is valid
Mute corresponding codec
Close SPI/SSI handle handle SSI = ssi close(ch0) handle SPI =
spi close(ch0)
Set channels state to CLOSE
Unlock close() access semaphore ercd = tk sig sem(semid2,1)
Return an error code
8. sound uninitialise()
The function is called to uninitialise sound driver. The function will:
Check channel 0 is not in use
Close SPI and SSI driver spi uninit() ssi unint()
Delete drivers open() and close() access semaphore tk del sem(&csem info open)
tk del sem(&csem info close)
Change channel state to UNINIT
Return error code
6.3.2 Design Of SPI Driver
1. spi init()
Create SPI read and write tasks tskid1 = tk cre task(&ctsk info spi read)
tskid2 = tk cre task(&ctsk info spi write)
Create SPI read and write semaphores semid3 = tk cre sem(&csem info spi read)
semid4 = tk cre sem(&csem info spi write)
Register callback for SPI read and write interrupts ercd = tk def int(dintno,TA HLNG,inthdr)
Callback function for SPI read and write declared void(spi read Callback)(int)
void spi write Callback(int)
Set pins MOSI, MISO, CLK, SSL
2. spi init()
Check requested ch0 is valid
Check le mode ags are valid
Congure SPI registers
PSCR 0=0x03 //sequence length 4
SPBR 0=0x00 //set bit rate as 33.33/2 MHz
SPDCR 0=0x20 //data register access width in bytes
SPCKD 0=0x00 //1RSPCK
SSLND 0=0x00 //1RSPCK
SPNP 0=0x00 //1RSPCK+2P1#
SPCMD 0=0x1401 //LSBF,16 bit,CPHA=1,CPOL=0
SPBFCR 0=0xC0 //TxTRG - 1byte, RxTRG - 31 byte
Return SPI handle
3. spi ioctl()
Functions to set Master/Slave mode, SSL polarity, MOSI idle
value, bit rate, Clock polarity, Clock phase, etc.
Set SPCR->MSTR //Master or Slave mode
Set SPCMD->BRDV //Baud rate
Set SPPCR->MOIFV //MOSI idle value
Set SPCMD->CPOL //Clock polarity
Set SPCMD->CPHA //Clock phase
4. spi write()
Lock SPI write semaphore
Task is blocked when transmit buer is empty
Check if transmit buer empty ag is set. If yes, call Callback
function to ll transmit buer.
if(spi->SPSR->SPTEF==1)
Callback()
Unlock SPI write semaphore
5. spi read()
Lock SPI read semaphore
Task is blocked when the space in receive buer is not enough for
the specied data length
Check if receive buer full ag is set. If yes, call Callback function
to read receive buer.
if(spi->SPSR->SPRF==1)
Callback();
Unlock SPI read semaphore ercd = tk sig sem(semid4,1)
6. spi close()
Close SPI handle
7. spi uninit()
If SPI ch0 not in use, delete SPI read and write semaphore
tk del sem(&csem info spi read)
tk del sem(&csem info spi write)
6.3.3 Design Of SSI Driver
1. ssi init()
Create SSI read and write tasks
tskid3 = tk cre task(&ctsk info ssi read)
tskid4 = tk cre task(&ctsk info ssi write)
Create SSI read and write semaphores
semid5 = tk cre sem(&csem info ssi read)
semid6 = tk cre sem(&csem info ssi write)
Register callback for SSI read and write interrupts
ercd = tk def int(dintno,TA HLNG,inthdr)
Callback function for SSI read and write declared
void(ssi read Callback)(int)
void ssi write Callback(int)
2. ssi open()
Check requested ch0 is valid
Check le mode ags are valid
Congure SSI registers
Set SSICR->DWL[2:0] // Set data word length
Set SSICR->SWL[2:0] // Set system word length
Set SSICR->SCKD // Set serial bit clock direction
Set SSICR->SWSD // Set serial WS direction
Set SSICR->SCKP // Set Serial bit clock polarity
Set SSICR->SWSP // Set Word select polarity
Return SSI handle
3. ssi ioctl()
Functions to set Master/Slave, WS polarity, bit clock polarity,
Serial data alignment, Sampling rate, data word length
Set SSICR->DWL //data word length
Set SSICR->SCKP //bit clock polarity
Set SSICR->SWSP //word select polarity
Set SSICR->SDTA //serial data alignment
4. ssi write()
Lock SSI write semaphore
Task is blocked if transmit buer is empty
Check if transmit buer empty ag is set. If yes, call Callback
function to ll transmit buer
If(ssi->SSIFSR->TDE==1)
Callback()
Check if transmit underow ag is set. If yes, task is put in waiting
state until transmit buer has data
If(ssi->SSISR->TUIRQ==1)
Clear ag, TUIRQ=0
ercd = tk slp tsk()
Check if transmit overow ag is set. If yes, transmission is dis-
abled and transmit buer is reset
If(ssi->SSISR->TOIRQ==1)
ssi->SSICR->TEN = 0 //transmission stopped
ssi->SSICR->TFRST = 1 //transmit buer reset
ssi->SSICR->TOIRQ = 0 //clear ag
Unlock SSI write semaphore
5. ssi read()
Lock SSI read semaphore
Task is blocked when space in receive buer is not enough to
receive specied data length
Check if receive underow ag is set. If yes, task is put to wait
state until new data arrives
If(ssi->SSISR->RUIRQ==1)
ssi->SSISR->RUIRQ = 0 //clear ag
ercd = tk slp tsk()
Check if receive overow ag is set. If yes, disable reception and
reset data in buer
If(ssi->SSISR->ROIRQ==1)
ssi->SSICR->REN = 0 //disable reception
ssi->SSICR->RFRST = 1 //reset receive buer
ssi->SSISR->ROIRQ = 0//clear ag
Check if receive buer full ag is set. If yes, call Callback
if(ssi->SSIFSR->RDF==1)
Callback();
Unlock SSI read semaphore
6. ssi close()
Close SSI handle
7. ssi uninit()
If SSI ch0 not in use, delete SSI read and write semaphore
tk del sem(&csem info ssi read)
tk del sem(&csem info ssi write)
Chapter 7
SYSTEM
IMPLEMENTATION &
RESULTS
7.1 Host PC Setup
The host PC development system was used to write the source code for
SPI, SSI, Sound driver, RTOS and application. Makele was generated and
the source code was cross- compiled with ARM RVCT compiler.
All source les and libraries were compiled and linked to obtain executable
which was then loaded to eBinder IDE for debugging and loading to board.
After connecting the serial cable from PC to the serial port of board and
connecting the USB port of PC and JTAG port in board, load option was
selected in eBinder. This starts downloading of the executable to board
via JTAG bus. Also the commands for running the board can be entered
through the PC terminal. While the code is being downloaded, green led in
the board blinks continuously. Next, a headphone is connected to the board
and a pendrive with a list of songs is plugged in. Then commands are entered
to play song, after which the song is heard through headphone connected to
board.
7.2 Target Board Setup
The target board consists of an SoC which includes an ARM Cortex A9
processor, SPI Controller, SSI Controller, USB Controller, Serial ash mem-
ory and peripherals like JTAG port, serial port, etc. There is an audio codec
with DAC/ADC unit outside the SoC. The target board is connected to PC
via a serial port for terminal connection and a JTAG port for debugging with
ICE. The application, T-kernel and bootloader and drivers are downloaded
to the board for functioning the sound subsystem.
7.3 Results
Fig 7.1 shows the build steps & Fig 7.2 shows the hardware setup. The
Sound Subsystem was build with T-kernel RTOS version 2.0, File System,
Boot Loader and other necessary drivers.In Fig 7.3 eBinder IDE is opened and
the executable le is loaded In Fig 7.4 the executable is loaded to board using
eBinder.In Fig 7.5, the debug option (F5) is selected and executable loaded
to board starts running.In Fig 7.6, audio jack of headphone is connected to
board.In Fig 7.7 the song is played and heard from the headphone. Also
song details and audio control are shown in terminal. This shows that Sound
Driver is functioning.
Figure 7.1: Build Steps
Figure 7.2: Hardware Setup
Figure 7.3: Loading the executable le to eBinder
Figure 7.4: Download to board using eBinder
Figure 7.5: Running the executable using eBinder
Figure 7.6: Audio Jack connected to board
Figure 7.7: Play running
Chapter 8
SOFTWARE & HARDWARE
TOOLS
8.1 Software
8.1.1 RTOS:T-kernel
T-kernel with File System, basic driver support and Boot Loader. T-Kernel
is the real-time operating system (RTOS) under the T-Engine Forum, Japan.
Features:
Strong standardization
The standardization includes kernel system call interface, the guide-
lines for the hardware execution, device driver model, etc. It also main-
tains a single unied source code governed by T-License. All these as-
sure middleware portability at source level among dierent platforms,
which is a key advantage for users to have freedom of not being depen-
dent on specic CPU vendors.
Hard real-time performance
T-Kernel is a high-performance RTOS based on ITRON whose real-
time performance is one of the best. The task dispatch time in the
T-Kernel is in the sub-microsecond range.
Dynamic resource management
Memory resource is dynamically managed; automatic assignment of
ID numbers of kernel objects, such as tasks and semaphores, facilitates
dynamic addition/loading of middleware and device driver.
Support of CPUs with/without MMU
T-Kernel can take advantages (e.g., memory protection) of MMU
(memory management unit), which is usually included in modern high-
functionality embedded processors. It can also operate on CPUs with-
out MMU.
Scalability into a more sophisticated system
T-Kernel is equipped with a mechanism called subsystem, which en-
ables kernel extension and the construction of both lightweight and
advanced systems on the same kernel.
8.1.2 Toolchain : RVDS 4.1(Real View Development
Suite v4.1)
RVDS 4.1 Professional enables build of high performance applications at
optimal code size by employing combination of ARM Compiler and ARM
Proler. RVDS 4.1 Professional also includes vectorizing compilation for
the NEON media processing engine which can increase the performance of
multimedia applications in standard C code by more than 200%.
Features:
Support for the latest Cortex-A9, Cortex-A5, and Cortex-M4 processors
The highly optimizing ARM Compiler, supporting all modern versions
of the ARM, Thumb and Thumb-2 instruction sets and supporting the
NEON SIMD instruction set with the vectorizing NEON compiler
Non-intrusive Streaming proling and Trace of software executing for
minutes, hours or days, while running at operational frequencies
Proler-driven compilation automatically optimizes software based on
its dynamic behaviour. This improves performance, by more aggres-
sively optimizing hotspots for performance, and code size, by more
aggressively optimizing cold code.
High performance software development using Real-Time System Mod-
els of complete ARM processor cores and boards running at around
200MHz.
Link-time code generation, which enables cross source-le optimization
while neatly tting into existing makele technology
8.1.3 Debugger : eBinder v1.9 + Partner Jet loader
eBinder is a powerful integrated development environment (IDE) for real
time operating system-based development.
Features:
Integrated development platform
Multi-tasking debug tools
System analysis tools
Real time debugging capability
Software engineering tools
8.1.4 Database:Tortoise Subversion SVN 1.7
Tortoise Subversion (SVN) 1.7 is a software versioning and revision control
system distributed under an open source license.
8.1.5 Microsoft Visual C++ 2008 Express Edition
IDE developed by Microsoft as a lightweight version of the Microsoft Vi-
sual Studio. It is used for doing source code editing and simulation in x86
environment.
8.2 Hardware
Eagle hardware development board based on ARM Cortex A9 processor
with necessary peripherals.
The Cortex-A9 NEON MPE features are:
SIMD and scalar single-precision oating-point computation
Scalar double-precision oating-point computation
SIMD and scalar half-precision oating-point conversion
8, 16, 32, and 64-bit signed and unsigned integer SIMD computation
8 or 16-bit polynomial computation for single-bit coecients
structured data load capabilities
dual issue with Cortex-A9 processor ARM or Thumb instructions
independent pipelines for VFPv3 and Advanced SIMD instructions
large, shared register le, addressable as:
thirty-two 32-bit S (single) registers
thirty-two 64-bit D (double) registers
sixteen 128-bit Q (quad) registers
Chapter 9
CONCLUSION
A background study on Car Infotainment System was done which helped to
identify the technology improvements that could be brought in to enhance
passenger and driver experience inside a car. The entire system is based
on a latest infotainment platform available in market, which has improved
hardware features to support the current requirements in this sector. The
improved hardware features include a processor with 10MB internal RAM,
SPI and SSI controllers with multiple channel support, Tx/Rx FIFO, low
power consumption. Kernel drivers have to be developed for the SPI and
SSI controllers.
The major work in this project included SPI and SSI controller driver
development and Sound Driver design. T-kernel APIs were used to achieve
synchronisation between various tasks in driver. The T-kernel Sound Subsys-
tem was run on the development board and play functionality was veried.
Bibliography
[1] T-kernel 2.0 Specication provided by Tata Elxsi,banglore
[2] ARM Cortex A9 Technical Reference manual
[3] SPI Specication provided by Tata Elxsi,banglore
[4] SSI Specication provided by Tata Elxsi,banglore
[5] IOIF User Guide provided by Tata Elxsi,banglore
[6] RX Serial Peripheral Interface(RSPI),, http :
==www:renesasinteractive:com=CoursePDFs=RXRSPI:pdf
[7] Inter IC Sound Bus,, http : ==www:eng:auburn:edu=:::=Inter IC-
Sound(SSI)Bus:pdf
[8] Qiu Jieting, Chen Rujun, He Zhanxiang, Qiu Kailin, Development of
Control system in electromagnetic acquisition station based on ARM and
Linux
[9] Ming He, Limin Dong, Wuchen Wu, Lu Kong, Chao Zhu, Zhonghua Zhou,
A Congurable SoC Platform Design Based on LEON Microprocessor
and Linux Operation System
[10] Dong-Hwan Park, Soon-Ju Kang, IEEE1394 OHCI Device Driver Ar-
chitecture for Guarantee Real-Time Requirement
[11] Hyo-Sang Lim, Dong-Hwan Park, Soon-Ju Kang and Bong-Jin Oh,
PRIORITY QUEUE-BASED IEEE1394 DEVICE DRIVER SUP-
PORTING REAL-TIME CHARACTERISTICS
[12] Oudjida, A.K., Berrandjia, M.L., Tiar, R., Liacha, A. FPGA implemen-
tation of I2C & SPI protocols: A comparative study
[13] www.renesas.com/products/mpumcu/superh/sh7260/

Inner Pages

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Inner Pages

Uploaded by

Copyright:

Available Formats

Abstract

Car infotainment is a very advancing area in automotive industry. In-

You might also like