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