Hardware for positioning applications using software defined radio : High speed interfaces with real time constraints

Hardware for positioning applications

using software dened radio

High speed interfaces with real time constraints

-Master Thesis performed in Computer Engineering,

Dept. of Electrical Engineering at Linköpings Universitet

David Karlsson

LITH - ISY - EX - - 06/3764 - - SE

Linköping 2006

Titel

Hardware for positioning applications using software dened radio High speed interfaces with real time constraints

-Master Thesis performed in Computer Engineering, Dept. of Electrical Engineering at Linköpings Universitet

by David Karlsson

LITH - ISY - EX - - 06/3764 - - SE

Supervisor: Per-Ludvig Normark, NordNav Technologies AB Examiner: Dake Liu

Abstract

This thesis has theoretically and practically evaluated interfaces between a radio front end for GPS and a mobile platform to answer the question how should this interface be designed to minimize the computational load on the platform as well as costs. Bench-marking of serial peripheral interface and a glueless one bit interface is performed on MPC5200 and OMAP 1710 running Linux operating system. The conclusion is two dif-ferent design approaches, one based on serial peripheral interface and one on SDIO card. Buer sizes in the platform and the front end is the key factor for computational load and this is discussed in detail. Also other consideration for interface design is discussed such as the implications of front end being master or slave on the bus.

Contents

1 Introduction 1

1.1 NordNav Technologies . . . 1

1.2 Purpose . . . 1

1.3 Outline and reading instructions . . . 2

2 Theory 3 2.1 GPS/Galileo . . . 3

2.1.1 Galileo . . . 3

2.1.2 A software receiver . . . 4

2.2 Embedded platform fundamentals . . . 4

2.2.1 Buers and FIFOs . . . 5

2.2.2 Direct Memory Access (DMA) . . . 6

2.2.3 Variable latency IO . . . 6

2.2.4 Bus master or slave . . . 7

2.2.5 Power consumption . . . 7 2.3 Interface details . . . 7 2.3.1 Secure Digital . . . 7 2.3.2 MultiMediaCard . . . 8 2.3.3 Memory Stick . . . 8 2.3.4 CompactFlash . . . 9

2.3.5 Other types of cards . . . 9

2.3.6 Universal Serial Bus . . . 9

2.3.7 IEEE 1394 . . . 9

2.3.8 SPI and other serial standards . . . 10

2.4 Evaluated platforms . . . 10

2.4.1 Interfaces for each platform . . . 12

2.5 Drivers for embedded operating system . . . 12 iii

iv CONTENTS 2.5.1 Linux . . . 13 2.5.2 Windows CE . . . 14 3 Evaluated interfaces 15 3.1 Selection process . . . 15 3.2 Benchmarking methodology . . . 16 3.3 Serial on MPC5200 . . . 16 3.3.1 Hardware . . . 17 3.3.2 Software . . . 17 3.3.3 Benchmarking results . . . 18 3.4 Parallel on MPC5200 . . . 18 3.4.1 Hardware . . . 19 3.4.2 Software . . . 20 3.4.3 Teoretical results . . . 20 3.5 Serial on OMAP 1710 . . . 20 3.5.1 Hardware . . . 20 3.5.2 Software . . . 20 3.5.3 Benchmarking results . . . 21 3.5.4 Verication . . . 21 4 Discussion 23 4.1 Platform classication . . . 23 4.1.1 DSP . . . 23 4.1.2 General computing . . . 23 4.1.3 Mobile communication . . . 24

4.2 Master or slave - the need of buers . . . 24

4.2.1 Front end is master . . . 24

4.2.2 Front end is slave . . . 24

4.3 Choice of interface . . . 25

4.3.1 The "Less is more" approach . . . 25

4.3.2 The "Extra everything" approach . . . 26

4.3.3 Reasons for exclusion . . . 26

5 Conclusions 29 5.1 Recommendations . . . 29

CONTENTS v

Bibliography 31

Appendixes

A Acronyms 33

Chapter 1

Introduction

This chapter contains some general information about this thesis. Here you will nd an introduction to NordNav Technologies and their products as well as where this thesis is needed in their current development. The last section cover reading instructions for the thesis.

1.1 NordNav Technologies

NordNav Technologies is a company that develops and licenses real-time software for GPS and Galileo positioning system. Their knowledge is focused on software dened radio application for processing of satellite signals to acquire a position and time. They are not focused on the user application that presents graphical user interfaces often with digital maps for helping the user to navigate.

Currently they have two product segments, one Rx range that is a PC-based software receiver for research, development and verication and the Ex range that targets the embedded market. This is a solution for easy integration of positioning services into products for automotive, personal (PDA and mobile technology), marine and aviation.

1.2 Purpose

This thesis has been done for evaluating some possible design alternatives as well as serve as a pre study for the design decisions needed when building or buying a radio frequency front end IC that work well together with their target platforms. The problems with many of today's commercially available RF front ends are that they output data in the same way as an analogue to digital converter (clock and parallel data). This generally puts a high computational burden on the processing element to act on each and every sample. Nordnav are looking into building or buying a more competent RF front end that ease the computational load on the processing element.

The purpose of this thesis is to answer what interfaces are good and bad for the Nord-nav software reciver application and their respective costs in terms of computational load, pin count and complexity of hardware. The study has been limited to some for NordNav

2 Chapter 1. Introduction important platforms and includes both hardware development and benchmarking using custom made drivers as well as theoretical studies of alternatives for comparison.

1.3 Outline and reading instructions

This chapter has presented the general purpose and method of this thesis. In the follow-ing chapter the theory used for drawfollow-ing conclusions and makfollow-ing recommendations are presented. This include a short introduction to the NordNav Ex application as a software dened radio for GPS, fundamental concepts for embedded platforms, a presentation of some high performance interfaces and a study of several platforms for comparison. Chap-ter 3 presents the developed drivers and the evaluation process.

The main chapter in this thesis is chapter 4 where a discussion about possible design alternatives is performed. This is then summarized in the nal chapter conclusions. For a quick overview of this thesis start by reading these chapters and use chapter 2 and 3 for clarication in areas you nd more interesting or need more background information about.

This thesis contains quite many acronyms and in appendix A a list of commonly used ones are presented with short descriptions.

For ease up the reading most hands on recommendations has been left out in the text in chapter 4 and 5. These recommendations is instead found in appendix B.

Chapter 2

Theory

This chapter holds background information for understanding conclusion and decisions taken later on. It also summarizes the studied platforms.

2.1 GPS/Galileo

There are several systems for positioning existing today, the most commonly used is GPS. This is owned and controlled by the US department of defence but the service has been provided free of charge since the year 2000. The positioning technique is to measure distances to four satellites in orbit around the globe and solve a system of equations resulting in a known tree-dimensional position and time. [15]

The GPS service globally needs 24 satellites orbiting the earth and constantly sending out a signal for identication and ranging. In practice they are a few more for redundancy. All satellites transmit on the same frequency with CDMA modulation which minimizes the interference between dierent satellites. [15]

The signal consists of three components. A carrier, a ranging code which is a unique sequence of ones and zeros assigned to each satellite and navigation data. The ranging code is used to identify a satellite and make precise range measurements. The navigation data is a message of the satellites health status, position, velocity and other information needed for accurate positioning. [15]

2.1.1 Galileo

The European Union have plans of launching their own set of satellites that should be working similar to the GPS satellites but under the control of the European Union. [15] They will send on the same frequency but with dierent identication codes for the satellites making them interoperable and independent of the GPS system. Receivers will be able use one or both of the systems. The antenna and radio frequency front end will be able to handle both systems. However the digital signal processing parts will dier for the two systems. Receivers capable of handling both systems will benet in position accuracy and overall performance. [20]

4 Chapter 2. Theory

2.1.2 A software receiver

There are several steps of signal processing between the antenna and a position given in latitude and longitude. This section will walk through them from a data processing per-spective. Focus is not a mathematical detailed level but to give a general understanding of what type of signal processing that has to be performed and it's load on a software dened radio (SDR) in general positioning applications.

The signal processing starts with an antenna connected to a radio frequency front end that lters and down convert the signal before it is converted to digital samples. This is solved by analogue ASICs and is the only hardware signal processing needed by a SDR, after this some form of CPU or DSP and software are used for signal processing. Commercially available front ends typically outputs samples of one to four bits at sampling rates at slightly more than 16 MHz. In some application with less precise positioning constraints the sample rate are decimated so the application only use one out of two, three or four samples. This gives bit rates in the range of 4 Mbit/s to 70 Mbit/s. [7]

Next is per channel baseband processing. For a position x there must be at least four parallel channels in the receiver that can handle the acquisition and tracking of satellite signals. The result from the acquisition stage is which satellites the receiver should track based on the carrier to noise gure for the signals from the dierent satellites. [7]

Tracking is the process of extracting exact timing information from the received signals. This is the computational most intensive task of a SDR and includes several correlations and conversion of the incoming samples to baseband in-phase and quadrate components. In this correlation algorithm it is very important that no samples are missed so care has to be taken to ensure that a miss of samples doesn't happen undetected. [7] The last part of the receiver is the data processing that decodes the incoming data bits. Bit rate for GPS data is about 50 bit/s. First a bit transition in the incoming signal has to be detected and after that 10 words of 30 data bits each are decoded into something called a navigation data subframe. The GPS satellites constantly send 5 dierent subframes over and over again and three of them hold information needed for positioning. Typically, all needed data is received after tracking a satellite for 18 to 36 seconds. This data is then used from all four channels for solving a position and time system of equations. [7]

The position and time are then fed to a user application that present it to the user and may combine it with maps and other features making it into a navigation application or utilising it in some other type of service. But these parts are far beyond the scoop of this thesis.

2.2 Embedded platform fundamentals

This section briey describes some hardware functions that exist in many of today's embedded platforms. The information is provided for readers that are not familiar with these mechanisms because they are discussed and referred to later in the thesis.

2.2. Embedded platform fundamentals 5

2.2.1 Buers and FIFOs

Buers are memory areas that stores data while they are transferred between a producer and consumer. This is a mechanism for handling speed mismatch in between the devices. With a double buer design two buers are used, one for the producer and one for the consumer. When the producer has lled the rst buer it signals to the consumer and start to ll the other buer. Before this signal comes the consumer has to be nished with it's buer or there will be risk of data loss due to the fact that the producer overwrites the data in the buer the consumer reads from. Properly congured the consumer always nish before the signal comes that indicate a buer switch. 1 _[25]

The double buer design could be stretched to use more than two buers. In this way a linked ring of buers are used. When producer have lled one buer it moves to the next, as do the consumer. If producer comes to the same buer as the consumer the data loss may occur and it needs to be detected.

FIFO-buers are a special kind of buer ring with one word (or byte) in each buer and a large number of buers in the ring. FIFO stands for First-In-First-Out and is sometimes also called a queue.

Generaly it is easy to calculate the time to ll a buer of a given size from a data stream of given data rate.

Time to ll buer [seconds] = _{Data rate into buer [Bytes/second]}Buer size [Bytes]

As this thesis deals with a data stream from the radio front end that is constant over time this formula describes the process well. This formula can be used to determine time between buer switch in a double buer solution or for how long time a FIFO may be lled from a producer without emptying it. [25]

When a buer is constantly lled by a stream at certain data rate and emptied by a read burst when necessary for not overowing the buer the behaviour may be illustrated as in gure 2.1. Interrupt in that gure has been somewhat simplied as there are variable response time for an interrupt handler thus resulting in a safety margin has to be added in all buers. The angle of the slope indicates the data rate into the buers when slope is positive (denoted I) and the dierence of input and output data rate when negative (denoted I and O).

From the gure one conclusion can be drawn; if it is not possible to have the exact same speed the output data rate should be set as close to (but higher than) the input data rate to maximize the time between interrupt.

1 _{In the long run the consumer always has to be faster than the producer and this long run should}

6 Chapter 2. Theory

B:

Output slightly faster than input A:

Exact same speed

C:

Output much faster than input

Time B u ff e r u s a g e 0 % 1 0 0 % Constantly I & O Time B u ff e r u s a g e 0 % 1 0 0 % I & O I Time B u ff e r u s a g e 0 % 1 0 0 % I & O I I I & O I I & O Time between interrupt

Time between interrupt

Time between interrupt is unlimited

Figure 2.1: Dierences in input and output data rate's inuences on time between in-terrupt.

2.2.2 Direct Memory Access (DMA)

One common burden for IO systems is transfers of large blocks of data between the main memory and an IO device2_{. To ease up this burden many computers have a DMA}

controller that can be assigned a transfer task of a certain buer between two memory addresses. The controller is connected to the memory bus and shares it with the processor in some arbitration scheme that gives both a fare share of the bus bandwidth. The DMA controller moves word after word of data between a source and a destination until the whole buer is transferred and it will then interrupt the processor and be ready for a new task. [25]

An active DMA controller will probably hog the bus sometimes when the processor needs it forcing the processor to stall waiting for access to the bus, but with a proper congured arbitration between the DMA and the processor this stall is feasible compared to let the processor move each word needed in large block transfers. [25]

2.2.3 Variable latency IO

Memory mapped interfaces resides on a memory bus and presents register for control and data in- and output as memory locations on this bus. This bus uses several chip select signals for enabling the correct chip to address. This can be a mixture of Boot ROMs, ash memories and other memories as well as other peripheral hardware. Variable

2 _{The transfer can also be in between dierent memories on or o chip or directly between two IO}

2.3. Interface details 7 latency IO denes a communication protocol on this bus that besides the normal signals (Chip select, Read/Write, Address, Data) also have a signal from the peripheral chip indicating when it has presented data on the data lines or is done with sampling presented data. This is dierent from ROM whose timing characteristics normally are coded in the memory controller resulting in a constant wait of a certain number of clock cycles. With variable latency IO this wait will depend on the peripheral and may be dierent for each and every memory operation. [9, 10, 22]

2.2.4 Bus master or slave

One of the rst thing to decide in bus interface design is to chose which device that should be master and be able to initiate a data transfer and which device that should be slave and only be able to respond to actions taken by the master. One solution is to give both (all) devices the possibility to become master and overcome this problem but that comes with the cost of some arbitration logic on the bus that determines which device should be master at any given moment. [26]

2.2.5 Power consumption

In regular CMOS ICs the power consumption is mainly dependent on three factors: • Supplied voltage in square

• Number of logic switches • Leakage to substrate

The number of logic switches is the easiest factor to save power with. By lowering the clock frequency the switches occur more infrequent and less active logic gates means fewer switches at each clock pulse. The supplied voltage and leakage is more dependent on the technology used for manufacturing the IC. [29]

2.3 Interface details

In the following sections some high speed interfaces are presented. All of them exist in one or more of the studied platforms.

2.3.1 Secure Digital

SD and SDIO are standards for expansion cards for consumer electronics owned and licensed by the SD Card Association. The full size card is roughly the size of a coin but there are specications for even smaller cards called miniSD and microSD all with the same interface standard except for physical dimensions [24]. The interface specication in the standards prescribes three modes of operation; SD-1bit, SD-4bit and SD-SPI. The SD-1bit and SD-SPI are compatible with the original MultiMediaCard (MMC) standard and oer moderate performance, using a serial protocol and a 20 MHz bit clock. The

8 Chapter 2. Theory SD-SPI is physically similar to SPI protocol described in 2.3.8 but the SD specications also denes a software protocol with about the same read and write commands as for SD-1bit and SD-4bit modes. [30]

The SD-4bit mode uses the same software protocol as SD-1bit but transmits data on 4 parallel wires with a bit clock at up to 25 MHz, resulting in a maximum bit rate at 100 MBit/s. The transfer is protected by built in CRC-checks and in general the host controller handles this CRC-generation and check in hardware for minimizing the computational needs in software. There is also content protection built into the standard for ensuring that copy right protected material is not easily copied if distributed on an SD card. [30]

It is possible to connect several SD-1bit and SD-4bit cards to the same electrical bus for sharing the host controller but this will result in a performance loss when switching has to be performed in between dierent cards. It is therefore not recommended in such situations when switching has to be performed often according to Codetelligence. [30]

The dierences between SD and SDIO is a extended command set for doing IO over the SD bus but most important an interrupt line is introduced making the SDIO card able to request service from the CPU. Further a data read suspending mechanism is introduced with similar functionality as VLIO described earlier. [30]

To use the SD/SDIO card standard in any of the modes a membership is required for development starting at $1,500 per year, another $1,000 is needed for a license for Host/Ancillary products. If the card doesn't contains any memory it is royalty free for production. [23]

2.3.2 MultiMediaCard

MultiMediaCard (MMC) is the standard that the SD card is based on but the MMC standard has also been evolving and it's latest version 4.0 supports transfer rates at 416 MBit/s with up to 8 parallel data lines. However none of the studied platforms has native support for this new version of the standard. The use of the standard is royalty free, but a membership in MultiMediaCard Association that starts at $2,500 per year is required for those companies that manufacture, design or implement MultiMediaCards. [18]

This standard currently only discusses it's use as a memory device but an IO standard for MMC, similar to SDIO for SD-card, is under development but no time plan for this standards settlement is presented. [18]

2.3.3 Memory Stick

Most of the studied platforms but OMAP 1710 lack native support for Memory Stick. In that case they need external circuits to interface Memory Sticks. The maximum transfer rate for the Memory Stick according to the standard is 157.6 MBit/s, high enough for NordNav Ex. The lack of native support and the various host controllers that may be used in dierent platforms between the CPU and the card slot makes it hard to predict it's CPU load and useful transfer rate in general. The standard is proprietary of Sony

2.3. Interface details 9 Corporation and the license fee is Yen 500,000 per year (about $4,100 in 2005-12-12). Royalties are not discussed on the memorystick.org webpage. [14]

2.3.4 CompactFlash

CompactFlash is a parallel interface that is electrically compatible with PCMCIA-ATA standard for storage devices such as hard disk drives. It has native support in some of the studied platforms and oers transfer rates at up to 528 MBit/s. It oers possibility for interrupts to the host controller and pauses controlled by the device during burst transfers. [3]

2.3.5 Other types of cards

There are several other types of removable storage standards such as SmartMedia and xD-picture card. None of them seems to have any future as a common standard for the embedded market because the work in the respective standard association is put on hold and there are some articles describing how they loose market share to other standards. For xD-picture card the standard body don't aim the standard to be used in anything else than cameras. These standards have not been studied further because of this.

2.3.6 Universal Serial Bus

Universal Serial Bus (USB) is an open standard that is available for everyone to use. But for using the special logotype on hosts and devices testing and verication has to be performed to ensure that the device fulls the standard. [28]

The 2.0 revision of the standard was settled in the year 2000 and this describes transfer rates at up to 400 Mbit/s. The system works as a bus connected in a star topology consisting of one host and one or many hubs and functions. In between each and every one of these are point-to-point electrical connections. Data transfers may be message based initiated by the host or streams that are initially set up by the host but then controlled by either the host or function. This can ensure that buers are not overowed or underowed in functions. [28]

Hosts in the USB 2.0 specication are dierent in hardware compared to devices (hubs and functions). This gives problem if for example a camera is a USB device when connected to a PC but it would also be nice to be able to connect it directly to a USB printer and act as a host in that communication.

To solve this problem USB On-The-Go (USB OTG) specication were released 2001 that allow devices to be host or function dependent on the cable connected to it. One type of connector is used at host side and another on the function side. But both connectors t the USB connector on an USB OTG compliant device. [21]

2.3.7 IEEE 1394

The standard IEEE 1394 with amendments 1 and 2 describes a serial protocol and physical layer for connection of devices in a varying physical topology. The bus is

self-10 Chapter 2. Theory conguring meaning that it doesn't need to be a xed master on the bus. The rst version of the standard from 1995 denes data rates at up to about 400 MBit/s; this is upgraded in later amendments to the standard. [8]

This standard is supposed to be easy to implement and very cost eective for con-sumer products requiring high bandwidth communication between devices. [26]

The name FireWire is one name for implementations of the IEEE 1394 in consumer products. For implementations of the standard a royalty for each product has to be paid to patents holders thru a patent portfolio license maintained by MPEG LA currently at $0.25 per device implementing the standad [16].

2.3.8 SPI and other serial standards

Serial Peripheral Interface (SPI) is general standard for serial data in it's most native form with four wires; Clock, Chip select/Syncronization, Data in and Data out. One device is master and the other in this point to point connection is slave. For connecting several slave devices to one master they all share the clock and data signals but the Chip select/Syncronization signal is separate for each and every slave device. The name SPI was introduced by Motorola but functionally equivalent protocols is common in embedded platforms today. [6]

Some platforms has some general serial port that is programmable to handle SPI as well as other serial protocols with the possibility to change clockpolarity, time between synchronization signal and data as well as word length. The possibilities vary between each platform but the mentioned ones are common. [1, 6, 27]

2.4 Evaluated platforms

There are a large number of embedded platforms that is suitable for NordNav Ex appli-cation. This section will present the platforms that have been studied during this thesis work to get a general idea of which interfaces exists and how much throughput they can handle.

First come quotes from the manual for each and every platform to indicate their target system. After that interfaces for each platform are summarized in tables.

Freescale MPC5200

The digital communication networking and consumer markets require signicant proces-sor performance to enable operating systems and applications such as VxWorks, QNX, JAVA and soft modems. High integration is essential to reducing device and systems costs. The MPC5200 is specically designed to meet these market needs while building on the family of microprocessors that use PowerPC architecture. [6]

2.4. Evaluated platforms 11 Texas Instruments OMAP1710

OMAP1710 is the next generation of OMAP processors and succeeds the Texas In-struments OMAP1610 processor. Like its predecessor, it is fully programmable to per-form one or more of the following personal communication system tasks: Call manager, Mail/fax reader/composer, Internet access, Personal digital assistant (PDA), Personal information management (PIM), Multimedia engines. This system is optimized for var-ious multimedia codecs, such as: MPEG4, MP3, JPEG. Furthermore, it is capable of running advanced speech applications: Text to speech, Speech recognition, Audio modem riser [27]

Analog Devices Blackn 53x

The ADSP-BF531/ADSP-BF532/ADSP-BF533 processors are highly integrated system-on-a-chip solutions for the next generation of digital communication and consumer multi-media applications. By combining industry-standard interfaces with a high performance signal processing core, users can develop cost-eective solutions quickly without the need for costly external components. [1]

Samsung S3C2410

This product is designed to provide hand-held devices and general applications with cost-eective, low-power, and high-performance micro-controller solution in small die size. [22]

Intel Xscale PXA255 & PXA27x

It is an application specic standard product (ASSP) that provides industry-leading MIPS/mW performance for handheld computing applications. The processor is a highly integrated system on a chip and includes a high-performance low-power Intel XScale microarchitecture with a variety of dierent system peripherals. [9]

Designed from the ground up for wireless clients, it incorporates the latest Intel advances in mobile technology over its predecessor, the Intel PXA255 processor. The Intel PXA27x processor redenes scalability by operating from 104 MHz up to 624 MHz, providing enough performance for the most demanding mobile applications. [10]

Neomagic MiMagic 6+

The MiMagic 6+ Multimedia Applications Processor is the heart of a complete mobile multimedia content and communications device. Its unique high-performance multi-media engine delivers quality video encoding and decoding and high performance 3D graphics at very low power consumption. A rich set of peripherals, including USB On-The-Go, Memory Stick Pro, Magic Gate, and SD Card, oer many options for device connectivity. And it's all on a single chip. [19]

12 Chapter 2. Theory

2.4.1 Interfaces for each platform

The following three tables presents the above mentioned platforms basic data (table 2.1) and interfaces that is available on each platform (table 2.2-2.3). Some interfaces have been left out for simplicity. These are interfaces that are not able to handle data rates above 5 MBit/s as this is the absolute minimum needed by NordNav Ex application. Also some highly specied interfaces for connection of GSM modem on the mobile plat-form and such has been left out as these is not pratically possible to use in a future product implementation. Interfaces have been divided into two groups; with standard-ized connectors that possibly are available outside an embedded platform and and those interfaces that connects with custom connectors or soldered in place on the PCB.

Generally the programmable serial port may be congured for SPI and use that ports maximum data rate in transfers.

Company Platform name Maximum clock frequency Freescale MPC5200 528 MHz

Texas Instrument OMAP1710 200 MHz Analog Devices Blackn 53x 600 MHz Samsung S3C2410 266 MHz

Intel PXA255 400 MHz

Intel PXA27x 624 MHz

NeoMagic MiMagic6+ 250 MHz Table 2.1: Studied platforms basic data. Platform SD/SDIO MMC CompactFlash USB

MPC5200 Yes 12 MBit/s, Host

OMAP1710 Full support Yes 12 MBit/s, OTG Blackn 53x

S3C2410 Full support Yes 12 MBit/s, Host or Device PXA255 MMC-1 bit, Yes 12 MBit/s, Device

SPI-mode

PXA27x Full support Yes Yes 12 MBit/s, OTG MiMagic 6+ Full support Yes Yes 12 MBit/s, OTG

Table 2.2: Interfaces with standardized connectors for each platform.

2.5 Drivers for embedded operating system

One important part of the operating system is to control connected hardware resources by device drivers. Drivers are responsible for transfer information to and from the device and if implemented handle interrupts from the device to the operating system. [25]

2.5. Drivers for embedded operating system 13 Platform SPI Programmable ROM/RAM Flash Memory

serial port

MPC5200 33 MBit/s 33 MBit/s Yes Yes OMAP1710 19.2 MBit/s 100 MBit/s Yes Yes Blackn 53x 67 MBit/s 33 MBit/s Yes Yes

S3C2410 33 MBit/s Yes, VLIO Yes

PXA255 13 MBit/s Yes, VLIO Yes

PXA27x 13 MBit/s Yes, VLIO Yes

MiMagic 6+ 9.216 MBit/s Yes, VLIO Yes Table 2.3: Other high speed interfaces for each platform.

There are two trends on device drivers. One towards increased standardization of software and hardware interfaces. This facilitates the incorporation of new devices into already existing computer systems. The other trend is towards a larger variety of devices making each and every one unique and in the need of custom designed drivers. Unique may be in terms of physical hardware interface, control signals and size and handling of buers. [25]

This thesis purpose has not been set with any specic operating system in mind as the hardware interface performance is not that aected by the operating system as long as it implements and uses a given architectures all benecial hardware. For the evaluation and benchmarking part of this thesis Linux has been used as this was the installed system on the existing evaluation boards used.

Besides Linux, as an environment for drivers, Windows CE has been studied for comparision.

2.5.1 Linux

For the Linux operating system, support for USB 2.0 has existed for several years from the open source project at www.linux-usb.org. This is well proven code base that is integrated in Linux kernels 2.4.x and 2.6.x3_{. [12]}

The IEEE1394 driver for Linux is stable but a kernel version 2.6.12 or later is rec-ommended [13]. CompactFlash cards are handled as mountable storage such as a hard disk drive and have native support in Linux.

SD/SDIO cards have no open source project because of licensing issues with SD-CARD Association but several commercial alternatives exists that provides full support for the modes SD-4bit, SD-1bit as well as SD-SPI. Some of these drivers also have support for MMC. [2, 4, 5]

For more platform specic interfaces such as the SPI interface on OMAP1710 it is rare to nd any drivers that are generic enough to be able to fully utilise for the NordNav Ex application and it will probably has to be written specically for each platform.

14 Chapter 2. Theory

2.5.2 Windows CE

Windows CE 5.0 has drivers for SD/SDIO, MMC, USB and IEEE 1394. As for Linux the platform specic interfaces such as SPI needs custom drivers. [17]

For both Linux and Windows drivers there is a need to write a high level NordNav Ex driver that utilise the existent driver to receive data and wraps it up in correct data blocks suitable for the acquisition and tracking in NordNav Ex. But these drivers will, if it exist a low level driver, be portable between dierent platforms.

Chapter 3

Evaluated interfaces

The implementations that have been done are described in detail and their results in benchmarking are reported.

3.1 Selection process

There are several platforms and every platform have several possible ports that possibly could be used for interfacing an RF front end chip. The process of deciding which solutions to implement and benchmark has been based on the following criterions.

• The platform should be interesting for Nordnav software receiver products. • The port should cope with the demands on transfer rate of the application. • The solution should give a good general understanding of the platform. • Both serial and parallel interfaces should be tested.

• The development time should t within this thesis work.

Based on this the decision was taken to implement and benchmark a SPI solution for the MPC5200 platform. This platform has several serial ports but all of them utilise the same architecture with a FIFO and possibility to use DMA for transfers between the FIFO and main memory. This makes benchmarking results of this solution hold for SPI, USB and Ethernet as interface protocol and therefore it gives a good understanding of all serial ports on the platform. SPI is the protocol with the least overhead in the transfers and was therefore considered to be the easiest to build hardware glue logic for it is also an existing interface for several platforms. For comparison a solution that didn't utilise DMA or FIFO was benchmarked.

During the development of the serial driver with the DMA-controller some test were also performed for an approximation of the performance of a parallel interface.

The third solution to evaluate was the programmable serial port on the OMAP 1710 platform. As this is a more capable serial port the possibilities of using only a clock and data line seemed interesting.

16 Chapter 3. Evaluated interfaces Besides this it would be interesting to benchmark an SDIO or MMC card and driver but the development time and need of licences for developing such hardware made this practically impossible.

3.2 Benchmarking methodology

The purpose of the benchmarking was to measure the amount of CPU time that the driver consumed for several dierent test setups on each platform. The dierent test setups are chosen to identify the parameters of the driver and hardware that inuence the consumed CPU for the current platform and driver.

The benchmarking software was a short loop that ran for an exact amount of time and the number of loops was counted. This gave a measure of how much CPU power that was free on the system. The following is pseudo code for the benchmarking routine used.

Counter = 0

Starttime = now()

While ((now() - Starttime) < testtime) Counter = Counter + 1

End While Print Counter

The constant testtime is the time the test should run for. Three seconds have been used and the measurement has been performed 100 times and the mean value of these measurements have been taken and presented as the CPU left result. This gives a mean value over ve minutes of time which should be enough time to minimize the inuence of infrequent tasks running on the operating system on the measurement.

Tests were performed with the driver active and not and the results were compared with the percentage value from the following formula.

CPU comsumed = 1 −_{CPU left driver inactive}CPU left driver active

3.3 Serial on MPC5200

For benchmarking of this interface a programmable logic circuit (CLPD) was connected using three pins, these were CLK, RXDATA and FRAME. The SPI protocol also pre-scribes one more data bit for transmission but as the communication for this test setup was only one way it was not needed. The MPC5200 was congured as slave and the SPI glue logic in the radio peripheral was designed as a SPI master. This conguration of master and slave makes the radio front end able to send data to the MPC5200 whenever it nds it necessary thus eectively reducing the needs of buers to zero. MPC5200 doesn't even have a possibility to transmit anything to the radio front end and could therefore not be in any need of being master. Figure 3.1 illustrates the hardware and driver architecture of the test setup.

3.3. Serial on MPC5200 17 PSP SPI slave CLK RXDATA FRAME DMA Task Radio front end SPI glue logic

DATA CLK MEM 2 equal buffers Driver Application Nordnav Ex FIFO MPC5200 Radio perpherial Interrupt handler SPI master

Figure 3.1: Architecture of the hardware and driver for SPI.

3.3.1 Hardware

For benchmarking the glue logic hardware was designed to transmit at four dierent data rates. Three of them matched the GPS samples from the radio front end using every fourth, third or second sample. The fourth data rate was set at maximum possible for the test setup with respect to existing clock signals and the SPI protocol. The data rates are summarized in table 3.1 and refer to actual bit rates compensated for the SPI overhead which is 1 bit for every byte transferred. In this setup each byte is 8 bits.

Data rate [MBit/s] 14.565

8.193 5.462 4.0965

Table 3.1: Data rates implemented in hardware for benchmarking.

3.3.2 Software

The MPC5200 is running MontaVista Linux, kernel version 2.4. A custom device driver was developed for this operating system. A dual buer approach was used meaning that when the DMA controller was busy lling one buer another buer was used by the positioning application. When one buer is lled they switched buers and continued processing data. Buer sizes were varied from 32 Kbytes to 512 Kbytes.

18 Chapter 3. Evaluated interfaces 0,00% 0,02% 0,04% 0,06% 0,08% 0,10% 0,12% 0,14% 0,16% 0,18% 0,20% 4 6 8 10 12 14

Data rate (Mbit/s)

C P U C o n s u m e d 32 Kbytes 64 Kbytes 128 Kbytes 256 Kbytes 512 Kbytes Buffer size

Figure 3.2: Benchmark results for the SPI driver.

3.3.3 Benchmarking results

The intended comparison between with and without DMA was not possible to complete because of the enormous dierence in CPU consumed. Already at data rates at half of the lowest intended to measure the non DMA driver consumed about 70 % of the CPU. However the DMA driver worked well at all data rates and the measured values for CPU consumed are showed in gure 3.2. There is a strong linear relationship between the data rate and the CPU consumed with increasing CPU consumption with higher bit rates. The vertical distance between the lines in gure 3.2 indicates that CPU consumed relates to the invers of buer size. This makes perfectly sense as interrupts occur once every lled buer and the time between interrupts would therefore be as described in 2.2.1.

For an interrupt routine that takes about constant time independent of buer size and data rate this would give the measured results. The benchmark shows that DMA controller very well scale with buers and data rates and that the interface driver only needs to consume about 0.2 % of the MPC5200 processing power. It also excludes the possibility to use non DMA drivers.

3.4 Parallel on MPC5200

The serial driver for MPC5200 framework together with the hardware similarities be-tween the programmable serial port and the parallel interface called LocalBus makes it possible to do benchmarks and draw conclusions from the experiences from the

se-3.4. Parallel on MPC5200 19

ROM/RAM controller DATA

Control*

DMA Task Radio front end FIFO buffer

DATA CLK MEM 2 equal buffers Driver Application Nordnav Ex MPC5200 Radio perpherial Interrupt handler

Figure 3.3: Architecture of the hardware and driver for parallel interface. rial driver combined with some benchmark of incomplete1 _{hardware designed to the}

the parallel interface capabilities. Figure 3.3 illustrates the architecture of the driver and hardware. Control are the signals Address, Chip enable and Read/Write from the MPC5200 and Buer Half Full signal to the platform. MPC5200 doesn't support VLIO so this was not possible to use in this setup.

3.4.1 Hardware

The Half full signal from the FIFO indicates when it needs to be emptied by the processor. This Half full is not always exactly at half the buer size but selectable. This selection has to be done so that it is no risk that an overow occurs if the processor is very busy and can't handle the interrupt at once. This sets an upper limit of when the half full signal should be asserted. On the other hand the amount of data in the buer when half full is the maximum amount of data that can be transferred in each DMA task without the risk of underowing the buer2_{. The amount of data in the buer when issuing}

the half full signal is here the most interesting factor for performance. From the simple formula in section 2.2.1 the time to ll the buer to half full will be the same as the time between interrupts to the driver for emptying the buer. This could be somewhat optimized in production code as the maximum transfer size doesn't include the samples that always arrives while emptying the FIFO. Refer to gure 2.1 for illustrations.

1 _{The hardware lacked the buer and valid data; it just generated half full signals at the right}

frequency.

20 Chapter 3. Evaluated interfaces

3.4.2 Software

The same interrupt routine was used in both the SPI and Parallel driver with the only modication that other addresses was used when reading data from the parallel bus instead of the SPI FIFO.

3.4.3 Teoretical results

The interrupt routine takes a constant amount of CPU and the CPU consumed is there-fore only dependent on how often this interrupt occurs. The time between interrupts can easily be calculated with the formula in section 2.2.1. Measurments from the SPI driver benchmarking with the same time between interrupts can therefore be used for comparison.

Some measurements were performed to validate this and they give almost exactly the same results with comparable SPI benchmarks. When extrapolation the benchmark results to buers of 2 Kbytes and data rates of 16.368 MBit/s the accuracy drops some-what but are still within 20 % from the correct value, with calculated values generally higher than measured.

For example if the FIFO buer is 8 Kbytes and half full signal is asserted at 4 Kbytes the time between interrupt are the same as for a 32 Kbytes buer and 131 Mbit (16.367 · 32/4) data rate. Extrapolation of the 32 Kbytes buer line in gure 3.2 gives 1.315 % CPU Consumed but the measured value was 1.05 %.

3.5 Serial on OMAP 1710

One of the most programmable serial ports on the platforms studied are the McBSP port on OMAP 1710. It is higly congurable with frame sizes, clock division and syncronized transfers with other internal or external clock signals or multiples of them as well as continuous data with synchronization signal generated external or internal.

The latter was decided to be evaluated in a glueless implementation with just con-necting the front end clock signal to clock input and front end sign bit to data input.

3.5.1 Hardware

For benchmarking a FPGA was connected in between the front end and the OMAP platform. This made it possible to decimate the signal and use only one out of one, two, three or four samples. It was also a great help in the development process as it made it possible to inject identiable test patterns.

3.5.2 Software

The OMAP 1710 development platform runs with Linux with 2.6 kernel version and some specic patches for the platform. The custom driver developed for MPC5200 was modied to handle the dierences for device drivers between 2.4 and 2.6 kernel

3.5. Serial on OMAP 1710 21

PSP

DMA Task Radio front end

DATA CLK MEM 2 equal buffers Driver Application Nordnav Ex OMAP 1710 Radio perpherial Interrupt handler

Figure 3.4: Architecture of the hardware and driver for glueless serial on OMAP 1710. versions. Other revised parts of the code were all platform specic code such as port conguration and DMA controller. The general framework and operation are still the same and described in gure 3.4.

In this implementation some extra time was spent on integrating the driver with the Ex application and rigid verication of the received samples. For that purpose a recorder application was built that used the driver and the same interface as the Ex application for interacting with it.

3.5.3 Benchmarking results

The results for this platform and driver are very similar to the MPC5200 platform. With very strong linear relationship between Data rate and CPU consumed, but generally with a factor of about eight times higher consumption. The main dierence here may be the dierent clock frequency they operate in, with MPC5200 about 2.5 times faster than OMAP 1710.

Besides that MontaVista Linux is not exactly the same as the general Linux kernel with applied OMAP patches and probably the interrupt handling is somewhat better in MontaVista Linux as this is a real time capable embedded operating system. The dierences between version 2.4.x and 2.6.x of the kernel may also give some explanations of the performance dierence.

3.5.4 Verication

For verication of the drivers operation the recorder application was used to record about 20 Mbytes of samples to memory and then write it to disk for further analysis. The reason for not writing to disk at once was that the slow hard disk could not keep

22 Chapter 3. Evaluated interfaces up with the data rate from the driver. This made the available RAM the limit of the size of recordings that was possible to do. With decimation to one out of three samples this gave 30 seconds recording of live GPS intermediate frequency data.

NordNav Rx is an application for GPS research and is suitable for analysis of recorded data. The application is a GPS receiver with outputs of about everything needed to evaluate the process of signal acquisitioning, tracking and navigation. The recorded data from the OMAP platform was feed to the Rx application which veried that a position was possible to determine and that no samples where missed in the driver.

Chapter 4

Discussion

This chapter put the theory and evaluation chapters in to the same context and discuss two alternative approaches for development.

4.1 Platform classication

During the survey of embedded platforms and their interfaces a classication of the studied platforms based on their interfaces and intended usage have been done. This classication's categories are DSP, general computing and Mobile communication. The following sections will describe each of them.

4.1.1 DSP

Platforms in this category are derived from high performance computational cores. The available interfaces are rather primitive, standard parallel and serial interfaces with high bit rate but lack of interfaces with more advanced protocols like USB or SD card.

These platforms handles today's RF front ends very well and doesn't need any glue logic at all for interfacing parallel or serial data streams in its basic form.

Blackn is the main platform in this category.

4.1.2 General computing

These embedded platforms have been derived from other general computing platforms. The number of peripheral interfaces are more limited than for the Mobile communication category but they do have advanced interfaces like USB and SD card but these are quite general, not like the Mobile communication category which have interfaces dedicated for WLAN modules and such.

This group of platforms is not likely to interface without any glue logic in the radio front end. At least if they should work with more than one bit per sample. Simple serial interfaces like SPI are commonly supported and are possible to realise with a small gate count. For these interfaces there will be a need to develop drivers for each platform but the CPU consumption will be low with tailored drivers with DMA support.

24 Chapter 4. Discussion This category is populated by MPC5200, Xscale PXA255 and S3C2410 platforms.

4.1.3 Mobile communication

This category is platforms directly targeted for mobile phones and other hand held communication and entertainment devices. They have a rich set of interfaces specialized for directly connecting to peripherals like radio modules, cameras and displays.

Besides the discussion above about serial interfaces in the general computing group this category is also suitable for advanced interfaces like SDIO card. This would reduce the need of new drivers for each platform as this is often provided by the operating system but this may also be somewhat more CPU consuming as they are not tailored for the NordNav Ex application and hardware.

The PXA27x, OMAP1710 and MiMagic 6+ are categorised as Mobile communication platforms in this thesis.

4.2 Master or slave - the need of buers

In software dened radio receivers most data travels from the radio front end to the platform and therefore the interface should be optimized for this data transfer. Transfers in the opposite direction is for modifying settings in the front end and therefore happens rarely, if ever.

4.2.1 Front end is master

If the front end is selected to be master it is able to initiate a transfer any time it likes and therefore it may optimize the transfers so that it starts at the exact clock phase that is best. Thus resulting in a minimum need of buers, they only have to handle speed mismatch and no large buering of data. This of course only holds if there is a point to point connection between master and slave and no other usage of the bus.

4.2.2 Front end is slave

If the front end is slave or the bus is shared with other devices it is hard to predict when data will be sent from the front end. Therefore the front end in such a solution has to buer data until a bus master starts a transfer of data from it. The size of the buer depends on the data rate into the buer, data rate out of the buer and the interval at which the platform may initiate data transfers. The output data rate should not necessary be as high as possible as this will force buers to be larger or time between interrupt to be shorter. Refer to gure 2.1 for illustrations.

That gures conclusion is to match input and output data rate as close as possible, exactly the same data rate is generally impossible if not using the same clock. One solution for matching output data rate to input rate is to pause during burst transfer when data rate is too high and by that mechanism lower the data rate a little so the mean is exactly the same. This could be achieved with variable latency IO or any

4.3. Choice of interface 25 other interface that supports pause during burst transfers1 _{. This makes the needed size}

of buers much lower as the platform may continuously read data and the front end pause the transfer if its buer is close to empty. It will also lower CPU consumption as interrupts doesn't happens so often.

However if this approach is used careful notice has to be taken to make sure this often paused burst reads are not hogging any vital bus in the platform making other use of it impossible.

4.3 Choice of interface

From the survey of platforms and their capabilities as well as interfaces there are two possible interface strategies for the future, each discussed in the following two sections. After that table 4.1 compare the two solutions and one section argument for why certain standards have been excluded.

4.3.1 The "Less is more" approach

This approach works to minimize the need of glue logic with a small SPI interface with a low pin count, low extra gate count and no buers2 _{resulting in a low interface design}

cost as well as low manufacturing cost for the front end. The connection of the front end will be integrated on the PCB of the platform and therefore it is not possible to sell as an upgrade to existing devices. This solution is only for devices where NordNav take part in the development process of the device.

The costly part of this is that every platform and operating system needs custom drivers that have to be developed by NordNav or their partners. This results in rather high initial cost for each device/platform and a constant need to develop drivers for new versions of operating systems and platforms. This process is not very time consuming as it has been partly3 _{done twice during this thesis work. But it reduces the possible}

customer group to those devices that NordNav have time to develop custom drivers for. It also means that NordNav Ex market is limited to newly developed devices but all of these devices will have NordNav Ex technology inside.

On the other hand a simple IC gives a low variable cost for manufacturing resulting in better margins on those systems where time is spent on custom driver development and PCB integration.

For more than one bit precision of the GPS samples the front end ICs has to be modied somewhat resulting in non-recurring engineering costs for new masks and ASIC design. If no modication is performed it will not be possible to use front ends with all of the studied platforms. What generally is needed is a synchronization signal in between each and every word of data (8, 16 or 32 bits) and a parallel to serial conversion of the signal.

1_{SDIO and CompactFlash is two examples.} 2_{The front end should be SPI master on the bus}

3 _{Drivers have been developed for benchmarking only without the focus on totally stable and}

26 Chapter 4. Discussion

4.3.2 The "Extra everything" approach

The other approach is to design and manufacture a complete SD/SDIO-card or MMC4_.

This will be a rather large hardware system to be developed, veried and tested, a project that will take lots of time and eort. If not a partner company or a hardware IP-core is bought it will probably be too much work for NordNav without prior experience in ASIC hardware design projects. Even if an IP-core is bought for the interface there is a lot of work with verication of such a device as well as transforming register transfer level described hardware into a mask for IC manufacturing. The latter process should be done by experienced people as the cost for making mistakes in this process is extremely high and requires expensive tools and know how.

On the downside is also power consumption as this solution requires a lot more logic gates and memory it will consume more power and also the interface overhead will be larger than for the other approach which may also demand a higher clock frequency for a given sampling rate and sample size which also increases the power consumption.

The positive sides with this approach are that low level drivers are not needed as this is handled by the operating system. The NordNav Ex application will therefore be portable between dierent platforms and devices and it will be possible to oer NordNav Ex as an o the shelf product for a large number of embedded devices without the need of custom integration projects for each and every device. If the design enables setting the sample size and decimation in software it will also be possible to utilise this front end solution for dierent applications within the Ex range with dierent constraints on position errors and such. Making it a competent front end only limited by the RF parts in it.

One important aspect here is that not all devices with an MMC/SD/SDIO slot will be able to handle a bit rate as high as required and a software dened radio application. Some device manufacturers implement just parts of the MMC/SD/SDIO standard thus resulting in lower data rates in their card slots than required by the software dened radio.

4.3.3 Reasons for exclusion

There are several other interfaces that could be used for the NordNav Ex front end connection. The main reason for not recommend them among the two proposed solutions above is that they are not simple or not as good as the "extra everything". USB as host is quite common among studied platforms and with the general acceptance and use of the USB On-The-Go standard it will probably be common with a USB Host ports on most embedded devices. One problem with USB is that there is no protective slot for it on the device forcing the GPS front end to be a dongle that sticks out of the device and easily breaks. Another problem with USB is that it still requires a lot of work with verication for conforming to the standard and it will probably be almost as much work as the "extra everything" approach but with some more downsides and lower transfer

4.3. Choice of interface 27 Approach

Factor Less is more Extra everything

Technical

Drivers Custom drivers for each

operat-ing system and platform. One driver for each operating sys-tem. Extra logic gates About the same as today's front

ends. About 10K gates for physicallayer and some K gates more for logical layer and front end inte-gration. Plus some buer mem-ory dependent on time between interrupts to the device.

Power consumption About the same as today's front

ends. More logic and higher clock fre-quency gives higher power con-sumption.

Economical

Component cost for

each enabled device Today's front ends with slightlymore gates for interface logic. Higher gate count IC with atleast some Kbytes of memory on-chip.

Non-recurring

engineer-ing (NRE) costs. New masks and RTL to silicon ofa small design. New masks and RTL to siliconof a large design. Verication of compliance to the used standard.

Licenses None SDIO and MMC from $2,500 per

year

Royalties (per device) None SDIO may require royalites. Time to market Time has to be spent for each

en-abled device. Dependent on de-vice manufacturer's time to mar-ket.

Long initial development time.

Table 4.1: Comparison between the two possible interface strategies.

rate for high performance applications as the maximum data rate in general is 12 MBit/s for the platforms.

IEEE 1394, FireWire, on the other hand is much easier to implement but lack native support in all of the studied platforms and is therefore not suitable. The same argument is used for the Memory Stick and Compact Flash as the native support is poor it will require external circuits with another interface for many platforms.

Parallel interfaces are common for all platforms but it's main disadvantage is it lack of control of the transfers. Some platforms have support for VLIO that lowers the need of buers but anyhow the need of buers will be of several Kbytes at least resulting in larger die size in a nal IC. It will also require at least twice the pin count compared to a serial interface.

Chapter 5

Conclusions

The discussion is in this chapter condensed into some hands on recommendations and nally some issues found and future work is presented.

5.1 Recommendations

This purpose of this thesis is to evaluate possible design alternatives for hardware for the NordNav Ex application and two very distinct paths are dened and discussed in the previous chapter. If one of them or both are chosen is not just based on technical and economical factors. A decision in this question includes also factors like market needs and personnel available for development which is beyond the scope of this thesis.

The easiest way is the "less is more" approach which may use today's front ends together with many platforms as long as not more than one bit per sample is needed. The modications to the front end IC needed for more bits per sample is not that advanced but anyhow a new IC has to be manufactured with all costs that this includes. In appendix B a more detailed denition of the possible future IC is presented as well as some design alternatives that should be considered before designing. Some of them require quite much extra work as well as gates but results in a more widely usable front end IC.

If more time and money are spent on hardware design an "extra everything" approach should be considered resulting in a wider market and a lot more of potential customers and supported devices. But this alternative is not possible without the help of some partner companies for designing a MMC/SD/SDIO card ASIC from scratch. NordNav could be able to design the chip on register transfer level if an IP-core for the device interface is bought. The list of front end functionality found in appendix B should be considered for this approach as well.

For both of these approaches to work a DMA controller has to be in charge of the transfers from the peripheral to memory. In order to minimize buers the data rate in between front end and platform should be as close as possible to the data rate of the front end.

30 Chapter 5. Conclusions

5.2 Future work

This study lack benchmarking of a VLIO enabled platform and some more in depth studies of it's impact on buer sizes. This could be of interest if a parallel interface seems interesting. Other benchmarking that should be considered is one of the performances of SDIO card drivers on some embedded operating systems.

This thesis deals with seven platforms but the there are a lot more on the market and for a more detailed picture some more platforms may have to be studied and evaluated as been done here.

Bibliography

[1] Analog Devices, USA. Blackn Embedded Processor ADSP-BF531/ADSP-BF532/ADSP-BF533 Data sheet, Rev B 2005.

[2] Bsquare corporation webpage. www.bsquare.com, Accessed 2005-11-15. [3] CF+ and CompactFlash Specication, Revision 3.0, 2004.

[4] Codetelligence webpage. www.codetelligence.com, Accessed 2005-11-15. [5] embWiSe webpage. www.embwise.com, Accessed 2005-11-15.

[6] Freescale Semiconductor. MPC5200 Users Guide, 2005.

[7] A Hansson, P Normark, A Rosenlind, C Ståhlberg, F Svensson, and D Akos. Global positiong system in a digital signal processor for the TMS320 DSP platform. Tech-nical report, Luleå University of Technology, Luleå, 2001.

[8] IEEE Std 1394-1995, IEEE Standard for a High Performance Serial Bus, 1995. [9] Intel. Intel PXA255 Processor Developer's Manual, January 2004.

[10] Intel. Intel PXA27x Processor Family Developer's Manual, October 2004. [11] The Linux Kernel Archive webpage. www.kernel.org, Accessed 2005-11-15. [12] Linux USB webpage. www.linux-usb.org, Accessed 2005-11-15.

[13] Linux1394 webpage. www.linux1394.org, Accessed 2005-12-13.

[14] Memory stick developers site webpage. www.memorystick.org, Accessed 2005-12-12.

[15] P Misra and P Enge. Global positioning system. Signals, Measurments, and Perfor-mance. Ganga-Jamuna Press, USA, 2004.

[16] MPEG LA. www.mpegla.com/1394/, Accessed 2005-12-13.

[17] MSDN Common Windows CE Modules webpage. msdn.microsoft.com/library/ en-us/wcemain4/html/_wcesdk_windows_ce_modules.asp, Accessed 2005-12-13.

32 BIBLIOGRAPHY [18] MultiMediaCard Association webpage. www.mmca.org, Accessed 2005-12-12. [19] NeoMagic, USA. MiMagic 6+ Application Processor Developer
s Manual, Rev 1.0,

22 Sep 2005.

[20] P Normark and C Stålberg. Hybrid GPS/GALILEO real time software receiver. In Proc. ION GNSS 2005, Longbeach, USA, 2005.

[21] On-The-Go Supplement to the USB 2.0 Specication, Revision 1.0a, 2003.

[22] Samsung Electronics. User's Manual S3C2410A - 200MHz & 266 MHz 32-Bit RISC Microprocessor, 1.0 2004.

[23] SD Association webpage. www.sdcard.org, Accessed 2005-11-15. [24] SD Association news release, 2005-07-13.

[25] A Silberschatz, P B Galvin, and G Gagne. Operating systems concepts. John Wiley & sons, inc, USA, sixth edition, 2003.

[26] W Stallings. Computer Organization & Architecture. Designing for performance. Prentice Hall, USA, sixth edition, 2003.

[27] Texas Instruments, USA. OMAP1710 Multimedia Processor Technical Reference Manual, september 2004.

[28] Universal Serial Bus Specication, Revision 2.0, 2000.

[29] W Wolf. Computers as Components. Principles of Embedded Computing System Design. Academic Press, USA, 2001.

[30] S Yi. Understanding Secure Digital I/O Performance in Systems and Cards. Tech-nical report, Codetelligence, Inc., USA, 2004.

Appendix A

Acronyms

This appendix explains commonly used acronyms and abbreviations used in this thesis. ASIC - Application Specic Integrated Circuit A custom designed IC for a

cer-tain application or functionality.

ATA - Advanced Technology Attachment A standard interface for storage devices such as hard disks.

CDMA - Code Division Multiple Access A technology for sharing a data link be-tween dierent senders that is sometimes used instead of time division or frequency division.

CMOS - Complementary Metal-Oxide-Semiconductor A technology for ICs that use transistor pairs for low power consumption.

CPLD - Complex Programmable Logic Device A less complex FPGA which there-fore only may realize limited sized digital designs.

CRC - Cyclic Redundancy Check A algorithm used to calculate a checksum used in data transfers to detect and correct errors.

DMA - Direct Memory Access See section 2.2.2.

DSP - Digital Signal Processing The use of digital electronics to process signals. FFT/IFFT - (Inverse) Fast Fourier Transform A transformation that may be used

to transform from time plane to frequency plane or vice versa. Generally needs lots of multiplications and additions.

FIFO - First In First Out A buer used as a queue. See section 2.2.1.

FPGA - Field Programmable Gate Array An IC with programmable logic com-ponents and interconnect which make it possible to realize dierent logic hardware designs without the need of manufacturing a new IC. Used for prototyping, low volume production, test and verication.

34 Chapter A. Acronyms GNSS - Global Navigation Satellite System A name for systems for positioning

based on satellites, the largest of them is GPS and the coming Galileo.

GPS - Global Posistioning System System for positioning using satellites controlled by the department of defence in USA.

IC - Integrated Circuit Small electronic device containing transistors that realize cer-tain functionality.

IEEE1394 - Institute of Electrical and Electronics Engineers standard 1394 Standard for a serial interface also called Firewire. See section 2.3.7.

IO - Input Output A subsystem used for outputting or inputting data.

IP-core - Intellectual Property Core A description of a piece of hardware in some form for manufacturing of IC or programming of CPLD/FPGA. These are possible to sell, buy and further develop as any other drawing.

LSB - Least Signicant Bit Refers to a bit in a word that has least signicance. MMC - MultiMediaCard See section 2.3.2.

MSB - Most Signicant Bit Refers to a bit in a word that is most signicant. OTG - On-The-GO Supplement to the USB 2.0 standard for devices that may be

host or function dependent on the connected cable. See section 2.3.6.

PCB - Printed Circuit Board The board where ICs and other electronic compo-nents are placed and interconnected in a device.

PCMCIA - Personal Computer Memory Card International Association Physical and electrical specication of an expansion card for PC Laptops. Signal compatible with the ATA standard for storage.

PDA - Personal Digital Assistant Pocket sized device used for handling schedules, contacts, e-mail and other applications.

RF - Radio Frequency Device operating with signals at frequencies suitable for trans-mitting as a radio signal.

SD/SDIO - Secure Digital, Secure Digital Input Output See section 2.3.1. SDR - Software Dened Radio Usage of software algorithms instead of hardware

for transforming an radio signal to information. See section 2.1.2

SPI - Serial Peripheral Interface Serial interface that uses clock, data in, data out and synchronization signal for transfers in point to point connections.

VLIO - Variable Latency Input Output See section 2.2.3.

WLAN - Wireless Local Area Network Network for data transfers using some kind of wireless connection.

Appendix B

Detailed recommendations