CHAPTER 1

1. INTRODUCTION

1.1. Aim of the Project:

The Bluetooth technology is one of most commonly available wireless

communication in most of the mobiles. Several companies are currently developing

Bluetooth broadcasting system for marketing.

One of the major issue with the Bluetooth which might affect a broadcast, is

low transfer rate, an issue with device discovery when a lot of users are doing device

discovery at the same time. The fact that it only supports seven connections is also a

limitation.

This project deals with Bluetooth broadcasting for delivering information for

more number of mobiles. This system runs on ARM-Linux operating system with

Samsung S3C2440 processor, and it achieves single point transmission, multi-point

transmission and information update based on Bluetooth 2.0 specifications. BlueZ

protocol stack and object exchange (OBEX) were utilized to complete data

Transmission. During transmission of data to multiple number of mobile users if any

one of the user rejected the connection then data is not transfer to that particular device

and it display the MAC address of that particular device on the pc.

1

1.2. Literature Survey:

The authors Khaja Kamaluddin, Masood Shareef Arif, Imran Khan proposed

GPS based Bluetooth Broadcasting – Long Range Solution. In which Bluetooth is

used to broadcast the messages to bluetooth devices through cluster of piconet .With

this solution ,long range data and voice communication could be done with free of

cost also can be used for commercial advertising purpose. Global Positioning System

(GPS) network provides information about position and time to receiving devices.

There are 24 satellites actively involved in this network and continuously transmit

position information through spread spectrum signal. In order to obtain the accurate

location and time, there must be four satellites in receiver range[1].

The authors ]Idwan, S.Alramouni, Al-Adhaileh, and Al-Khasawneh, proposed

Enhancing mobile advertising via Bluetooth technology ,in which Multimedia

Message Transmitter Tool (MMTT) is a proximity marketing platform, which allows

one-way (one-to-many) data transfer to mobile devices based on proximity of such

mobile devices. The main purpose is to establish the permission-based

communication through the individual's mobile phone which enables companies to

reach their specific target. The main idea of MMTT is to deploy Bluetooth devices in

indoor/outdoor areas, creating a Bluetooth umbrella; therefore, we can track people

through their mobile phones unique Bluetooth IDs, which enables locating consumers

and sending advertisement to their mobile phones[2].

2

The author kyunghun jang proposed Reliable delivery of broadcast packet in

Bluetooth packet from broadcasting system is retransmitted for a fixed number of

times. there is a trade-off between the number of retransmission and the effective

throughput.but reliable packet delivery is not always guaranteed. Therefore, author

proposed a reliable broadcast packet delivery policy, which is called NACK-based

retransmission policy in which the number of retransmission is dynamically adjusted

so that all the slaves can receive the packet correctly. simulation results proved that

NACK-based retransmission policy guarantees reliable packet delivery and

maximizes the effective throughput by preventing a broadcast packet from being

retransmitted unnecessarily[3].

With,the help of above papers my objective is to implement a broadcasting

system using Bluetooth on linux operating system. In order to implement the

broadcasting system ,the BLUZ packages must be used to operate Bluetooth on linux

and obex library functions required for data transfer to the mobile. The broadcasting

system based on ARM acts as server and all the mobile devices treated as clients.The

client-server model is implemented with help of sockets,where socket is to create end

point communication between two systems.

.

3

2. EXISTING SYSTEM

The embedded Bluetooth information broadcasting system mainly complete

two functions, namely information broadcast and information update. The

information broadcast completes the task that sends information to multiple

Bluetooth devices around EBIBS at the same time, mainly including information unicast

and multicast.

Information update achieves network communication between EBIBS and PC. It

completes seamless connections between Bluetooth and TCP/IP. Users are

permitted to access file system via FTP, so the EBIBS can timely update

information based on user requirement, which greatly improve system operability.

The architecture of EBIBS is shown in Fig. 1. In addition, user interaction interface

was designed.

Fig1.EBIBS block diagram

4

The block diagram of the existing system consists of arm development board,

one pc/laptop serial communication cable and one Bluetooth dongle. In order to

establish the communication between the pc and arm the serial communication cable

is used. The Bluetooth dongle is attached to the arm development board to broad cast

the data to the all mobiles which are in the communication range.

2.1) INFORMATION BROADCAST PROCESSS

The information unicast is base for information broadcast. The system firstly

complete file transmission process in single point mode. The process is based on

OBEX protocol and uses OPEN OBEX library functions and achieves object

push operation to mobile device.

OPEN OBEX library funnction performs the session layer operation and

corresponding object model description of OBEX protocol. Fig 2. shows complete

process of object push.

Fig 2. information broadcast

5

OBEX-INIT() function is used to initiate OBEX entity, including initiate

transform type, socket description, maximum size of send packet and maximum size

of receive packet and then return a entity handle.Store target Bluetooth device

address, object push service channel number and information file name to

corresponding local variables.

Call BtOBEX_TransportConnect() function establish transmission connection.

The function firstly initiate transmission attributes of local and remote OBEX entities

and then call socket () system function to create local socket. The bind () function is

used to bind socket and process and connect () function is used to connect local

device socket and remote socket. Finally return connect () system call. If the return

value is 0, it indicates the connection is successful.

Broadcast system send connect request to remote device. It firstly call OBEX-

ObjectNew () function to create a send request object and then call OBEX-Client () to

write request into local device, and then send it out. At this moment, broadcast system

calls OBEX-HandleInput () function to wait fro response signal of remote device. The

function call select () and register socket between broadcast system and remote device

so that system can listen to events on the socket. After remote device responds, the

function will read and process received data, otherwise the function will block. If

returned event variable is OBEX_RSP_SUCCESS, it says that remote device respond

successfully.

Send file object to remote device. Firstly,build_object_from_file () function is

used to create file object.The function will access related file information about file content, size and send the object out. Then it waits for responsefrom remote device. The

response indicates successful file transmission. Send disconnect request to remote device. As

same to send connect request, after remote device successfully respond,it disconnects.

After all transmission tasks completed, information transmission parent

process firstly determine whether all childprocess has exited. If so, enter into next

round transmission, otherwise it will block operation and wait for other childprocess

6

to exit. Each child-process will then create information push child-process. The

process call object push function to complete transmission to some device.

2.2) Multicast process :

The milticast implementation process is shown below.

Fig3 multicast implementation

Multicast transmission uses TDD and EDR technologies in Bluetooth protocol to

implement information transmission from system to multiple Bluetooth devices. Meanwhile,

multiple process technique is used to reasonably manage multiple transmission processes, so

that the information can be sent to remote device effectively and promptly. The TDD

7

technique is used so that multiple devices can share a physical channel. Data is packet and

sent in time division multiplexing manner. The EDR technology increases transmission

bandwidth and transmission rate of Bluetooth data so as to improve information multicast

transmission efficiency.

The multicast transmission process is shown in Fig.3 Firstly, information

transmission parent process creates child-processes whose number is equal to that of

Bluetooth devices. During transmission of data to multiple number of mobile users if any one

of the user rejected the connection then data is not transfer to that particular device and it

display the mac address of that particular device on the pc.

8

3. PROPOSED SYSTEM

In the proposed system we can transfer data to any number of Bluetooth based

mobiles which are in communication range better than existing system because in

that system after terminating the all the child process in piconet new child process get

data, but in the proposed system after terminating one child process of piconet new

ones allowed so it can send data to the more number of mobiles.fig 4 shows the

blockdiagram of the proposed system.

FIG 4.Broadcasting system

9

3.1) OBJECT PUSH OPERATION

The broadcasting system is based on OBEX protocol.

This protocol uses OPENOBEX library functions, so it can achieve object push

operation to remote devices.fig 5 shows object push operation.

FIG 5. object push operation

In the proposed system if a data send to the child processs using the sockets .

if child gets the data then sockets of the particular child processs is closed and new

socket was created for new child process.the first stage of the obex push operation

need OBEX-INIT() function is used to initiate OBEX entity, including initiate

transform type, socket description, maximum size of send packet and maximum size

of receive packet and then return a entity handle. In the second stage Store target

Bluetooth device address, object push service channel number and information file

name to corresponding local variables.

10

In the third stage Call BtOBEX_TransportConnect() function establish

transmission connection. The function firstly initiate transmission attributes of local

and remote OBEX entities and then call socket () system function to create local

socket. The bind () function is used to bind socket and process and connect () function

is used to connect local device socket and remote socket. Finally return connect ()

system call. If the return value is 0, it indicates the connection is successful.

Broadcast system send connect request to remote device. It firstly call OBEX-

ObjectNew () function to create a send request object and then call OBEX-Client () to

write request into local device, and then send it out. At this moment, broadcast system

calls OBEX-HandleInput () function to wait fro response signal of remote device. The

function call select () and register socket between broadcast system and remote device

so that system can listen to events on the socket. After remote device responds, the

function will read and process received data, otherwise the function will block. If

returned event variable is OBEX_RSP_SUCCESS, it says that remote device respond

successfully.

Send file object to remote device. Firstly,build_object_from_file () function is

used to create file object.The function will access related file information about file

content, size and send the object out. Then it waits for response from remote device.

The response indicates successful file transmission. Send disconnect request to remote

device. As same to send connect request, after remote device successfully respond,it

disconnects.

After all transmission tasks completed, information transmission parent

process firstly determine whether all childprocess has exited. If so, enter into next

round transmission, otherwise it will block operation and wait for other childprocess

to exit. Each child-process will then create information push child-process. The

process call object push function to complete transmission to some device.

11

3.2) Multicast implementation process :

The multicast implementation process of the proposed system is

different is different from the existing system .in the proposed system after sending the

data to the child process ,the child is terminated and new child is allowed.so it can send

send data to more number of devices compared to the existing system

Fig 6. multicast implementation

Multicast transmission uses TDD and EDR technologies in Bluetooth protocol to

implement information transmission from system to multiple Bluetooth devices. Meanwhile,

multiple process technique is used to reasonably manage multiple transmission processes, so

that the information can be sent to remote device effectively and promptly. The TDD

technique is used so that multiple devices can share a physical channel. Data is packet and

sent in time division multiplexing manner. The EDR technology increases transmission

bandwidth and transmission rate of Bluetooth data so as to improve information multicast

transmission efficiency.

12

the multicast transmission process is shown in Fig.6 Firstly, information

transmission parent process creates child-processes whose number is equal to that of

Bluetooth devices. During transmission of data to multiple number of mobile users if

any one of the user rejected the connection then data is not transfer to that particular

device and it display the mac address of that particular device on the pc.

Information boardcast module and information update module are desingned

according to official Bluetooth protocol BlueZ and OBEX, where BlueZ includes two

parts of core library bluez-libs and bluez-utils utility. The latter provide developers

with tools support for upper-level applications. OBEX prtocol is realized by

OpenOBEX application function library. Therefore, the design firstly implements

migration from BlueZ and OpenOBEX to ARM9 hardware platform system and then

achieves other functions. LED and key driver are designed according to embedded

character-driven technology.

3.3)Flow chart:

The broadcasting system initially waits for 30 sec time which is used to replace

the old data with new data after that it search the near by device and display the mac

address and name of that mobile,the channel number of the opp(object push profile )

number.after searching it send data to all mobiles one after another .finally it display

the time taken for data transfer for each mobile.once it transmitted all the mobiles the

broadcasting system enters into the sleep mode such that in remains idle for one

minute.after the sleep period again it searches the mobile devices and repeats the

process as shown in fig 7.

13

flow chart:

Fig 7.flow chart

14

START

Wait for 30Sec to update file

Search for Nearby devices (Device Inquiry)

Query each device for its display name

Search for object push profile (OPP) service channel Number

Using Channel number connect the device to send data

Choose device with user specified name

Send the data on channel selected using command “OBEX_PUSH_SERVICE””

Disconnect the device

Wait until data send

4. TOOLS

In order to implement the broad casting system using Bluetooth ,the Following tools

are required

Software:1)boot loader

2)bluez stack

3)obex profile

4)socket programming

Hardware:1)usb Bluetooth dongle

2)arm development board

15

SOFTWARE REQUIREMENTS

4.1) Boot Loader:

Microprocessors can execute only code that exists in memory (either ROM or

RAM), while operating systems normally reside in large-capacity devices such as

hard disks, CD-ROMs, USB disks, network servers, and other permanent storage

media.

When the processor is powered on, the memory does not hold an operating

system, so special software is needed to bring the OS into memory from the media on

which it resides. This software is normally a small piece of code called the boot

loader. On a desktop PC, the boot loader resides on the master boot record (MBR) of

the hard drive and is executed after the PC's basic input output system (BIOS)

performs system initialization tasks.

In an embedded system, the boot loader’s role is more complicated because

these systems rarely have a BIOS to perform initial system configuration. Although

the low-level initialization of the microprocessor, memory controllers, and other

board-specific hardware varies from board to board and CPU to CPU, it must be

performed before an OS can execute.

At a minimum, a boot loader for an embedded system performs functions such as

Initializing the hardware, especially the memory controller Providing boot parameters

for the OS Starting the OS .Most boot loaders provide features that simplify

developing and updating firmware; for example: Reading and writing arbitrary

memory locations, Uploading new binary images to the board's RAM from mass

storage devices Copying binary images from RAM into flash

U-Boot

U-Boot is an open-source, cross-platform boot loader that provides out-of-box

support for hundreds of embedded boards and many CPUs, including PowerPC,

ARM, XScale, MIPS, Coldfire, NIOS, Microblaze, and x86.

16

U-Boot Features:

Customizable footprint

U-Boot is highly customizable to provide both a rich feature set and a small

binary footprint.

Monitor

U-Boot has a command shell (also called a monitor) for working with U-Boot

commands to create a customized boot process.

Variables

U-Boot uses environment variables that can be read or written to and from

non-volatile media. Use these variables to create scripts of commands

(executed one after the other) and to configure the boot process.

Kernel images downloadable via Ethernet and USB

Because U-Boot can download a kernel image using either Ethernet or USB,

no flash programming is needed to test a new kernel. This prevents the

deterioration of flash caused by repeated flash erases and writes.

Numbers assumed in hexadecimal format

Numbers used by U-Boot are always considered to be in hexadecimal format.

For example, U-Boot understands number 30100000 as 0x30100000.

The Boot Process

After power-up or reset, the processor loads the U-Boot boot loader in several steps.

Executes a primary bootstrap that configures the interrupt and exception

vectors, clocks, and SDRAM Decompresses the U-Boot code from flash to

RAM Passes execution control to the U-Boot and it Configures the Ethernet

MAC address, flash, and, serial console Loads the settings stored as

environment variables in non-volatile memory.After a few seconds (a

programmable length of time), automatically boots the pre-installed kernel.

To stop the automatic booting (auto boot) of the pre-installed kernel, send a character

to the serial port by pressing a key from the serial console connected to the target. If

U-Boot is stopped, it displays a command line console (also called monitor).

17

4.2) U-Boot commands:U-Boot has a set of built-in commands for booting the system, managing

memory, and updating an embedded system’s firmware. Custom built-in commands

can be created by modifying U-Boot source code.

Built-in commands

For a complete list and brief descriptions of the built-in commands, at the U-Boot

monitor prompt, enter either of these commands:

A list of commands and help text like this is displayed:

# help

? - alias for 'help'

autoscr - run script from memory

base - print or set address offset

bdinfo - print Board Info structure

boot - boot default, i.e., run 'bootcmd'

bootd - boot default, i.e., run 'bootcmd'

bootelf - Boot from an ELF image in memory

bootm - boot application image from memory

bootp - boot image via network using BootP/TFTP protocol

bootvx - Boot vxWorks from an ELF image

cmp - memory compare

coninfo - print console devices and information

cp - memory copy

crc32 - checksum calculation

date - get/set/reset date & time

18

dboot - Digi ConnectCore modules boot commands

dcache - enable or disable data cache

dhcp - invoke DHCP client to obtain IP/boot params

echo - echo args to console

envreset- Sets environment variables to default setting

fatinfo - print information about filesystem

fatload - load binary file from a dos filesystem

fatls - list files in a directory (default /)

flpart - displays or modifies the partition table.

go - start application at address 'addr'

help - print online help

icache - enable or disable instruction cache

icrc32 - checksum calculation

iloop - infinite loop on address range

imd - i2c memory display

iminfo - print header information for application image

imm - i2c memory modify (auto-incrementing)

imw - memory write (fill)

inm - memory modify (constant address)

intnvram- displays or modifies NVRAM contents like IP or partition table

iprobe - probe to discover valid I2C chip addresses

itest - return true/false on integer compare

loadb - load binary file over serial line (kermit mode)

loads - load S-Record file over serial line

loady - load binary file over serial line (ymodem mode)

loop - infinite loop on address range

19

md - memory display

mm - memory modify (auto-incrementing)

mtest - simple RAM test

mw - memory write (fill)

nand - NAND sub-system

nboot - boot from NAND device

nfs - boot image via network using NFS protocol

nm - memory modify (constant address)

ping - send ICMP ECHO_REQUEST to network host

printenv- print environment variables

printenv_dynamic- Prints all dynamic variables

rarpboot- boot image via network using RARP/TFTP protocol

reset - Perform RESET of the CPU

run - run commands in an environment variable

saveenv - save environment variables to persistent storage

setenv - set environment variables

sleep - delay execution for some time

sntp - synchronize RTC via network

tftpboot- boot image via network using TFTP protocol

update - Digi ConnectCore modules update commands

usb - USB sub-system

usbboot - boot from USB device

version - print monitor version

The available commands vary according to the capabilities of the hardware platform.

For more information about a command, enter:

help command name

For example:

20

# help run

run var [...]

- run the commands in the environment variable(s) 'var'

As the first characters of a command are entered, U-Boot searches its list of built-in

commands until it finds a match. For example, entering save or sav or even sa, causes

U-Boot to execute the saveenv command.

U-Boot needs enough characters to be entered to determine the command to execute.

For example, if loa is entered, U-Boot cannot tell whether to execute loadb, loads or

loady, and an Unknown command message is displayed.

Information commands

Commands that information about the development board, devices, memory, etc.,

include:

Command Description

bdinfo Prints board info structure.

coninfo Prints console devices and information.

date [MMDDhhmm[[CC]YY][.ss]] Gets, sets, or resets system date/time.

fatinfo <interface> <dev[:part]> Prints information about the file system from dev on

interface.

iminfo addr [addr ...] Prints header information for the application image starting at

the addr address in memory, including verification of the image contents (magic

number, header, and payload checksums). Works only for Linux kernel images.

nand bad Shows NAND bad blocks.

nand info Shows available NAND devices.

version Displays U-Boot version and timestamp.

Network commands:

Network-related commands include:

Command Description

bootp [loadAddress] [bootFilename] Boots the image over the network using the

BootP/TFTP

protocol. If no argument is given, bootp takes the values from the loadaddr and

bootfile environment variables.

dhcp Requests an IP address from a DHCP server, set in the serverip system

variable. If the autoload variable is set to yes, also transfers the file to which the

21

bootfile environment variable points to the loadAddress RAM memory address by

TFTP.

nfs [loadAddress] [host ip addr:bootfilename]

Using NFS, transfers image bootfilename into the RAM address loadAddress.

ping <pingAddress> Pings the IP address passed as parameter. If the other end

responds, this message is displayed:

host <pingAddress> is alive.

rarpboot [loadAddress] [bootfilename] Using RARP/TFTP, transfers image into the

RAM address loadAddress.

sntp Gets the date and time from the NTP server to which the ntpserverip

environment variable points..

tftpboot [loadAddress] [bootfilename] Using FTP, transfers image bootfilename into

the RAM

address loadAddress.

If the autostart variable is set to 'yes', all commands (except ping) boot the transferred

image by calling the bootm command. bootm does not work for WinCE images. If

working

with a WinCE image file, either set the autostart variable to 'no' or delete it before

executing these network commands.

4.3)USB commands:To access the USB subsystem, use the usb command, followed by its operations:

Command Description

usb reset Resets (rescans) USB controller.

usb stop [f] Stops USB [f]=force stop.

usb tree Shows USB device tree.

usb info [dev] Shows available USB devices.

usb storage Shows details of USB storage devices.

usb dev [dev] Shows or sets current USB storage device.

usb part [dev] Prints the partition table of one (dev) or all USB storage devices.

usb read addr blk# cnt Reads cnt blocks starting at block blk# to RAM address addr.

fatload usb <dev[:part]> <addr> <filename>

22

Reads filename image from partition part of USB device dev into the RAM memory

address addr. If part is not specified, partition 1 is assumed.

usbboot Boots from USB device.

Memory commands:

These commands manage RAM memory:

Command Description

cmp[.b, .w, .l] addr1 addr2 count Compares memory contents from address addr to

addr2 for as many count bytes, words, or long words.

cp[.b, .w, .l] source target count Copies memory contents from address source to

target for as many count bytes, words, or long words.

go addr [arg ...] Starts the application at address addr passing arg as arguments.

md[.b, .w, .l] address [# of objects] Displays memory contents at address addr for as

many [#of objects] bytes, words, or long words.

mm[.b, .w, .l] address Modifies locations of memory, beginning at address, which

gets auto-incremented.

mw[.b, .w, .l] address value [count] Writes value into address for as many count

bytes, words,

or long words.

nm[.b, .w, .l] address Modifies a fixed location of memory.

nand read addr off size Copies memory contents from flash address off to RAM

address addr for as many size bytes (only for NAND flash memories).

nand write addr off size Copies memory contents from RAM address addr to flash

address off for as many size bytes (NAND flash memories only).

nand erase [off size] Erases size bytes from address off. Erases entire device if no

parameters are specified (NAND flash memories only). U-Boot skips bad blocks and

shows their addresses.

nand dump[.oob] off Dumps NAND page at address off with optional out-of-band

data (only for NAND flash memories).

nboot address dev [off] Boots image from NAND device dev at offset off

(transferring it first to RAM address).

Serial port commands

Use these commands to work with the serial line:

Command Description

23

loadb [off] [baud] Loads binary file over serial line with offset off and baud rate

baud (Kermit mode).

loads [off] Loads S-Record file over the serial line with offset off.

loady [off] [baud] Loads binary file over the serial line with offset off and baud rate

baud (Ymodem mode).

I2C commands

These commands interface with the I2C interface:

Command Description

iloop chip address[.0, .1, .2] [# of objects]

Loops, reading a set of I2C addresses.

imd chip address[.0, .1, .2] [# of objects]

Displays I2C memory.

imm chip address[.0, .1, .2] Modifies I2C memory with an auto-incremented address.

imw address[.0, .1, .2] value [count] Fills an I2C memory range with value.

inm chip address[.0, .1, .2] Modifies memory, reads and keeps an address.

iprobe Discovers valid I2C chip addresses.

itest [.b, .w, .l, .s] [*]value1 <op>[*]value2

Returns TRUE/FALSE on integer compare.

Environment variable commands

To read, write, and save environment variables, use these commands:

Command Description

printenv [name ...] If no variable is given as argument, prints all U-Boot environment

variables.

If a list of variable names is passed, prints only those variables.

printenv_dynamic Prints all dynamic variables.

envreset Overwrites all current variables values to factory default values.

Does not reset the wlanaddr or ethaddr variables or any other persistent settings

stored in NVRAM

saveenv Writes the current variable values to non-volatile memory (NVRAM).

setenv name [value] If no value is given, the variable is deleted. If the variable is

dynamic, it is reset to the default value. If a value is given, sets variable name to value

value

24

4.4) Linux Kernel 2.6.32:Linux is an open source operating system running on all major processor

architectures, including ARM processors. It enjoys support by a large group of

engineers contributing back into the open source (similar process to the FSF's GNU

tools).This makes Linux a very dynamic and fast moving operating system.

Advantages of Linux on ARM 

Complete scalable operating system providing a reliable multi-tasking

environment ,Based on an open source model (GPL),Leverage a wide range of

UNIX and open source applications,Early availability on ARM processor-

based platforms ,Used in many ARM technology-based designs

including networking and wireless products ,Broad support through open

discussion forums.

Root File System:

Fig 8.root file system

25

The root file system is very important to work on linux os.it will decides the

file permissions of user and all system related packages are installed in lib folder and

all external devices related file are present in the dev folder of the root file system.the

root file system tree diagram is shown in fig 8.this root file system is very important

when we porting on arm development board.

4.5) Bluetooth stack

The Linux operating system currently has two widespread Bluetooth stack

implementations:

1)BlueZ, included with the official Linux kernel distributions, initially

developed by Qualcomm.

2)Affix, developed by Nokia Research Center.

In addition to the basic stack, the bluez-utils and bluez-firmware packages

contain low level utilities such as dfutool which can interrogate the Bluetooth adapter

chipset to determine whether its firmware can be upgraded. hidd is the Bluetooth

human interface device (HID) daemon.

Bluetooth is defined as a layer protocol architecture consisting of core

protocols, cable replacement protocols, telephony control protocols, and adopted

protocols. Mandatory protocols for all Bluetooth stacks are: LMP, L2CAP and SDP.

In addition, devices that communicate with Bluetooth almost universally can use these

protocols HCI and RFCOMM.

26

Figure 9: Bluetooth Stack

LMP

The Link Management Protocol (LMP) is used for control of the radio link between

two devices. Implemented on the controller.

27

AVRCP

AV Remote Control Profile. Commonly used in car navigation systems to control

streaming Bluetooth audio. Adopted versions 1.0, 1.3 & 1.4

L2CAP

The Logical Link Control and Adaptation Protocol (L2CAP) Used to multiplex

multiple logical connections between two devices using different higher level

protocols. Provides segmentation and reassembly of on-air packets.

In Basic mode, L2CAP provides packets with a payload configurable up to 64kB,

with 672 bytes as the default MTU, and 48 bytes as the minimum mandatory

supported MTU.

In Retransmission and Flow Control modes, L2CAP can be configured either for

isochronous data or reliable data per channel by performing retransmissions and CRC

checks.

Bluetooth Core Specification Addendum 1 adds two additional L2CAP modes to the

core specification. These modes effectively deprecate original Retransmission and

Flow Control modes:

Enhanced Retransmission Mode (ERTM): This mode is an improved

version of the original retransmission mode. This mode provides a reliable

L2CAP channel.

Streaming Mode (SM): This is a very simple mode, with no retransmission or

flow control. This mode provides an unreliable L2CAP channel.

Reliability in any of these modes is optionally and/or additionally guaranteed by the

lower layer Bluetooth BDR/EDR air interface by configuring the number of

retransmissions and flush timeout (time after which the radio will flush packets). In-

order sequencing is guaranteed by the lower layer.

Only L2CAP channels configured in ERTM or SM may be operated over AMP

logical links.

SDP

The Service Discovery Protocol (SDP) allows a device to discover services offered by

other devices, and their associated parameters. For example, when you use a mobile

phone with a Bluetooth headset, the phone uses SDP to determine which Bluetooth

profiles the headset can use (Headset Profile, Hands Free Profile, Advanced Audio

Distribution Profile (A2DP) etc.) and the protocol multiplexer settings needed for the

phone to connect to the headset using each of them. Each service is identified by a

28

Universally Unique Identifier (UUID), with official services (Bluetooth profiles)

assigned a short form UUID (16 bits rather than the full 128).

RFCOMM

Radio Frequency Communications (RFCOMM) is a cable replacement protocol used

to create a virtual serial data stream. RFCOMM provides for binary data transport and

emulates EIA-232 (formerly RS-232) control signals over the Bluetooth baseband

layer, i.e. it is serial port emulation.

RFCOMM provides a simple reliable data stream to the user, similar to TCP. It is

used directly by many telephony related profiles as a carrier for AT commands, as

well as being a transport layer for OBEX over Bluetooth.

Many Bluetooth applications use RFCOMM because of its widespread support and

publicly available API on most operating systems. Additionally, applications that used

a serial port to communicate can be quickly ported to use RFCOMM.

BNEP

The Bluetooth Network Encapsulation Protocol (BNEP) is used for transferring

another protocol stack's data via an L2CAP channel. Its main purpose is the

transmission of IP packets in the Personal Area Networking Profile. BNEP performs a

similar function to SNAP in Wireless LAN.

AVCTP

The Audio/Video Control Transport Protocol (AVCTP) is used by the remote control

profile to transfer AV/C commands over an L2CAP channel. The music control

buttons on a stereo headset use this protocol to control the music player.

AVDTP

The Audio/Video Distribution Transport Protocol (AVDTP) is used by the advanced

audio distribution profile to stream music to stereo headsets over an L2CAP channel.

Intended to be used by video distribution profile in the bluetooth transmission.

TCS

The Telephony Control Protocol – Binary (TCS BIN) is the bit-oriented protocol that

defines the call control signaling for the establishment of voice and data calls between

Bluetooth devices. Additionally, "TCS BIN defines mobility management procedures

for handling groups of Bluetooth TCS devices."

TCS-BIN is only used by the cordless telephony profile, which failed to attract

implementers. As such it is only of historical interest.

29

Adopted protocols

Adopted protocols are defined by other standards-making organizations and

incorporated into Bluetooth’s protocol stack, allowing Bluetooth to create protocols

only when necessary. The adopted protocols include:

Point-to-Point Protocol (PPP)

Internet standard protocol for transporting IP datagrams over a point-to-point

link.

TCP/IP/UDP

Foundation Protocols for TCP/IP protocol suite

Object Exchange Protocol (OBEX)

Session-layer protocol for the exchange of objects, providing a model for

object and operation representation

Wireless Application Environment/Wireless Application Protocol (WAE/WAP)

WAE specifies an application framework for wireless devices and WAP is an

open standard to provide mobile users access to telephony and information

services.

4.6) BlueZ

Bluez is the Bluetooth stack for Linux. Its goal is to make an implementation of the

Bluetooth wireless standards specifications for Linux. As of 2006, the BlueZ stack

supports all core Bluetooth protocols and layers. It was initially developed by

Qualcomm, and is available for Linux kernel versions 2.4.6 and up.

Startup Mode Selection

To choose the development board startup mode, S2 DIP-switch is determined,

Depending on the target board tips. Switch S2 to _NOR" side logo, the system will

start with the NOR flash. Switch S2 to _NAND" side logo, the system will start with

the NAND Flash. The NOR Flash and NAND Flash of the development board has

been burned into the Same BIOS from factory (because the BIOS at the same time

support for both flash, just after the boot of different manifestations, please refer to

"development board BIOS feature and use that"), S2 has been receiving side of

NAND flash, the system boot from a startup operation of NAND flash system.

30

External Interface Connector

Please use our direct serial line to connect the Mini2440/s serial port 0 and

PC/s.

Use our crossover cable to the network interface Mini2440 connected with the

PC.

Use our 5 V power adapter to connect to the 5 V input socket on the board.

Steps to load Bluez stack in PC

1. Go to root directory in Linux using command “sudo -i”

2. Go to folder containing Bluetooth stack files using command “CD

filename”(Change Directory).

3. Type the command “tar –xvf filename to be extracted”.

4. Cd filename of the file extracted

5. ./configure –prefix =/usr

6. Make

7. Sudo Make install.

By using above steps load the following Bluetooth stack files in given sequence order

1. Expat

2. Glib

3. Dbus

4. Bluez

5. Open obex

4.7) Open OBEX:

The object model addresses the question of how objects are represented by

OBEX. The model must deal with both the object being transferred and information

about the object. It does this by putting the pieces together in a sequence of headers. A

header is an entity that describes some aspect of the object, such as name, length,

descriptive text, or the object body itself. For instance, headers for the file jumar.txt

might contain the name, a type identifier of “text”, a description saying “How to use

jumars to grow better tomatoes”, the file length, and the file itself.

31

OBEX Headers:

Headers have the general form:

<HI, the header ID>

<HV, the header value>

HI, the header ID, is an unsigned one-byte quantity that identifies what the

header contains and how it is formatted. HV consists of one or more bytes in the

format and meaning specified by HI. All headers are optional - depending on the type

of device and the nature of the transaction, you may use all of the headers, some, or

none at all. IDs make headers parseable and order independent, and allow

unrecognized headers to be skipped easily. Unrecognized headers should be skipped

by the receiving device.

OBEX defines a set of headers that are used quite frequently and therefore benefit

from a compact representation. It also provides a mechanism to use any HTTP header,

as well as user defined headers.

This small set will serve the needs of file transfer on PCs as well as the needs of many

other devices, while facilitating a clean mapping to HTTP when OBEX is used as a

compact final hop in a web communication.

The low order 6 bits of the header identifier are used to indicate the meaning of the

header, while the upper 2 bits are used to indicate the header encoding. This encoding

provides a way to interpret unrecognized headers just well enough to discard them

cleanly. The length prefixed header encodings send the length in network byte order,

and the length includes the 3 bytes of the identifier and length. For Unicode text, the

length field (immediately following the header ID) includes the 2 bytes of the null

terminator (0x00, 0x00). Therefore the length of the string ”Jumar” would be 12

bytes; 5 visible characters plus the null terminator, each two bytes in length.

The 2 high order bits of HI have the following meanings (shown both as bits and as a

byte value):

32

Headers Identifiers:

TABLE1:header identifier

Session Protocol:

33

The session protocol describes the basic structure of an OBEX conversation. It

consists of a format for the “conversation” between devices and a set of opcodes that

define specific actions. The OBEX conversation occurs within the context of an

OBEX connection. The connection oriented session allows capabilities information to

be exchanged just once at the start of the connection, and allows state information to

be kept (such as a target path for PUT or GET operations).

OBEX follows a client/server request-response paradigm for the conversation

format. The terms client and server refer to the originator/receiver of the OBEX

connection, not necessarily who originated the low level IrLAP connection. Requests

are issued by the client (the party that initiates the OBEX connection).

Once a request is issued, the client waits for a response from the server before issuing

another request.The request/response pair is referred to as an operation.

OBEX Operations and Opcode definitions

OBEX operations consist of the following:

TABLE2:obex operations

Connect operation

This operation initiates the connection and sets up the basic expectations of each side of the link.

34

The request format is:

Byte 0 Byte 1-2 Byte 3 Byte 4 Byte 5-6 Byte 7 Byte 8 Byte 9-12 Byte 13 Byte 14-15

0xA0 0x001F 0x10 0x10 0x007F 0xCB 0x01 0x00000001 0x4A 0x0013

The CONNECT request and response must each fit in a single packet.

Implementations are not required to recognize more than the first 7 bytes of these

packets, though this may restrict their usage.

Disconnect

This opcode signals the end of the OBEX session. It may include a Description

header for additional user readable information. The DISCONNECT request and

response must each fit in one OBEX packet and have their Final bits set.

The request format is:

The response to DISCONNECT is 0xA0 (Success), optionally followed with a

Description header. A DISCONNECT may not be refused. However, if the

disconnect packet contains invalid information, such as an invalid Connection Id

35

Byte 16-310xF9EC7BC4953C11D2984E525400DC9E09

header the response code may be “Service Unavailable” (0xD3). Server side handling

of this case is not required.

The response format is:

It is permissible for a connection to be terminated by closing the transport connection

without issuing the OBEX DISCONNECT operation. Though, this precludes any

opportunity to include descriptive information about the disconnection. Currently, this

is common practice and DISCONNECT is infrequently used. However, it is good

practice to send an OBEX DISCONNECT for each OBEX CONNECT sent but few

applications track or care about such details.

The Request Format is---

Byte 0 Byte 1-2 Byte 3 Byte 4-7

0x81 0x0008 0xCB 0x00000001

Format of the abort request

The Response Format is---

Byte 0 Byte 1-2

0xA0 0x0003

Format of the abort response

PUT :

The PUT operation sends one object from the client to the server. The request will

normally have at least the following headers: Name and Length. For files or other

objects that may have several dated versions, the Date/Time header is also

recommended, while the Type is very desirable for non-file object types.

However, any of these may be omitted if the receiver can be expected to know the

information by some other means. For instance, if the target device is so simple that it

accepts only one object and prevents connections from unsuitable parties, all the

headers may be omitted without harm. However, if a PC, PDA, or any other general-

purpose device is the intended recipient, the headers are highly recommended.

36

A PUT request consists of one or more request packets, the last

of which has the Final bit set in the opcode. The implementer may choose whether to

include an object Body header in the initial packet, or wait until the response to a

subsequent packet is received before sending any object body chunks.

The request format is:

Each packet is acknowledged by a response from the server as described in the

general session model discussion above.

Put Response

The response for successfully received intermediate packets (request packets without

the Final bit set) is 0x90 (Continue, with Final bit sent). The successful final response

is 0xA0 (Success, with Final bit set). The response to any individual request packet

must itself consist of just one packet with its Final bit set - multi-packet responses to

PUT are not permitted

Any other response code indicates failure. If the length field of the response is > 3

(the length of the response code and length bytes themselves), the response includes

headers, such as a Description header to expand on the meaning of the response code

value.

The response format is:

Here is a typical Final response:

37

For example: The client requests the server to put the file Jonas.txt to the server. The

size of the file is 155 bytes.

The request format is:

Byte 0 Byte 1-2 Byte 3 Byte 4-7 Byte 8 Byte 9-10 Byte 11-36 Byte 37 Byte 38-39 Byte 40-194

0x82 0x002B 0xCB 0x00000001 0x01 0x0024 Jonas.txt\0 0x49 0x000B …

The response format is:

The successful response packet for a request to put the file JonasBredband.txt

The request to delete a file is given as----

Byte 0 Byte 1-2 Byte 3 Byte 4-7 Byte 8 Byte 9-10 Byte 11-220x82 0x00 0xCB 0x00000001 0x01 0x0019 Marcus.txt\0

Table . A request to delete the file Marcus.txt

In this case the file is Marcus.txt, no body header is used.

The successful response packet for a request to delete the file Marcus.txt

Byte 0 Byte 1-20xA0 0x0003

The successful response packet for a request to delete the file Marcus.txt

4.8) SOCKET PROGRAMMING

To the kernel, a socket is an endpoint of communication. To an application, a

socket is a file descriptor that lets the application read/write from/to the network. The

socketsAre required if a processs in one system need to communicate with process on

another system. Clients and servers communicate with each by reading from and

writing to socket descriptors.

38

Byte 0 Byte 1-2

0xA0 0x0003

The main distinction between regular file I/O and socket I/O is how the

application “opens” the socket descriptors.

Network Byte Ordering:

Network is big-endian, host may be big- or little-endian Functions work on

16-bit (short) and 32-bit (long) values htons() / htonl() convert host byte order to

network byte order ntohs() / ntohl() convert network byte order to host byte.

Socket primitives:

In terms of telephone analogy socket programming need following system

calls.

Socket() – Endpoint for communication

Bind() - Assign a unique telephonenumber.

Listen() – Wait for a caller.

Connect() - Dial a number.

Accept() – Receive a call.

Send(), Recv() – Talk.

Close() – Hang up.

Socket:

To create an end point for communication.

Syntax:

int socket(int domain, int type, int protocol);

explanation:

domain := AF_INET (IPv4 protocol)

type := (SOCK_DGRAM or SOCK_STREAM )

protocol := 0 (IPPROTO_UDP or IPPROTO_TCP)

returned: socket descriptor (sockfd), -1 is an error

BIND:

39

A server process calls bind to attach itself to a specific port and IP address.Syntax:

int bind(int sockfd, struct sockaddr*my_addr, int addrlen);

sockfd - socket descriptor (returned from socket())

my_addr: socket address, struct sockaddr_in is used

addrlen := sizeof(struct sockaddr)

LISTEN:

The server process calls listen to tell the kernel to initialize a wait queue of

connections for this socket.

Syntax:

int listen(int sockfd, int backlog);

backlog: how many connections we want to queue

ACCEPT:

Accept is called by a Server process to accept new connections from new

clients trying to connect to the server

Syntax:

int accept(int sockfd, void *addr, int*addrlen);

addr: here the socket-address of the caller will be written

returned: a new socket descriptor (for the temporal socket)

CONNECT:

Connect is called by a client to connect to a server port

Syntax:

int connect(int sockfd, struct sockaddr*serv_addr, int addrlen); //used by

TCP client

parameters are same as for bind()

SEND:

Syntax:

int send(int sockfd, const void *msg, int len, int flags);

msg: message you want to send

40

len: length of the message

flags := 0

returned: the number of bytes actually sent

RECEIVE:

Syntax:

int recv(int sockfd, void *buf, int len, unsigned int flags);

buf: buffer to receive the message

len: length of the buffer (“don’t give me more!”)

flags := 0

returned: the number of bytes received

SEND (DGRAM-style):

Syntax:

int sendto(int sockfd, const void*msg, int len, int flags, const struct

sockaddr *to, int tolen);

msg: message you want to send

len: length of the message

flags := 0

to: socket address of the remote process

tolen: = sizeof(struct sockaddr)

returned: the number of bytes actually sent

RECEIVE (DGRAM-style):

Syntax:

int recvfrom(int sockfd, void*buf, int len, unsigned int flags, struct

sockaddr

*from, int *fromlen);

buf: buffer to receive the message

len: length of the buffer (“don’t give me more!”)

from: socket address of the process that sent the data

fromlen:= sizeof(struct sockaddr)

flags := 0

returned: the number of bytes received

41

CLOSE:

Close signals the end of communication between a server-client pair. This

effectively closes the socket.

Syntax:

close (socketfd);

TCP/IP :

the fig.10 shows the client –sever model of socket programming based on the

TCP/IP protocol.when client performs the write operation the server performs read

operation only. If the server performs the write operation the client performs read

operation only.

42

Fig 10. client-server

Hardware

4.9)Bluetooth Dongle :

43

Bluetooth is a wireless personal area network (PAN) technology from the

Bluetooth Special Interest Group, (www.bluetooth.com), founded in 1998 by

Ericsson, IBM, Intel, Nokia and Toshiba. Bluetooth is an open standard for short-

range transmission of digital voice and data between mobile devices (laptops, PDAs,

phones) and desktop devices. It supports point-to-point and multipoint applications.

Bluetooth provides up to 723 kb/s data transfer within a range of 10 m and up to 100

m with a power amplifier.

Unlike IrDA, which requires that devices are aimed at each other (in line of

sight), Bluetooth uses omnidirectional radio waves that can transmit through walls

and other non-metal barriers. Bluetooth transmits in the unlicensed 2.4GHz band and

uses a frequency hopping spread spectrum (FHSS) technique, which chops up the data

being sent and transmits chunks of it on up to 79 bands (1 MHz each; centered from

2402 to 2480 MHz) in the range 2,400–2,483.5 MHz (allowing for guard bands). It

usually performs 800 hops per second, with AFH enabled. If there is interference

from other devices, the transmission does not stop, but its speed is downgraded. The

name Bluetooth comes from King Harald Blatand (Blueto oth) of Denmark.

Bluetooth is a wireless radio standard primarily designed for low power

consumption, with a short range (up to 10 meters) and with a low-cost transceiver

microchip in each device. It can be used to wirelessly connect peripherals like

printers or keyboards to computers, or to have PDAs communicate with other nearby

PDAs or computers.

The standard also includes support for more powerful, longer-range devices

suitable for constructing wireless LANs. Any device may perform an "inquiry" to find

other devices to which to connect, and any device can be configured to respond to

such inquiries.

Pairs of devices may establish a trusted relationship by learning (by user input)

a shared secret known as a "passkey". A device that wants to communicate only with

a trusted device can cryptographically authenticate the identity of the other device.

Trusted devices may also encrypt the data that they exchange over the air so that no

one can listen in.

44

The protocol operates in the license-free ISM band at 2.45 GHz . In order to

avoid interfering with other protocols which use the 2.45 GHz band, the Bluetooth

protocol divides the band into 79 channels (each 1 MHz wide) and changes channels

up to 1600 times per second. Implementations with versions 1.1 and 1.2 reach speeds

of 723.1 kbit /s. Version 2.0 implementations feature Bluetooth Enhanced Data Rate

(EDR) , and thus reach 2.1 Mbit /s. Technically version 2.0 devices have a higher

power consumption, but the three times faster rate reduces the transmission times,

effectively reducing consumption to half that of 1.x devices (assuming equal traffic

load).

Embedded Bluetooth

Bluetooth devices and modules are increasingly being made available which

come with an embedded stack and a standard UART port. The UART protocol can be

as simple as the industry standard AT protocol, which allows the device to be

configured to cable replacement mode. This means it now only takes a matter of hours

(instead of weeks) to enable legacy wireless products that communicate via UART

port.

Bluetooth 2.0 :

The bluetooth 2.0 is selected because it supports all the usb ports of system.

This version is backwards compatible with 1.x and the major enhancements

include Non-hopping narrowband channel(s) introduced. These are faster but have

been criticized as defeating a built-in security mechanism of earlier versions; however

frequency hopping is hardly a reliable security mechanism by today's standards.

Rather, Bluetooth security is based mostly on cryptography. Broadcast/ multicast

support . Non-hopping channels are used for advertising Bluetooth service profiles

offered by various devices to high volumes of Bluetooth devices simultaneously,

since there is no need to perform handshaking with every device. (In previous

versions the handshaking process takes a bit over one second.) .Enhanced Data Rate

(EDR) of 2.1 Mbit /s,Built-in quality of service,Distributed media-access control

protocols,Faster response times. Halved power consumption due to shorter duty

45

cycles. Originally Gaussian frequency-shift keying (GFSK) modulation was the only

modulation scheme available; subsequently, since the introduction of Bluetooth

2.0+EDR, π/4-DQPSK and 8DPSK modulation may also be used between compatible

devices. Devices functioning with GFSK are said to be operating in basic rate (BR)

mode where an instantaneous data rate of 1 Mbit/s is possible. The term Enhanced

Data Rate (EDR) is used to describe π/4-DPSK and 8DPSK schemes, each giving 2

and 3 Mbit/s respectively. The combination of these (BR and EDR) modes in

Bluetooth radio technology is classified as a "BR/EDR radio".Using the Bluetooth

technology for broadcasting information allows for a way of broadcasting that is quite

different from any other currently common broadcasting technologies. Bluetooth

broadcasting will most likely not be able to replace broadcasting systems like

television and radio broadcasts, or even message transmission technologies like e-

mail, SMS/MMS and instant messengers (one example on instant messengers is MSN

Messenger).However, Bluetooth broadcasting can be used in situations where the

other technologies are not as suitable. Bluetooth adapters work using the plug-and-

play feature of the Windows and Mac operating systems, so they can be removed and

reinserted at any time. When you plug a device in, the software driver stored in the

device is transferred to and interpreted by the operating system. There is usually no

installation required, although some adapters do require you to install drivers from a

CD the first time you use them. Once it's installed, the adapter usually lights up and

begins sending signals to search for Bluetooth devices in the area. If it finds any, you

are given the option to communicate with them.

A Bluetooth system today usually consists of two physically separated parts.

One is the Bluetooth module and the other one is the host, e.g. the PC or the

embedded system that is going to use the transferred information. These two parts

communicate with each other over UART or USB using the Host controller interface,

HCI, protocol. Thus the Bluetooth stack is divided in two parts. The stack which

resides inside the host, e.g. PC or PDA, is referred to as the host stack.

THE BLUETOOTH MODULE

The module itself is a small embedded system on a small PCB and it consists

of a number of parts; the Baseband (the processing unit), the Flash memory, a 13MHz

46

crystal, and a radio module. The module has not itself an internal antenna; such a

device must be added externally.

FIG 11.bluetooth dongle

The baseband chip inside the module is used to control the radio traffic is shown in

fig 11. Watched from inside the baseband chip, it processes commands from the host,

establishes links to other Bluetooth devices and sends commands, status and data over

the radio link. It also, of course, receives data and commands from other devices and

handles error correction, encryption and retransmissions. The baseband chip,

encapsulates an Arm7 processing unit, 56k RAM, different communication interfaces

and 8 address pins that can be set to be GP I/O pins if one wishes to. It has also some

Bluetooth specific hardware where some of the functionality resides.

An external flash memory of 8MBit (1Mb) is included in the module. The

Bluetooth firmware resides inside this memory. A flash memory is used today, even

though it is much more expensive than a ROM, this is probably mainly because of the

constant upgrades of the firmware under the development phase that Bluetooth

module undergoes today. In the future the flash will most certainly be replaced with a

ROM.

The Bluetooth radio module is in fact a module in itself. It is a short-range microwave

47

requency radio transceiver for Bluetooth communication. The module is designed to

operate in the globally available ISM frequency band, 2.4 -2.5 GHz. Fast frequency

hopping (1600 channel hops/s) with 79 channels available (2.402 to 2.480 GHz) and a

maximum TX & RX bit rate of 1 MBit/s exploits the maximum channel bandwidth

allowed in the unlicensed ISM band.

The Bluetooth module includes firmware for the Host Controller Interface

(HCI), and the link manager (LM) and the baseband operating system; in Ericsson

module it is OSE delta. The firmware (FW) resides in the flash. The protocol stack in

the firmware is fully specified in the Bluetooth specification since it is absolutely

necessary that the information sent runs over identical protocol stacks. The protocol

stack in the firmware consists of two layers, the HCI and the Link Manager Protocol

layer seen in Figure 12. The Link Controller is a hardware block which controls the

radio.

Figure 12 The Controller Bluetooth stack

48

The HCI layer can be seen as a "Bluetooth language". It is a set of instructions

used for communication between a Host and a Host Controller (e.g. a Bluetooth

module and a PC). The HCI protocol layer has a set of standardized commands and

signals but can also implement producer specific commands. The HCI layer

communicates with either the host's HCI layer through a hardware interface driver or

it communicates with the Link Manager.

The Link Manager in each Bluetooth module can communicate with another

Link Manager in another Bluetooth module using the Link Manager Protocol (LMP),

which is a peer-to-peer protocol.

4.10) ARM9 Architecture

SAMSUNG's S3C2440A 16/32-bit RISC microprocessor. SAMSUNG’s

S3C2440A is designed to provide hand-held devices and general applications with

low-power, and high-performance microcontroller solution in small die size. To

reduce total system cost, the S3C2440A includes the following components.

The S3C2440A is developed with ARM920T core, 0.13um CMOS standard

cells and a memory complier. Its low power, simple, elegant and fully static design is

particularly suitable for cost- and power-sensitive applications. It adopts a new bus

architecture known as Advanced Micro controller Bus Architecture (AMBA). The

S3C2440A offers outstanding features with its CPU core, a 16/32-bit ARM920T

RISC processor designed by Advanced RISC Machines, Ltd. The ARM920T

implements MMU, AMBA BUS, and Harvard cache architecture with separate 16KB

instruction and 16KB data caches, each with an 8-word line length. By providing a

complete set of common system peripherals, the S3C2440A minimizes overall system

costs and eliminates the need to configure additional components. The integrated on-

chip functions that are described in this document include:Around 1.2V internal,

1.8V/2.5V/3.3V memory, 3.3V external I/O microprocessor with 16KB

I-Cache/16KB D-Cache/MMU ,External memory controller (SDRAM Control and

Chip Select logic) ,LCD controller (up to 4K color STN and 256K color TFT) with

49

LCD-dedicated DMA,4-ch DMA controllers with external request pins,3-ch UARTs

(IrDA1.0, 64-Byte Tx FIFO, and 64-Byte Rx FIFO),2-ch SPI ,IIC bus interface

(multi-master support) ,IIS Audio CODEC interface AC’97 CODEC interface ,SD

Host interface version 1.0 & MMC Protocol version 2.11 compatible 2-ch USB Host

controller / 1-ch USB Device controller (ver 1.1)4-ch PWM timers / 1-ch Internal

timer / Watch Dog Timer ,8-ch 10-bit ADC and Touch screen interface RTC with

calendar function ,Camera interface (Max. 4096 x 4096 pixels input support. 2048 x

2048 pixel input support for scaling) 130 General Purpose I/O ports / 24-ch external

interrupt source ,Power control: Normal, Slow, Idle and Sleep mode ,On-chip clock

generator with PLL

ARCHITECTURE:

Integrated system for hand-held devices and General embedded applications 16/32-

Bit RISC architecture and powerful Instruction set with ARM920T CPU core.

Enhanced ARM architecture MMU to support WinCE, EPOC 32 and Linux.

Instruction cache, data cache, write buffer and Physical address TAG RAM to reduce

the effect of main memory bandwidth and latency on Performance.ARM920T CPU

core supports the ARM debug Architecture.Internal Advanced Microcontroller Bus

Architecture (AMBA) (AMBA2.0, AHB/APB).

SYSTEM MANAGER

Little/Big Endean support. Support Fast bus mode and Asynchronous bus mode.

Address space: 128M bytes for each bank (total 1G bytes).Supports

programmable 8/16/32-bit data bus width for each bank.Fixed bank start address

from bank 0 to bank 6.Programmable bank start address and bank size for bank

7.Eight memory banks: Six memory banks for ROM, SRAM, and others.Two

memory banks for ROM/SRAM/Synchronous DRAM.Complete Programmable

access cycles for all memory banks.Supports external wait signals to expand the

bus cycle.Supports self-refresh mode in SDRAM for power down.Supports

various types of ROM for booting (NOR/NAND Flash, EEPROM, and others).

50

NAND Flash Boot Loader

Supports booting from NAND flash memory, Supports storage memory for NAND

flash memory after booting.Supports Advanced NAND flash.

Cache Memory

Cache is 64-way set-associative cache with I-Cache (16KB) and D-Cache

(16KB),8words length per line with one valid bit and two dirty bits per

line,Pseudo random or round robin replacement algorithm.Write-through or

write-back cache operation to update the main memory.The write buffer can

hold 16 words of data and four addresses.

CLOCK & POWER MANAGER

On-chip MPLL and UPLL: UPLL generates the clock to operate USB

Host/Device. MPLL generates the clock to operate MCU at maximum

400MHz @ 1.3V.Clock can be fed selectively to each function block by

software.

Power mode: Normal, Slow, Idle, and Sleep mode

Normal mode: Normal operating mode

Slow mode: Low frequency clock without PLL

Idle mode: The clock for only CPU is stopped.

Sleep mode: The Core power including all peripherals is shut down.

Woken up by EINT[15:0] or RTC alarm interrupt from Sleep mode

INTERRUPT CONTROLLER

interrupt sources of 60 (One Watch dog timer, 5 timers, 9 UARTs, 24 external

interrupts, 4 DMA, 2 RTC, 2 ADC, 1 IIC, 2 SPI, 1 SDI, 2 USB, 1 LCD, 1

Battery Fault, 1 NAND and 2 Camera), 1 AC97 Level/Edge mode on external

interrupt sourceProgrammable polarity of edge and level Supports Fast

Interrupt request (FIQ) for very urgent interrupt request

TIMER WITH PULSE WIDTH MODULATION (PWM)

4-ch 16-bit Timer with PWM / 1-ch 16-bit internal timer with DMA-based or

interrupt-based operation Programmable duty cycle, frequency, and polarity Dead-

zone generation Supports external clock sources

51

RTC (REAL TIME CLOCK)

Full clock feature: millisecond, second, minute, hour, date, day, month, and year with

32.768 KHz operation,Alarm interrupt,Time tick interrupt.

GENERAL PURPOSE INPUT/OUTPUT PORTS

24 external interrupt ports and 130 Multiplexed input/output ports.

DMA CONTROLLER

4-ch DMA controller,Supports memory to memory, IO to memory, memory to

IO, and IO to IO transfers,Burst transfer mode to enhance the transfer rate

LCD CONTROLLER STN LCD DISPLAYS FEATURE

Supports 3 types of STN LCD panels: 4-bit dual scan, 4-bit single scan, 8-bit

single scan display type ,Supports monochrome mode, 4 gray levels, 16 gray

levels, 256 colors and 4096 colors for STN LCD

Supports multiple screen size Typical actual screen size: 640x480, 320x240,

160x160, and others,Maximum frame buffer size is 4 Mbytes.Maximum

virtual screen size in 256 color mode: 4096x1024, 2048x2048, 1024x4096 and

others

TFT(THIN FILM TRANSISTOR) COLOR DISPLAYS FEATURE

Supports 1, 2, 4 or 8 BPP (bit-per-pixel) palette color displays for color TFT

Supports 16, 24 BPP non-palette true-color displays for color TFT Supports

maximum 16M color TFT at 24 BPP mode ,LPC3600 Timing controller

embedded for LTS350Q1-PD1/2(SAMSUNG 3.5” Portrait

/256Kcolor/Reflective a-Si TFT LCD) LCC3600 Timing controller embedded

for LTS350Q1-PE1/2(SAMSUNG 3.5” Portrait / 256Kcolor/Transflective a-Si

TFT LCD)

Supports multiple screen size Typical actual screen size: 640x480, 320x240,

160x160, and others.Maximum frame buffer size is 4Mbytes.Maximum virtual

screen size in 64K color mode: 2048x1024, and others

UART

3-channel UART with DMA-based or interrupt based operation,Supports 5-

bit, 6-bit, 7-bit, or 8-bit serial data transmit/receive (Tx/Rx),Supports external

52

clocks for the UART operation (UEXTCLK),Programmable baud rate

Supports IrDA 1.0 Loopback mode for testing Each channel has internal 64-

byte Tx FIFO and 64-byte Rx FIFO.

A/D CONVERTER & TOUCH SCREEN INTERFACE

8-ch multiplexed ADC Max. 500KSPS and 10-bit Resolution Internal FET for direct

Touch screen interface

WATCHDOG TIMER

16-bit Watchdog Timer Interrupt request or system reset at time-out

IIC-BUS INTERFACE

1-ch Multi-Master IIC-Bus Serial, 8-bit oriented and bi-directional data

transfers can be made at up to 100 Kbit/s in Standard mode or up to 400 Kbit/s

in Fast mode.

IIS-BUS INTERFACE

1-ch IIS-bus for audio interface with DMA-based operation Serial, 8-/16-bit per

channel data transfers 128 Bytes (64-Byte + 64-Byte) FIFO for Tx/Rx Supports IIS

format and MSB-justified data format

AC97 AUDIO-CODEC INTERFACE

Support 16-bit samples,1-ch stereo PCM inputs/ 1-ch stereo PCM outputs 1-ch MIC

input

USB HOST

2-port USB Host,Complies with OHCI Rev. 1.0,Compatible with USB Specification

version 1.1

USB DEVICE

1-port USB Device,5 Endpoints for USB Device,Compatible with USB

Specification version 1.1

SD HOST INTERFACE

53

Normal, Interrupt and DMA data transfer mode (byte, half word, word

transfer),DMA burst4 access support (only word transfer),Compatible with SD

Memory Card Protocol version 1.0,Compatible with SDIO Card Protocol

version 1.0,64 Bytes FIFO for Tx/Rx,Compatible with Multimedia Card

Protocol version 2.11

SPI INTERFACE

Compatible with 2-ch Serial Peripheral Interface Protocol version 2.11,2x8

bits Shift register for Tx/Rx, DMA-based or interrupt-based operation

CAMERA INTERFACE

ITU-R BT 601/656 8-bit mode support,DZI (Digital Zoom In) capability

Programmable polarity of video sync signals Max. 4096 x 4096 pixels input

support (2048 x 2048 pixel input support for scaling) Image mirror and

rotation (X-axis mirror, Y-axis mirror, and 180° rotation) Camera output

format (RGB 16/24-bit and YCbCr 4:2:0/4:2:2 format)

Operating Voltage Range

Core: 1.20V for 300MHz ,1.30V for 400MHz,

Memory: 1.8V/2.5V/3.0V/3.3V,I/O: 3.3V

Operating Frequency

Fclk Up to 400MHz,Hclk Up to 136MHz,Pclk Up to 68MHz

Package

289-FBGA

ARM Register file & modes of operation

Registers: General Purpose registers hold either data or address and they are

identified with the letter r prefixed to the register number. All registers are of 32 bits.

ARM has 37 registers in total, all of which are 32-bits long.

1 dedicated program counter

1 dedicated current program status register

54

5 dedicated saved program status registers

30 general purpose registers

However these are arranged into several banks, with the accessible bank being

governed by the processor mode. Each mode can access a particular set of r0-r12

registers, a particular r13 (the stack pointer) and r14 (link register), r15 (the program

counter), cpsr (the current program status register) And privileged modes can also

access a particular spsr (saved program status register).

In user mode 16 data registers and 2 status registers are visible. Depending upon

context, register r13 and r14 can also be used as General Purpose Registers. In ARM

state the registers r0 to r13 are Orthogonal that means - any instruction which use r0

can as well be used with any other General Purpose Register (r1-r13).

The ARM processor has three registers assigned to a particular task or special

function: r13, r14 and r15. They are frequently given different labels to differentiate

them from the other registers.

Register r13 is traditionally used as the stack pointer (sp) and stores the head

of the stack in the current processor mode

Register r14 is called the link register (lr) and is where the core puts the return

address whenever it calls a subroutine.

Register r15 is the program counter ( pc ) and contains the address of the next

instruction to be fetched by the processor

The register file contains all the registers available to a programmer. Which registers

are visible to the programmer depend upon the current mode of the processor.

Current program status registers:

The ARM core uses the cpsr to monitor and control internal

operations. The cpsr is a dedicated 32-bit register and resides in the register file. The

following figure shows the generic program status register.

55

Fig 13.register formatFig 13.register format

Program Status RegisterProgram Status Register

The control bit field in fig 13. contains the processor mode, state, and interrupt mask bits (I,F). Reserved bits are allocated for the future versions purpose.

The N, Z, C and V are condition code flags will be changed as a result of arithmetic and logical operations in the processor

N: Negative. Z: Zero. C: Carry. V: Overflow

The I and F bits are the interrupt disable bits

The M0, M1, M2, M3 and M4 bits are the mode bits

Processor Modes: Processor modes determine which register are active, and access

rights to CPSR register itself. Each processor mode is either privileged or Non-

privileged. ARM has seven modes. These 7 modes are divided into two types.

Privileged: - Full read-write access to the CPSR. Under this we are having Abort,

Fast interrupt request, Interrupt request, Supervisor, System and Undefined

Abort (10111):

When there is a failed attempt to access memory

Fast interrupt Request (FIQ (10001)) & interrupt request (10010):

56

Correspond to interrupt levels available on ARM

Supervisor mode (10011):

State after reset and generally the mode in which OS kernel executes

System mode (11111):

Special version of user mode that allows full read-write access of CPSR

Undefined (11011):

When processor encounters an undefined instruction

Non-privileged:- Only read access to the control filed of CPSR but read-write

access to the condition flags.

User (10000): User mode is user for programs and applications. And this the

normal mode

Banked Registers:

Register file contains in all 37 registers. 20 registers are hidden from program at

different times. These registers are called banked registers. Banked registers are

available only when the processor is in a particular mode. Processor modes (other

than system mode) have a set of associated banked registers that are subset of 16

register

57

SPSR:SPSR:

Each privileged mode (except system mode) has associated with it a Save Program

Status Register, or SPSR. This SPSR is used to save the state of CPSR (Current

program status Register) when the privileged mode is entered in order that the user

state can be fully restored when the user processor is resumed

Mode Changing:

Mode changes by writing directly to CPSR or by hardware when the processor

responds to exception or interrupt.

To return to user mode a special return instruction is used that instructs the core to

restore the original CPSR and banked registers.

58

Register Bank

Indicates that the normal register used by User or System mode has been replaced by an alternative register specific to the exception mode

ARM Instruction Set:

In this chapter we are going to discuss about the most commonly used

Instruction Set of ARM. Different ARM architectures revisions support different

instructions. However new revisions usually add instructions and remain backwardly

compatible. The following shows the type of instructions that ARM support.

I. Data Processing Instructions

II. Branch Instructions

III. Load-store Instructions

IV. Software Interrupt Instruction

V. Program Status Register Instructions

I. Data Processing Instructions:-

The data processing instructions manipulate data within registers. Most data

processing instructions can process one of their operands using the barrel shifter. If we

use the S suffix on a data processing instruction, then it updates the flags in the cpsr.

Move and logical operations update the carry flag C, negative flag N, and Zero flag Z.

The carry flag is set from the result of the barrel shift as the last bit shifted out. The N

flag is set to bit 31 of the result. The Z flag is set if the result is zero. The following

instructions are Data processing instructions.

i). Move instructions: This instruction is used to move the content of one register to

another register. The below instructions are the Move instructions

MOV: move a 32-bit value into a register Rd=RS

MOVN: move the NOT of the 32 bit value into a register Rd= ~RS

ii). Barrel Shifter :- A unique and powerful feature of ARM processor is ability to

shift the 32-bit binary pattern in one of the source registers left or right by a specific

number of positions before it enters the ALU. This is done by using the Barrel shifter.

This preprocessing or shift occurs within the cycle time of the instruction. The five

different shift operations that we can use within the barrel shifter given below.

LSL: logical shift left

LSR: logical shift right

59

ASR: arithmetic right shift

ROR: rotate right

RRX: rotate right extended

iii. Arithmetic Instructions: The arithmetic instructions implement and subtraction

of 32-bit signed and unsigned values. Some of the instructions of Arithmetic

instructions are given below.

ADD: add two 32-bit values.

ADC: add two 32-bit values and carry

SUB: subtract two 32-bit values

SBC: subtract with carry of two 32-bit values

RSB: reverse subtract of two 32-bit values

RSC: reverse subtract with carry of two 32-bit values

iv. Logical Instructions: Performs the logical operations on two source registers

AND: logical bitwise AND of two 32-bit values

ORR: logical bitwise OR of two 32-bit values

EOR: logical exclusive OR of two 32-bit values.

BIC: Logical bit clear (AND NOT)

v. Comparison Instructions: The comparison instructions are used to compare or

test a register with a 32 bit value. They update the cpsr flag bits (N, Z, C, and V)

according to the result, but do not affect other registers. After the bits have been set,

the information can then be used to change program flow by using conditional

execution. We do not need to apply the S suffix for comparison instructions to update

the flag. The following instructions are belong Comparison instructions

CMP (compare) : flags set as a result of R1-R2

CMN (compare negated) : flags set as a result of R1+R2

TST (test for equality of two 32-bit values) : flags set as a result of R1&R2

TEQ (test for equality of two 32-bit values) : flags set as a result of R1^R2

vi. Multiply Instructions: The multiply instructions multiply the content of a pair of

registers and, depending upon the instruction, accumulate the results in with another

register. The long multiplies accumulate onto a pair of registers representing a 64 bit

value. The final result is placed in a destination register or a pair of registers.

MUL: multiply

MLA: multiply and accumulate

60

Long Multiply Instructions: (Produce 64 bit values, result will be placed in two 32 bit

values)

SMLAL: signed multiply accumulate long

SMULL: signed multiply accumulate

UMLAL: unsigned multiply accumulate long

UMULL: unsigned multiply long

II. Branch Instructions: - A branch instruction changes the flow of execution or is

used to call a routine. This type of instruction allows programs to have subroutines, if-

then-else structures, and loops. The change of execution flow forces the program

counter pc to point to new address. The below shown instructions are Branch

instructions.

B: branch

BL: branch with link

BX: branch exchange

BLX: branch exchange with link

III. Load-store Instructions: - Load-store instructions transfer data between memory

and processor registers.

There are three types of load-store instructions:

i. single register transferring

ii. Multiple register transfer

iii. Swap

Single register transferring: - These instructions are used for moving a single data

item in and out of a register. The data types supported are signed and unsigned words

(32-bit), half-words (16-bit), and bytes. The following instructions are various load-

store single-register transfer instructions.

LDR: load word into a register

STR: save byte or word from a register

LDRB: load byte into a register

STRB: save byte from a register

LDRH: load half-word into a register

61

STRH: save half-word into a register

LDRSB: load signed byte into a register

LDRSH: load signed half-word into a register

Multiple register transfer: - Load-store multiple instructions can transfer multiple

registers between memory and the processor in a single instruction. The transfer

occurs from a base address register Rn pointing into memory. Multiple-register

transfer instructions are more efficient from single-register transfers for moving

blocks of data around memory and saving and restoring context and stacks. If an

interrupt has been raised, then it has no effect until the load-store multiple instruction

is complete.

LDM: load multiple registers

STM: save multiple registers

Swap: - The swap instruction is a special case of a load-store instruction. It swaps the

contents of memory with the contents of a register. This instruction is an atomic

operation- it reads and writes a location in the same bus operation, preventing any

other instruction from reading or writing to that location until it completes.

IV. Software Interrupt Instruction: - A software interrupt instruction (SWI) causes a

software interrupt exception, which provides a mechanism for applications to call

operating system routines. The following instruction comes under software interrupt

instruction.

SWI: software interrupt

V. Program Status Register Instructions: - The ARM instruction set provides two

instructions to directly control a program status (psr).

MRS: This instruction transfers the contents of either the cpsr or spsr into a register

MSR: This instruction transfers the content of a register into the cpsr or spsr

Together the above two instructions are used to read and write the cpsr or spsr

ARM9 is an ARM architecture 32-bit RISC CPU family. With this design

62

generation, ARM moved from a von Neumann architecture (Princeton architecture) to

a Harvard architecture with separate instruction and data busses (and caches),

significantly increasing its potential speed. Most silicon chips integrating these cores

will package them as modified Harvard architecture chips, combining the two address

busses on the other side of separated CPU caches and tightly coupled memories.

Differences from ARM7 coresDecreased heat production and lower

overheating risk,Clock frequency improvements. Shifting from a three stage pipeline

to a five stage one lets the clock speed be approximately doubled, on the same silicon

fabrication process.Cycle count improvements. Many unmodified ARM7 binaries

were measured as taking about 30% fewer cycles to execute on ARM9 cores. Key

improvements include Faster loads and stores; many instructions now cost just one

cycle. This is helped by both the modified Harvard architecture (reducing bus and

cache contention) and the new pipeline stages.Exposing pipeline interlocks, enabling

compiler optimizations to reduce blockage between stages.

Additionally, some ARM9 cores incorporate "Enhanced DSP" instructions,

such as a multiply-accumulate, to support more efficient implementations of digital

signal processing algorithms.Switching to Harvard architecture entailed a non-unified

cache, so that instruction fetches do not evict data (and vice versa). ARM9 cores have

separate data and address bus signals, which chip designers use in various ways. In

most cases they connect at least part of the address space in von Neumann style, used

for both instructions and data, usually to an AHB interconnect connecting to a DRAM

interface and an External Bus Interface usable with NOR flash memory.

63

4.11)Mini2440 Development Board:

Figure 14: Mini2440 Development Board

Mini2440 Development Board Hardware Resources Features:

CPU Processor

Samsung S3C2440A, frequency 400 MHz, the highest 533 MHz

SDRAM Memory

On-board 64MB SDRAM,32-bit data bus,SDRAM clock frequency up to 100

MHz

FLASH Memory

On-board 64 MB NAND flash, Power-down non-volatile,On-board 2 MB

NOR flash, Power-down non-volatile, BIOS has been installed,LCD Display

On-board integrated 4-wire resistive touch screen interface, you can directly

connect 4-wire resistive touch screen Support for black and white, 4 gray-

scale, 16 gray-scale, 256-color, 4096-color STN LCD screen size from 3.5; to

64

12.1;, 1024x768 pixels screen resolution can be achieved ,Support for black

and white, 4 gray-scale, 16 gray-scale, 256-color, 64K-color, True Color TFT

LCD screen size from 3.5; to 12.1;, 1024x768 pixels screen resolution can be

achieved,Standard configuration for the NEC 256K-color 240x320/3.5; TFT

True Color LCD,screen with touchscreen.,Leads to a 12 V power supply on-

board interface, for the large-size TFT LCD 12 V,CCFL backlight module

(inverting) power supply

Interfaces and Resources

1 100 Mbps Fast Ethernet RJ-45 interface (used network chips DM9000)

,3 Serial ports, USB host,1 USB slave (B-type interface),1 SD card storage

interface,1 channel stereo audio output interface, all the way microphone

interface,1 2.0mm pitch 10-pin JTAG interface,4 User LEDs,6 User buttons

(with lead blocks),1 buzzer PWM control,1 adjustable resistor, analog-to-

digital converter for A/D test,1 I2C-bus AT24C08 chip for I2C-bus test,1 2.0

mm pitch 20-pin camera interface,On-board real-time clock battery,Power

interface (5 V), with power switch and indicator light,System Clock Source,12

MHz passive crystal,Real-Time Clock,Internal real-time clock (with lithium

battery back-up)

Operating System Support

Linux 2.6.29,Windows CE .NET 5.0

Interfaces and Jumpers Layout :

Jumper Description: There is only one development of on-board jumper J2, it is

used to select the input panel LCD drive voltage, in the standard configuration, the

access for NEC 3.5$ LCD, voltage selection for 5 V.

Interfaces Layout: Mini2440 interface layout is shown below it in a very compact

area of 100 mm x 100 mm delicate arrangement of open made from a variety of

commonly used interface, and also leads to the need for development and testing of

the surplus of the I/O ports and bus interfaces.

CHAPTER 5

65

TEST RESULTS

5.1) Objective

The main objective of this project is to broadcast the data to all

mobile devices using Bluetooth, which are in communication range. By default

mobile devices have a obex profile. In order to transfer the data the to all mobiles the

Bluetooth MAC address was known by open obex library functions , and the sockets

are created to send objects to mobiles. Among so many mobile devices the

broadcasting system sends the data to one by one devices in such a way it can transfer

data to all devices .After broadcasting of data is completed ,it display the time

taken to transfer data to that mobile devices along with MAC address and name of the

mobile ,also it shows which mobile rejected or not accept data with the help of obex

library functions.

5.2) Test Setup

Fig 15.test setup

66

a

d

e

b

c

a) pc or laptop is used control the broadcasting system it displays the all the results of the broadcasting system.

b)RS 232 cable is required for serial communication of Arm from pc to load the operating system in arm.

c)arm development board is used to broadcast the data loaded in processor and supports Bluetooth related operations .

d)Bluetooth dongle connected to usb host of broadcasting system(arm) is used to broadcast data to mobiles.

e) Bluetooth dongle connected to usb host of PC to update the data in broadcasting system .

5.3)Procedure:

1) The rs232 serial communication cable is connected from the pc to arm development board, and Bluetooth 2.0 version dongle connected to the usb host of the Arm board.

2)verified the switch of the development board in nor mode,and provided the power supply to the pc and arm development board.

3)The source code is executed on the pc in linux operating system and displayed maximum file size limit used in programme as shown in below. we used the abc.jpg image for broadcasting, contains interview related information.

Fig 16.initial mode

4)two mobiles karboon and lephone is used for test purpose and Bluetooth in that mobiles must be switched on.

5)after 30 seconds it started to search for any mobiles in that range.

67

Fig 17.inquiry scan

6) It displayed number of mobiles in that communication range, as shown below.

Fig 18.search result

7) It also displayed the channel number of opp(object push profile) service with mac address and name of mobile devices.I

herehere

fig 19.mobile information

68

8)before sending the data, we have to enter the pin number “1111” on each mobile, which is written in source code .

Karbon mobile with lephone mobile with

Mac address 69:38:21:68:66:81 Mac address 07:92:25:16:48:21

Fig 20.mobiles

When the request from broadcasting system is accepted the data is transferred

to mobiles and it displays the time taken to transfer a file to each mobile along with

MAC address and name of mobile as shown below.

69

Fig 21 broadcasting time

The broadcasted image which contains the interview schedule .

abc.jpg on karbonn abc.jpg on lephone

fig 22 recieved image on mobile

70

Immediately after sending the data, sockets are closed. Again it searched for new mobiles after a one minute time ,and it displays all the mobiles in that range and repeats the broadcasting process.

Fig 23 retransmit.

71

5.4) Observation: It is observed that each mobile had opp(object push profile),but it does not

presented on same channel for all mobiles . For karbonn mobile the object push

profile is presented on the channel number 4 and for the lephone mobile the the

object push profile is presented on channel one. It is observed that datarate of

multicast transfer is depends on the Bluetooth technology in mobiles not along with

the file size. The data transfer to 2 mobiles with file size of 100kb has taken five

seconds for karbonn mobile and 19 seconds for lephone mobile.

5.5) Result:

The broadcasting system using Bluetooth is implemented and tested

successfully for two mobiles(karbonn ,lephone) .The Bluetooth dongle we used for

test is class 2 type dongle which supports up to 10m range,but with class 1 bluetooth

dongle it can send data up to 100m range.

72

CHAPTER 6

CONCLUSION& FUTURE SCOPE

The project “Implementation of Broadcasting System Using Bluetooth” has

been successfully designed and tested. It uses BlueZ protocol stack and OpenOBEX

function library based on ARM-Linux with ARM hardware platform. The information

broadcast and update function is achieved based on Bluetooth 2.0 protocol. The focus

is on information multicast. It is low cost, high reliability, real-time and can be

flexibly extended. It also has good portability and interactive features. The program

can be applied to variety municipal and public place propaganda system combining

with multimedia technologies. It can also be used form publish of commercial

advertisements, private organizations for internal communications. In future we can

increase the communication range of Bluetooth by antenna in Bluetooth dongle.

73

REFERENCES

[1] Khaja Kamaluddin1, Masood Shareef Arif2, Imran Khan3,”GPS based Bluetooth

Broadcasting – Long Range Solution”, International Journal of Computer & communication

Technology Volume-2 Issue-VIII, 2011.

[2] Idwan, S.Alramouni, S., Al-Adhaileh, M. and Al-Khasawneh, A. (2008) ‘Enhancing

mobile advertising via Bluetooth technology’, Int. J. Mobile Communications, Vol. 6, No. 5,

pp.587–597.

[3] kyunghun jang,” Reliable delivery of broadcast packet in Bluetooth”, Vehicular

Technology Conference, 2001. VTC 2001 Spring. IEEE VTS 53rd, Vol. 6.

[4] W. Richard Stevens, Stephen A. Rago” Advanced Programming in the UNIX”, Second

Edition, Addison Wesley Professional, 2005.

[5] http://www.arm.com/community/software-enablement/linux.php

APPENDICES

74

Appendix A- Software setup

Appendix B- ARM porting

Appendix C-Algorithm

Appendix D- Flow chart

Appendix E- Source Code

Appendix A- SOFTWARE SETUP

1.1Select operating system:

We choose linux as the operating system of the embedded system developing platform.

LINUX a 32-bit, open and tailored embedded real-time operating system. It has the virtue of

modularization, scalability, strong

communication ability and good real-time, also can support a wide range of CPU. Linux is

widely used in the development of various embedded intelligent devices, such as industrial

control, information appliance, mobile communication, automotive electronics and Personal

electronic consumer goods.

1.2 Linux features:

Kernel Version - Linux 2.6.38(or latest)

Boot Loader - U-boot-1.6.1: open source, can be configured as Nand booting or SD booting

- Superboot: developed by FriendlyARM, not open sourced. File Systems

- YAFFS2: recommended

- UBIFS: recommended for MLC nand Flash.

- CRAMFS

75

- EXT2/3

- FAT32

- NFS

Drivers (all open source)

- Driver for 4 serial ports

- DM9000 driver

- Audio driver (WM9714)

- RTC driver

- Drivers for 4 User LEDs

- USB host driver

- LCD driver (it supports 3.5-inch, 4.3-inch, 7-inch, 8-inch, LCD2VGA1024x768, LCD2VGA800x600, LCD2VGA640x480 and EZVGA800x600)

- 4-wire touch screen driver and 1-wire precise touch driver

- USB camera driver

- Drivers for USB mouse, keyboard, flash drive and portable hard disk

- SD card driver, up to 32 GB

- I2C driver

- ADC driver

- LCD backlight driver

- Watchdog driver (watchdog reset is cold reset)

- Multimedia drivers(including JPEG, FIMC, MFC, 2D/3D Accelerator, TVENC and TVSCALER)

- CMOS camera driver

76

- Back light adjustor. This allows users to adjust the board’s backlight up to 127 levels

and experience a gradually dim effect when turning it down.

1.3 CREATING THE RAW KERNAL:

The main work that utilizing Linux to carry on the development of embedded operating

system is to customize the operating system. That is, we need to customize corresponding .

The resources of embedded system are limited, so we should minimize the size of the kernel

under the terms of meeting the function demand and guaranteeing its stability in order to

save resources

Fig:1 Creating kernel processor

77

Flow chart of the kernel compilation:

.

1. First we need to take the kernel of the version which suits to our arm processor.

arm-elf-tools-20030314.sh

uClinux-dist-20040408.tar

2. copy the compressed file”arm-elf-linux-gcc-4.3.2”as our uniform cross

compiler .the execute the following commands:

#d:\temp

78

#tar zxvf arm-linux-gcc-4.3.2.tgz –c/

This command will install arm-linux-gcc in the location of “use/local/arm/4.3.2”.

2. Then run the command to add the compiler’s path to system variable:

#gedit/root/.bashrc

This is to edit the “/root/.bashrc” file .

then “export PATH=$PATH:/usr/local/arm/4.3.2/bin” in the opened file and save and exit the

file.

79

3. By giving the command “make config”

Provides a command-line interface where you are asked about each option one byone.

If a .config configuration file is already present, it uses that file to set the

values of the options .

3.by giving this command “make menuconfig”

Displays a curses-based terminal configuration menu. If a .config file is present, it

uses it to set default values, as with make config.

80

4. Giving the command “make xconfig”

Displays a Tk-based X Window configuration menu. If a .config file is present, it uses

it to set default values, as with make config and make menuconfig.

Any of these can be used to configure the kernel. They all generate a .config file in

the root directory of the kernel sources. (This is the file that contains the full details of

the options you choose.) Few developers actually use the make config command to

configure the kernel. Instead, most use make menuconfig to create an initial

configuration or to tweak an existing one.

You can also use make xconfig. Keep in mind, however, that make xconfig may have

some broken menus in some architecture, as is the case for the PowerPC, for instance.

To view the kernel configuration menu, type the appropriate command at the

command line with the proper parameters. For example, to cross compile the Linux

kernel for use on an embedded ARM system, you might use the following command

line .

81

5. The last step by giving command “make” we can able to generate the zimage file of the

linux kernel in the .elf file format.

82

We choose suitable BSP (Board Support Package)firstly while customizing the

platform. In this system, we choose " SAMSUNG SMDK2410: ARMV4I " which is

the support to S3C2410 processor .Then we carry on the platform configuration

according to the hardware platform and the use of the system, and add the essential

characteristics. For example, the system uses C to develop the application program, so

it is necessary to add the MFC features. In addition, we need to add the support to

USB Device and serial port, as well as essential characteristics such as USB

keyboard and mouse, Udisk, SD/MMC Card, DM9000 Driver, etc. After all modules

are added, two binary image files nk.bin and nk.nb0 of linux can get through

compiling. Connect the PC and hardware platform with the network cable, download

zimage the hardware platform. Then we compile the start-up configuration file

boot.ini of linux after download.

The stream interface driver is mutual with application program through the file system

API provided by the system. The system completes the management work such as

loading and unloading through the equipment manager. The stream interface driver

communicates with the under stratum CMOS device through calling the interface

function . The application program calls the stream

83

interface function through the API provided by file system, and then the stream

interface driver calls the native driver or communicates with the system kernel

peripheral equipment through the equipment manager, drives the relevant hardware

directly to execute action in the end.

LCD DRIVERS:

frame buffer is the device for the user process to write directly to screen in embedded

linux.In linux frame buffer is an interface for the display device .it describes some displsy

devices asa buffer and allow applications to access the graphics device through its defined

interface without care the specific hardware details.

In linux frame buffer equipment can be see as a complete subsystems, generally consisted of

fbmern.c file and xxxfb.c on the one hand it provides application with some API which

perform by fbmern.c file such as read write ,ioctl,.on the other hand it provides the

hardware operation with some interfaces which should be sateen to meet the LCD

controller hardware needs.in this s3c2400, LCD controller is integrated into the chip as

aindpendent unit relatively , so it’s a platform device .

1.4 CROSS COMPILATION:

Compilation in general is split into roughly 5 stages: Preprocessing, Parsing, Translation,

Assembling, and Linking:

84

PREPROCESSING:

The first stage of the GNU Compiler converts your input file into pre-processed

output. Preprocessing a file converts all pre-processing statements (such as #include,

#define and #ifdef) into true C code. The input filename must have the extension .c to

signify C source code (in other words, the filename must end in .c, such as in file.c).

You can stop the GNUCompiler at this stage by supplying -E as the stage option. If

you specify -E, the output filename must have the extension .i.

COMPILING:

The second stage of the compiler converts preprocessed input into assembly language

output. This is where the bulk of the work in compiling a C program is done. You can

start the compiler at this stage by specifying an input filename with the .i extension.

You can also stop the compiler at this stage by specifying -S, in which case your

output filename must end in .s.

In practice, you almost never want to start the GNU Compiler at this stage: you would

normally start at the preprocessing stage by specifying a .c file as input. There are

times, however, you want to stop at this stage, usually to check the quality of the code

produced by the compiler. There is a plethora of options to control exactly how the

compiler converts your C source code into assembly language (and, from there, into

an object file or executable). Some of these are listed later in this document. The most

useful are the debugging option -g and the optimisation options, such as -O2.

85

ASSEMBLING:

The third stage of the compiler is to convert the assembly language code into re

locatable binary object output. The GNU Compiler actually calls the GNU Assembler,

arm-elf-as, to do the real work of assembly. For this reason, there is almost no reason

to start the GNU Compiler from this stage (by specifying a file ending in .s).

On the other hand, the relocatable binary object that is generated by this stage is often

desirable. For example, you can create a number of object files from C source code

(by calling the compiler multiple times) which can then be linked together to form one

executable.

You can make the compiler stop at this stage by specifying -c as the stage option, in

which case your output filename must have the extension .o.

LINKING:

The fourth and final stage of the compiler is to link the relocatable object file into an

executable output file. The GNU Compiler uses the GNU Linker, arm-elf-ld, to do

the real work. You can start the compiler at this stage by specifying an input filename

with the extension .o. You can make the compiler stop at this stage (and not earlier)

by not supplying a state option, in which case the output filename must end in .elf.

86

Appendix B-ARM PORTING

Stage 1: Porting Linux

Following are the main steps for porting Linux:

Download the patches of Linux Kernel for supporting ARM processor.

Prepare the ARM based tool chain for compilation of Linux source code.

Choose and Configure boot loader as per target board.

Compile the boot loader.

Configure Linux kernel as per target platform (this may require developing some

additional device drivers or customization of the existing device drivers for the

reference design board) .

Compile the Linux kernel source

Burn compressed Linux image on the target platform

Update Board specific components such as Codec, Camera, Audio, Wifi, Power

Management, Bluetooth etc.

Burn system image on Target platform.

System C library:- BSD-derived implementation of the standard C system library (libc), tuned

for embedded Linux-based devices

87

Media Libraries:- Based on PacketVideo’s OpenCORE; the libraries support playback and

recording of many popular audio and video formats, as well as static image files, including

MPEG4, H.264, MP3, AAC, AMR, JPG.

Surface Manager:- Manages access to the display subsystem and seamlessly composites 2D

and 3D graphic layers from multiple applications

SQLite:- Powerful and lightweight relational database engine available to all applications.

Snapshot of the downloaded directory are given as below. ‘mydroid’ is the top level

directory in which we have downloaded and installed linux.

After successful compilation , burn the linux images (USERDATA.IMG) and Linux

kernel images (zIMAGE) at the respective offset in NAND Flash and start booting the

ARM Handheld PDK.

Produced more than we produced a core file: zImage, and file system, following our

development board comes with supervivi them programmed into the development

board and run.

Installing the USB driver and serial terminal settings, and USB download programming

instructions, see mini2440 user manual. First, the development board of the S2 switch to

NOR time, boot into BIOS mode (that is, supervivi mode), 128M mini2440 the BIOS version

of the output shown in Figure:

88

In this menu:

The first type “X” to format the system and the select “v” to start the download boot loader

you can choose vboot.bin, you can choose supervivi-128mb.

89

now press the key k to install the linux kernel of zimage.

90

Installing Root File System:

In the BIOS main menu select item [y] to start downloading a yaffs root file system

image

91

Programming is complete, you can use the "b" command to start the system, can

also switch S2 Nand Flash side, reset your system.When you first start the system, there will

be correction interface, followed by point "ten" font in the middle position,until the correct

contact, wait a moment, you can see the "big clock" interface.

Appendix-C ALGORITHM

92

The working of the project can be explained in the following steps:

1. Initially switch On the power supply for boards ARM9, and PC.

2. Wait for 30Sec to update file.

3. Search for Nearby devices for mobiles which have Bluetooth.

4. Query each device for its display name.

5. Search for object push profile (OPP) service channel Number.

6. Using Channel number connect the device to send data.

7. Send the data on channel selected using command “OBEX_PUSH_SERVICE.

8. Wait until data send

9. Disconnect the device

10.goto step 3.

Appendix D-Flow Chart

93

START

Appendix E-Source Code

94

Wait for 30Sec to update file

Search for Nearby devices (Device Inquiry)

Query each device for its display name

Search for object push profile (OPP) service channel Number

Using Channel number connect the device to send data

Choose device with user specified name

Send the data on channel selected using command “OBEX_PUSH_SERVICE””

Disconnect the device

Wait until data send

#include <stdio.h>#include <unistd.h>#include <sys/socket.h>#include <bluetooth/bluetooth.h>#include <bluetooth/rfcomm.h>

#include "obex_io.h"

int main(int argc, char **argv){ struct sockaddr_rc addr = { 0 }; struct sockaddr_rc loc_addr = { 0 }; int s, status; char server_bdaddr[18] = "00:15:83:B3:CF:FA"; char source_bdaddr[18] = "00:15:83:15:A3:10";

int file_size; char file_name[] = "abc.jpg"; unsigned char *ptr_buf; int i;

if(argc == 1) { printf("Usage: <program-name> <source bluetooth address> <server bluetooth address> <file name>\n"); printf("Sending file \"%s\" from %s to %s\n", file_name, source_bdaddr, server_bdaddr); } else if(argc == 2) { strcpy(source_bdaddr, argv[1]); }else if(argc == 3) { strcpy(source_bdaddr, argv[1]); strcpy(server_bdaddr, argv[2]); }else if(argc == 4) { strcpy(source_bdaddr, argv[1]); strcpy(server_bdaddr, argv[2]); strcpy(file_name, argv[3]); }

ptr_buf = easy_readfile(file_name, &file_size); printf("client, file size: %d\n", file_size); /* printf("File Content: "); for(i=0; i<file_size; i++) { printf("%c", ptr_buf[i]); } */

// allocate a socket s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);

95

// bind socket to port 1 of the first available bluetooth adapter

loc_addr.rc_family = AF_BLUETOOTH;//loc_addr.rc_bdaddr = *BDADDR_ANY;str2ba(source_bdaddr, &loc_addr.rc_bdaddr);loc_addr.rc_channel = 0;bind(s, (struct sockaddr *)&loc_addr, sizeof(loc_addr));

// set the connection parameters (who to connect to) addr.rc_family = AF_BLUETOOTH; addr.rc_channel = 20; str2ba(server_bdaddr, &addr.rc_bdaddr );

// connect to server status = connect(s, (struct sockaddr *)&addr, sizeof(addr));

// send a message if( 0 == status ) { //status = send(s, "hello!", 6, 0); status = send(s, ptr_buf, file_size, 0); printf("Client, Number of bytes transmitted: %d\n", status); }

if( status < 0 ) perror("uh oh");

close(s); return 0;}

// broadcast code

#ifdef HAVE_CONFIG_H

96

#include <config.h>#endif

#include <stdio.h>#include <unistd.h>#include <stdlib.h>#include <string.h>#include <errno.h>

#include <sys/socket.h>#include <arpa/inet.h>#include <netdb.h>#include <netinet/in.h>

#include <bluetooth/bluetooth.h>#include <bluetooth/rfcomm.h>

#include <openobex/obex.h>

#include "obex_test.h"#include "obex_test_client.h"#include "obex_search_service.h"

#define TRUE 1#define FALSE 0

#define BT_CHANNEL 4#define FILE_PATH "/var/lib/bluetooth/00:15:83:B3:CF:FA/pincodes"

//// Called by the obex-layer when some event occurs.//

int link_error = 0;

void obex_event(obex_t *handle, obex_object_t *object, int mode, int event, int obex_cmd, int obex_rsp){

switch (event) {case OBEX_EV_PROGRESS:

printf("Made some progress...: OBEX_EV_PROGRESS\n");break;

case OBEX_EV_ABORT:printf("OBEX_EV_ABORT......called\n");printf("Request aborted!\n");break;

case OBEX_EV_REQDONE:printf("OBEX_EV_REQDONE......called\n");client_done(handle, object, obex_cmd, obex_rsp);break;

case OBEX_EV_REQHINT:

97

printf("OBEX_EV_REQHINT........called\n");/* Accept any command. Not rellay good, but this is

a test-program :) */OBEX_ObjectSetRsp(object, OBEX_RSP_CONTINUE,

OBEX_RSP_SUCCESS);break;

case OBEX_EV_LINKERR:link_error = 1;printf("OBEX_EV_LINKERR........called\n");OBEX_TransportDisconnect(handle);printf("Link broken!\n");break;

case OBEX_EV_STREAMEMPTY:printf("OBEX_EV_STREAMEMPTY........called\n");fillstream(handle, object);break;

default:printf("Unknown event %02x!\n", event);break;

}}

/* * Function get_peer_addr (name, peer) * * * */int get_peer_addr(char *name, struct sockaddr_in *peer) {

struct hostent *host;u_long inaddr;

/* Is the address in dotted decimal? */if ((inaddr = inet_addr(name)) != INADDR_NONE) {

memcpy((char *) &peer->sin_addr, (char *) &inaddr, sizeof(inaddr));

}else {

if ((host = gethostbyname(name)) == NULL) {printf( "Bad host name: ");exit(-1);

}memcpy((char *) &peer->sin_addr, host->h_addr,

host->h_length); }

return 0;}

int inet_connect(obex_t *handle){

struct sockaddr_in peer;

98

get_peer_addr("localhost", &peer);return OBEX_TransportConnect(handle, (struct sockaddr *)

&peer, sizeof(struct sockaddr_in));

}

int file_server(){#define MAX_FILE_SIZE 5*1024*1024

struct sockaddr_rc loc_addr = { 0 }, rem_addr = { 0 }; char buf[MAX_FILE_SIZE] = { 0 }; int s, client, bytes_read; unsigned int opt = sizeof(rem_addr); char listen_baddr[18] = "00:15:83:B3:CF:FA"; char *ptr_buf; int buf_size;

printf("buf size: %d\n", sizeof(buf)); // allocate socket s = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM);

// bind socket to port 1 of the first available bluetooth adapter loc_addr.rc_family = AF_BLUETOOTH; //loc_addr.rc_bdaddr = *BDADDR_ANY; str2ba(listen_baddr, &loc_addr.rc_bdaddr); loc_addr.rc_channel = 20;

bind(s, (struct sockaddr *)&loc_addr, sizeof(loc_addr));

// put socket into listening mode listen(s, 1);

while(1) {

// accept one connection opt = sizeof(rem_addr);

client = accept(s, (struct sockaddr *)&rem_addr, &opt);

ba2str( &rem_addr.rc_bdaddr, buf );fprintf(stderr, "accepted connection from %s\n",

buf);memset(buf, 0, sizeof(buf));

// read data from the clientptr_buf = buf;buf_size = sizeof(buf);

while(1){

bytes_read = recv(client, ptr_buf, buf_size, 0);

if(bytes_read <= 0)

99

break;ptr_buf += bytes_read;buf_size -= bytes_read;

}

bytes_read = ptr_buf - buf;

printf("Number of bytes received: %d\n", bytes_read);

if( bytes_read > 0 ) {int size_written;//printf("received [%s]\n", buf);size_written = safe_save_file("abc.jpg", buf,

bytes_read);printf("file stored successfully: %d/%d\n",

size_written, bytes_read);}

// close connectionclose(client);

} close(s); return 0;}

int main (int argc, char *argv[]){

char cmd[5];char srcstr_bdaddr[19] = "00:15:83:B3:CF:FA"; //source

bluetooth dongle address

int end = FALSE;obex_t *handle;

bdaddr_t bdaddr, src_bdaddr;

uint8_t channel = 0;

struct context global_context = {0,};

char *port;

btdevice_data_t *btdata;int num_rsp;int i;FILE *fp;char sbdaddr[19], tmpstr[19];int num_secs;

// str2ba(argv[1], &bdaddr);// channel = atoi(argv[2]);

100

if(fork() == 0){

file_server();exit(0);

}printf("update file for %d sec",num_sec);wait(30);

printf("search device”);

str2ba(srcstr_bdaddr, &src_bdaddr);while(1){

num_rsp = search_devices(&btdata);fp = fopen(FILE_PATH, "w+");for(i=0; i<num_rsp; i++){

ba2str(&(btdata[i].bdaddr), sbdaddr);fprintf(fp, "%s %d\n", sbdaddr, 1111);

}fclose(fp);

for(i=0; i<num_rsp; i++){

if(fork() == 0){

printf("Using Bluetooth RFCOMM transport\n");

if(! (handle = OBEX_Init(OBEX_TRANS_BLUETOOTH, obex_event, 0))) {

perror( "OBEX_Init failed");exit(0);

}

OBEX_SetUserData(handle, &global_context);

printf( "OBEX Interactive test client/server.\n");

/* First connect transport */if(BtOBEX_TransportConnect(handle,

&src_bdaddr, &(btdata[i].bdaddr), btdata[i].channel) < 0) {printf("Transport connect error!

(Bluetooth): %s\n", strerror(errno));return -1;

}

// Now send OBEX-connect.connect_client(handle);

101

// put_client(handle);num_secs = push_client(handle);ba2str(&btdata[i].bdaddr, tmpstr);if(!link_error)

printf("====> %4d seconds used for transferring file to %s (%s)\n", num_secs, tmpstr, btdata[i].name);

link_error = 0;disconnect_client(handle);exit(0);

}}free(btdata); // Memory allocated in the search

devicessleep(60);

}return 0;

}

102

103