1.

INTRODUCTION
1.1 Introduction
Many infrastructures and industries use computer-based systems to remotely control sensitive processes and physical functions which were previously controlled manually by operators. These systems, commonly known as Supervisory Control and Data Acquisition Systems, allow a physical system to collect data from sensors and control equipment located at remote sites. The communication protocols allow these devices to communicate with each other. Modbus is a kind of communication protocol which is promoted by Modicon Corporation. It is widely used in the industrial automation. In simple terms, it is a method used for transmitting information over serial lines between electronic devices. The device requesting the information is called the Modbus Master and the devices supplying information are called Modbus Slaves. Modbus is an open protocol, meaning that it's free for manufacturers to build into their equipment without having to pay royalties. It has become a standard communications protocol in industry, and is now the most commonly available means of connecting industrial electronic devices. The control devices or the measuring instruments of different manufacturers can be linked to an industry monitor network by using the Modbus protocol. The Modbus communication protocol is adopted in massive equipment as the communication standard. With the rapid development of embedded computer technology, embedded data acquisition monitoring systems also started using high performance embedded microprocessors as the core of the embedded data acquisition monitoring system applications, a Modbus protocol is designed and realized in this project.

1.2 Problem Statement

Keeping in view the development of embedded data acquisition and Monitoring systems, the realization of Modbus protocol is done in this project. The purpose of this work is to design and realize Modbus Protocol in embedded Linux environment to interact with Modbus devices. The work involves development of Modbus Master and slave protocols. The Modbus Master protocol is developed for ARM9 based
1

System and the Slave protocol for ARM7 based embedded system. The work also involves development of a Linux application to get the data from Modbus master to monitoring center. The Monitoring Centre is a computer system used to interact with the Master to initiate actions and acquire the data.

1.3 System Methodology

The overall structure of the embedded data acquisition system is presented in Figure 1.1. In this architecture, the Master System is the core and data from the Slave System is communicated to the Master System using the Modbus protocol. After the acquisition of data, the data transmission to the monitoring center through TCP/IP. is realized

Figure 1.1: Architecture of the System The work is presented into four parts. The phases of development are: i. ii. iii. iv. Transplantation of Linux into the Master that employs ARM9 processor. Implementation of Modbus protocol on the master. Implementation of Modbus protocol on the slave. Development of a Linux application for the Monitoring Centre to interact with the Master System.
2

1.3.1 Transplantation of Linux on the Master System

Services of an operating system are not used in small systems that use simple tasks. However, as the complexity of applications expands beyond simple tasks, the operating system becomes essential. Since embedded systems are becoming more complex hardware-wise, and more features are put into them, applications they run require Operating System in order to meet the system response requirements. In the Modbus protocol implementation, the Master system may also require to interact with several Modbus slaves to get the work done, even though in the present work it interacts with only a single slave. The complexity of the application goes beyond a simple task. Hence to meet the application requirements an embedded Linux OS is transplanted onto the master. This involves customization of the Linux kernel to suit the ARM platform since the master is based on the ARM9 processor. To have a usable Linux Operating System requires at least 4-8 Mega bytes of SDRAM, and at least 2Mega bytes of Flash and the Boot Time should be small. To meet these requirements ARM9 based S3C2440 microcontroller board is used as Master and the Modbus master protocol is implemented on it to communicate with the slave system to acquire data from it. The S3C2440 is a 16/32-bit RISC embedded microcontroller based on ARM920T core It is a low-power microcontroller.

1.3.2 Implementation of Modbus Protocol on the master

The MODBUS standard defines messaging protocol that provides "client/server" communications between devices connected on different types of buses or networks. It standardizes protocol on serial line to exchange MODBUS request between a master and one or several slaves. A master-slave type system has one node (the master node) that issues explicit commands to one of the "slave" nodes and process responses. Slave nodes will not transmit data, without a request from the master node. They do not communicate with other slaves. The MODBUS protocol implementation for master involves formation of request frames, which are sent to the slaves. There are different frames for different actions that the master requests. In the present work these request frames are developed in the source code, cross compiled and ported onto the master after the
3

embedded Linux transplantation. At the physical level, MODBUS uses RS 485 physical interface.

1.3.3 Implementation of Modbus Protocol on the Slave

In the Modbus protocol, the slaves respond by supplying the requested data to the master, or by taking the action requested. A request to an individual slave will prompt a reply from that slave back to the master. The Modbus protocol establishes the format for the master's query address, a function code defining the requested action and any data to be sent. The slave's response message is constructed using the Modbus protocol. It contains fields confirming the action taken and any data to be returned. If an error occurred in receipt of the message, or if the slave is unable to perform the requested action, the slave will construct an error message and send it as its response. The application for Modbus slave protocol is implemented on the slave system. This application is cross compiled using KEIL Integrated Development Environment and flashed onto the slave system.

1.3.4 Development of Application for Monitoring Centre

The present work also consists of a Monitoring centre which is a PC that runs Linux Operating System. A Monitoring centre is a computer system through which the user interacts with the Modbus Master and thereby with the slave system. It provides a user interface to let the user operate the Master and Slave systems. When the Modbus master acquires data from the slave the data is also sent to the monitoring centre. The monitoring centre can also initiate actions. These actions are performed through master. When the monitoring centre requests for any actions on the slave it sends that request to the master then the master interacts with the slave through Modbus protocol and accomplishes the task requested. In order to perform these actions, the monitoring centre interacts with the master system using socket programming. An application is developed to accomplish this on the Monitoring centre in Linux using gcc compiler. The application is native compiled and run on the monitoring centre to acquire the data and to do any action required.

1.4 Testing the Modbus Protocol

In the present work, the Modbus protocol implementation is shown by establishing the communication between the Master and slave systems. The operations performed in Modbus protocol implementation are categorized into different data types based on the type of operations that are carried out. The Modbus protocol supports data types like reading a single I/O line whose status can be read; read or write of a line whose status can be read or written, reading a register and read/write of a register. These all data types are realized in the implementation of this communication protocol. These data types correspond to the slave system, that the Master can read status of a single I/O line, write a single line, read a register of the slave, and write to the register of a slave which is located remotely. In the present work, the demonstration of the above mentioned data types is done as follows: Reading the single I/O line is demonstrated by reading a switch connected to the GPIO line of the slave. This type of operation is termed as Discrete Input which can only be read can not be written. Device connected to the slave whose status can be written and read is called as Coil. This is realized by connecting a Relay whose status is read and after knowing the status the GPIO line to which it is connected can be written. Similarly 8 or 16 bits of data read from the slave is termed as Input Register and 8 or 16 bits of data written or read is treated as Holding Register. These are implemented by reading ADC value and writing data on to the LEDs connected to slave respectively. To perform these operations on the remote slave, The Master system sends the request frames; the Slave performs the operation and sends a response frame back to the Master. Thus, the Modbus protocol between the ARM9 based Master system and ARM7 based Slave is tested

1.5 . Organization
Chapter 1 gives the introduction. Chapter 2 describes the Modbus protocol and its function codes. Chapter 3 discusses the hardware design of the System. Chapter 4 outlines the software of the complete system
5

Chapter 5 discusses Testing and Results. Chapter 6 discusses Conclusion and Future work.

2. LITERATURE REVIEW
2.1 Introduction to Modbus Protocol
The purpose of this chapter is to provide the necessary background required to understand the Modbus protocol implementation. Modbus is an application-layer protocol. It was published by Modicon in 1979 and is primarily used in industrial applications. The Modbus protocol follows a master/slave architecture where a master will request data from the slave. The master can also ask the slave to perform some action. The master initiates a process by sending a function code that represents the type of transaction to be performed. The transaction performed by the Modbus protocol defines the process a controller uses to request access to another device, how it will respond to requests from other devices. The basic Modbus Network is shown in the Figure 2.1. The Modbus protocol establishes a common format for the layout and contents of message fields. During communications on a Modbus network, the protocol determines how each controller will know its device address, recognize a message addressed to it, determine the kind of action to be taken, and extract any data or other information contained in the message. Controllers communicate using a master/slave technique where only one device, the master, can initiate transactions or queries. The other devices, slaves, respond by supplying the requested data to the master or by taking the action requested in the query as shown in the Figure 2.2. Typical master devices include host processors and programming panels. Typical slaves include programmable controllers and other embedded systems. The messages exchanged between the master and the slaves are called frames. There are two types of Modbus frames: Protocol Data Unit (PDU) and Application Data Unit (ADU). The PDU frames contain a function code followed by data. The function code represents the action to be performed and the data represents the information to be used for this action. ADU frames add a little more complexity with an additional address part. ADU frames also provide some error checking. Both the ADU and PDU frames follow Big-Endian encoding. Figure 2.3 illustrates the Modbus Frame.
7

Figure 2.1: Basic Modbus Network

Figure 2.2: Basic Modbus Transaction

Figure 2.3: Modbus Frame

8

Modbus transactions always perform a set of actions by reading or writing to a set of four data types. Table 2.1 describes the four data formats used by the Modbus application layer. Table 2.1: Modbus Data Types Primary Tables Discrete Input Coils Input Registers Holding Registers Object Type Single bit Single bit 16-bit word 16-bit word Type of Read-Only Read-Write Read-Only Read-Write

The Discrete Inputs represent a single bit (Boolean) which can only be read. In other words, the master can only perform a read action on the discrete inputs. The same holds for the Input Registers. The master can only read the slaves Input Registers. The difference between the Discrete Inputs and the Input Registers is that the Input Registers represent 16 bits while the Discrete Inputs are only a single bit. The Coils also represent a Boolean data type which can be read and written to by the master. The Holding Registers represent a 16 bit word that can be read and written to. The Modbus Transaction with the data types is illustrated in the Figure 2.4.

2.2 The Complete Modbus Transaction

As mentioned before, the type of action that the slave performs is defined by a function code. For example, if the master wants to read a certain Discrete Input, it will send a function code of 0x02 followed by the address of the desired Discrete Input. The slave will read the 0x02 and will know that the master wants a Discrete Input. The slave will retrieve the Discrete Input from the given address and reply back to the master. The complete Modbus Transaction is shown in the Figure 2.5.

2.3 Modbus Function Codes

There are three main types of function codes: Public, User Defined, and Reserved. Since the public function codes are validated, publicly documented, and have
9

available conformance tests, most Modbus devices implement them. Each of the public function codes is associated with a well-defined function. A brief overview of the public function codes is presented in Table 2.2.

Figure 2.4: Modbus Transaction with Data types

2.4. Function Codes Descripitons

2.4.1 01 (0x01) Read Coils This function code is used to read from 1 to 2000 contiguous status of coils in a remote device. The Request PDU specifies the starting address, ie the address of the first coil specified, and the number of coils. Coils are addressed starting at zero. Therefore coils 1-16 are addressed as 0-15.It is shown in the Table 2.3. The coils in the response message are packed as one coil per bit of the data field. Status is indicated as 1 = ON and 0 = OFF. The LSB of the first data byte contains the output addressed in the query. The other coils follow toward the high order end of this byte, and from low order to high order in subsequent bytes. The response PDU is shown in the Table 2.4.
10

Figure 2.5: Complete Modbus Transaction If the returned output quantity is not a multiple of eight, the remaining bits in the final data byte will be padded with zeros (toward the high order end of the byte). The Byte Count field specifies the quantity of complete bytes of data. Example for Read Coil is shown in the Table 2.5 is an example of a request to read discrete outputs 2038. The status of outputs 2720 is shown as the byte value CD hex, or binary 1100 1101. Output 27 is the MSB of this byte, and output 20 is the LSB. By convention, bits within a byte are shown with the MSB to the left, and the LSB to the right. Thus the outputs in the first byte are 27 through 20, from left to
11

right. The next byte has outputs 35 through 28, left to right. As the bits are transmitted serially, they flow from LSB to MSB: 20 . . . 27, 28 . . . 35, and so on. In the last data byte, the status of outputs 38-36 is shown as the byte value 05 hex, or binary 0000 0101. Output 38 is in the sixth bit position from the left, and output 36 is the LSB of this byte. The five remaining high order bits are zero filled, The Read coils state diagram is shown in the Figure 2.6. Table 2.2: Modbus Function codes
Function Codes Code 02 01 05 15 04 03 06 16 23 22 20 21 43 6 6 14 Sub code (hex) 02 01 05 0F 04 03 06 10 17 16 14 15 2B

Physical Discrete Inputs Bit access Internal Bits Or Physical Coils Physical Input Registers Data Access 16 bits access

Read Input Discrete Read Coils Write Single Coil Write Multiple Coils Read Input Register Read Multiple Registers Write Single Register Write Multiple Registers Read/Write Multiple Registers Mask Write Register Read File record Write File record Read Device Identification

Internal Registers Or Physical Output Registers

File record access Encapsulated Interface

Table 2.3: Read Coil Request PDU Function Code Starting Address Quantity of Coils 1 Byte 2 Bytes 2 Bytes 0x01 0x0000 to 0xFFFF 1 to 2000(0x7D0)

Table 2.4: Read Coil Response PDU Function Code 1 Byte 0x01 Byte Count 1 Byte N* Coil Status n Byte n = N or N+1 *N = Quantity of Outputs / 8, if the remainder is different of 0 N = N+1
12

Table 2.5: Read Coil PDU Example Request Field Name Function Starting Address Hi Starring Address Lo Quantity of Outputs Hi Quantity of Outputs Lo Response Field Name Function Byte Count Output status 27-20 Outputs status 35-28 Outputs status 38-36

(Hex) 01 00 13 00 13

(Hex) 01 03 CD 6B 05

2.4.2 02 (0x02) Read Discrete Inputs This function code is used to read from 1 to 2000 contiguous status of discrete inputs in a remote device. The Request PDU specifies the starting address, i.e. the address of the first input specified, and the number of inputs. Inputs are addressed starting at zero. Therefore inputs 1-16 are addressed as 0-15. The Read Discrete Input request PDU is shown in the Table 2.6. The discrete inputs in the response message are packed as one input per bit of the data field. Status is indicated as 1= ON; 0 = OFF. The LSB of the first data byte contains the input addressed in the query. The other inputs follow toward the high order end of this byte, and from low order to high order in subsequent bytes.
ENTRY MB Server receives mb_req_pdu

NO Function code supported YES NO 0x001<=Quantity of Outputs<=0x07D0

YES NO Starting Address == OK AND Starting Address + Quantity of Outputs == OK YES Request Processing

NO ReadDiscreteOutputs == OK YES MB Server sends mb_rsp

MB Server Sends mb_exception_rsp

EXIT

Figure 2.6: Read Coils state diagram

13

If the returned input quantity is not a multiple of eight, the remaining bits in the final data byte will be padded with zeros (toward the high order end of the byte). The Byte Count Field specifies the quantity of complete bytes of data. The Read Discrete Input response PDU is shown in the Table 2.7. Table 2.6: Read Discrete Input Request PDU Function Code Starting Address Quantity of Inputs 1 Byte 2 Bytes 2 Bytes 0x02 0x0000 to 0xFFFF 1 to 2000(0x7D0)

Table 2.7: Read Discrete Input Response PDU Function Code Byte Count Input Status 1 Byte 1 Byte N* x 1 Byte 0x02 N*

*N = Quantity of Inputs / 8 if the remainder is different of 0 N = N+1 Table 2.8 shows an example of a request to read discrete inputs 197 218.The status of discrete inputs 204197 is shown as the byte value AC hex, or binary 1010 1100. Input 204 is the MSB of this byte, and input 197 is the LSB. Table 2.8: Read Discrete Input PDU Example Request Field Name Function Starting Address Hi Starring Address Lo Quantity of Inputs Hi Quantity of Inputs Lo (Hex) 02 00 C4 00 16 Response Field Name Function Byte Count Inputs Status 204-197 Inputs Status 212-205 Inputs Status 218-213 (Hex) 02 03 AC DB 35

The status of discrete inputs 218213 is shown as the byte value 35 hex, or binary 0011 0101. Input 218 is in the third bit position from the left, and input 213 is the LSB, the Read Discrete Input state diagram is shown in the Figure 2.7.

14

ENTRY MB Server receives mb_req_pdu

NO Function code supported YES NO 0x0001<=Quantity of Inputs<=0x07D0 YES NO Starting Address == OK AND Starting Address + Quantity of Inputs == OK YES Request Processing

NO ReadDiscreteInputs == OK YES MB Server sends mb_rsp

MB Server Sends mb_exception_rsp

EXIT

Figure 2.7: Read Discrete Inputs state diagram

2.4.3 03 (0x03) Read Holding Registers This function code is used to read the contents of a contiguous block of holding registers in a remote device. The Request PDU specifies the starting register address and the number of registers. Registers are addressed starting at zero. Therefore registers 1-16 are addressed as 0-15. The Request PDU is shown in the Table 2.9. The register data in the response message are packed as two bytes per register, with the binary contents right justified within each byte. For each register, the first byte contains the high order bits and the second contains the low order bits. The Response PDU is shown in the Table 2.10. Table 2.9: Read Holding Register Request PDU Function Code Starting Address Quantity of Registers 1 Byte 2 Bytes 2 Bytes 0x03 0x0000 to 0xFFFF 1 to 125(0x7D)

15

Table 2.10: Read Holding Register Response PDU Function Code Byte Count Input Status *N = Quantity of Registers 1 Byte 1 Byte N* x 2 Bytes 0x03 2xN*

An example of a request to read registers 108 110 is shown in Table 2.11. Table 2.11: Read Holding Register PDU Example Request Field Name Function Starting Address Hi Starring Address Lo No. of Registers Hi No. of Registers Lo (Hex) 03 00 6B 00 03 Response Field Name Function Byte Count Register value Hi(108) Register value Lo(108) Register value Hi(109) Register value Lo(109) Register value Hi(110) Register value Lo(110) (Hex) 03 06 02 2B 00 00 00 64

The contents of register 108 are shown as the two byte values of 02 2B hex, or 555 decimal. The contents of registers 109110 are 00 00 and 00 64 hex, or 0 and 100 decimal, respectively. The Read Holding Register state diagram is shown in the Figure 2.8.
ENTRY MB Server receives mb_req_pdu

NO Function code supported YES NO 0x0001<=Quantity of Registers<=0x07D0 YES NO Starting Address == OK AND Starting Address + Quantity of Registers == OK YES Request Processing

NO Read Multiple Registers == OK YES MB Server sends mb_rsp

MB Server Sends mb_exception_rsp

EXIT

Figure 2.8: Read Holding Registers state diagram

16

2.4.4 04 (0x04) Read Input Registers This function code is used to read from 1 to approx. 125 contiguous input registers in a remote device. The request PDU for Read Input Registers is shown in the Table 2.12. The Request PDU specifies the starting register address and the number of registers. Registers are addressed starting at zero. Therefore input registers 1-16 are addressed as 0-15. The response PDU is shown in the Table 2.13. The register data in the response message are packed as two bytes per register, with the binary contents right justified within each byte. For each register, the first byte contains the high order bits and the second contains the low order bits. The state diagram is shown in the Figure 2.9. Table 2.12: Read Input Register Request PDU Function Code Starting Address Quantity of Registers 1 Byte 2 Bytes 2 Bytes 0x04 0x0000 to 0xFFFF 0x0001 to 0x007D

Table 2.13: Read Input Register Response PDU Function Code 1 Byte Byte Count 1 Byte Input Registers N* x 2 Bytes *N = Quantity of Input Registers 0x04 2xN*

The example for the Read Input Register PDU is given in the Table 2.14.This is an example for a request to read input register 9. The contents of input register 9 are shown as the two byte values of 00 0A hex or 10 decimal. Table 2.14: Read Input Register PDU Example Request Field Name Function Starting Address Hi Starring Address Lo Quantity of Input Reg. Hi Quantity of Input Reg. Lo Response Field Name Function Byte Count Input Reg.9 Hi Input Reg. 9 Lo

(Hex) 04 00 08 00 01

(Hex) 04 02 00 0A

17

2.4.5 05 (0x05) Write Single Coil This function code is used to write a single output to either ON or OFF in a remote device. The requested ON/OFF state is specified by a constant in the request data field. A value of FF 00 hex requests the output to be ON. A value of 00 00 requests it to be OFF. All other values are illegal and will not affect the output. The request PDU for Write Single Coil is shown in the Table 2.15.

ENTRY MB Server receives mb_req_pdu

NO Function code supported YES NO 0x0001<=Quantity of Registers<=0x07D0

YES NO Starting Address == OK AND Starting Address + Quantity of Registers == OK YES Request Processing

NO Read Input Registers == OK YES MB Server sends mb_rsp

MB Server Sends mb_exception_rsp

EXIT

Figure 2.9: Read Input Registers state diagram It specifies the address of the coil to be forced. Coils are addressed starting at zero. Therefore coil 1 is addressed as 0. The requested ON/OFF state is specified by a constant in the Coil Value field. A value of 0XFF00 requests the coil to be ON. A value of 0X0000 requests the coil to be off. All other values are illegal and will not affect the coil. The response PDU is shown in the Figure 2.13. The normal response is an echo of the request, returned after the coil state has been written. The state diagram for Write Single output is shown in the Figure 2.10. The Table 2.17 shows an example of a request to write Coil 173 ON.

18

Table 2.15: Write Single Coil Request PDU Function Code Output Address Output Value 1 Byte 2 Bytes 2 Bytes 0x05 0x0000 to 0xFFFF 0x0000 to 0xFF00

Table 2.16: Write Single Coil Response PDU Function Code Output Address Output Value 1 Byte 2 Bytes 2 Bytes 0x05 0x0000 to 0xFFFF 0x0000 to 0xFF00

Table 2.17: Write Single Coil PDU Example Request Field Name Function Output Address Hi Output Address Lo Output Value Hi Output Value Lo (Hex) 05 00 AC FF 00 Response Field Name Function Output Address Hi Output Address Lo Output Value Hi Output Value Lo (Hex) 05 00 AC FF 00

ENTRY MB Server receives mb_req_pdu

NO Function code supported YES NO Output Value == 0x0000 OR 0xFF00

YES NO Output Address == OK

YES Request Processing

NO Write Single Output == OK YES MB Server sends mb_rsp

MB Server Sends mb_exception_rsp

EXIT

Figure 2.10: Write Single Output state diagram

19

2.4.6 06 (0x06) Write Single Register This function code is used to write a single holding register in a remote device. The request PDU is show in the Table 2.18. The Request PDU specifies the address of the register to be written. Registers are addressed starting at zero. Therefore register 1 is addressed as 0. The normal response is an echo of the request and is shown in the Table 2.19, returned after the register contents have been written. The state diagram is shown in the Figure 2.11. Table 2.18: Write Single Register Request PDU Function Code Register Address Register Value 1 Byte 2 Bytes 2 Bytes 0x06 0x0000 to 0xFFFF 0x0000 to 0xFFFF

Table 2.19: Write Single Register Response PDU Function Code Register Address Register Value 1 Byte 2 Bytes 2 Bytes 0x06 0x0000 to 0xFFFF 0x0000 to 0xFFFF

An example for a request to write register 2 to 00 03 hex is shown in the Table 2.20.

Table 2.20: Write Single Register PDU Example Request Field Name Function Register Address Hi Register Address Lo Register Value Hi Register Value Lo (Hex) 06 00 01 00 03 Response Field Name Function Register Address Hi Register Address Lo Register Value Hi Register Value Lo (Hex) 06 00 01 00 03

20

ENTRY MB Server receives mb_req_pdu

NO Function code supported YES NO 0x0000 <= Register Value <= 0xFFFF YES NO Register Address == OK

YES Request Processing

NO W rite Single Register == OK YES MB Server sends mb_rsp

MB Server Sends mb_exception_rsp

EXIT

Figure 2.11: Write Single Register state diagram

2.5 Hardware Implementations

Versions of the Modbus protocol exist for serial lines (Modbus RTU and Modbus ASCII) and for Ethernet (Modbus TCP). Most Modbus devices communicate over a serial RS-485 physical layer 2.5.1 Serial Implementation In Modbus, data is transmitted over serial lines between devices. The simplest setup would be a single serial cable connecting the serial ports on two devices, a Master and a Slave. The data is sent as series of ones and zeroes called bits. There are two serial modes that the Modbus application layer can follow: RTU and ASCII. In RTU, the data is represented in Binary format, whereas the ASCII mode represents the data such that it is human readable. Figure 2.12 and 2.16 demonstrate the difference between these two modes. The most common serial protocols used with Modbus are RS-232 and RS-485. In the present work RS-485 interface is used. Since it is differential, it resists electromagnetic interference from other equipment and supports long distance.

21

Figure 2.12: Modbus RTU Serial Frame

Figure 2.13: Modbus ASCII Serial Frame 2.5.2 TCP Implementation The Modbus protocol can also be implemented using TCP/IP. As in many TCP applications, the first requirement is to establish a connection between the master and the slave. When connection has been established, the master can build a request for the slave. The request contains a PDU (Modbus frame described above) followed by a MPAB header, as shown in Figure 2.14. Figure 2.15 represents a template for the MPAB header.

Figure 2.14: Modbus TCP Frame

22

Description Transaction Identifier Hi Transaction Identifier Lo MBAP Header Protocol Identifier Length Unit Identifier

Size 1 1 2 2 1

Example 0x15 0x01 0x0000 0x0006 0xFF

Figure 2.15: MBAP Header

Figure 2.16: Complete Modbus TCP Transaction

23

The Transaction Identifier can be like a TCP Sequence Number used to keep track of which Modbus transaction the packet is associated with. This is important because, in Modbus TCP, the slave can handle many requests at the same time. The Unit Identifier is typically used to address the Modbus slave. When using Modbus TCP, the address of the slave is its IP address and the Unit Identifier in the MBAP header is not used. Figure 2.16 demonstrates a complete Modbus TCP transaction. The present work involves Modbus implementation over serial in a mode called RTU using RS485.

2.6 Conclusion
In this chapter, Modbus Protocol, its function codes and physical media used for Modbus protocol implementation are discussed.

24

3. HARDWARE DESIGN
This chapter describes the hardware design of the overall system.

3.1 Functional Overview

Figure 3.1: Block diagram of overall system The overall structure of the embedded data acquisition system along with major functional blocks is shown in the Figure 3.1. The Master system uses S3C2440 microcontroller as core. This system contains many kinds of peripheral connections, including the serial port, the AD interface, RS485 interface, SD/MMC card reader, JTAG debugging interface and etc. The embedded Linux operating system is used in the Master system, and the Modbus master protocol function is realized. The Modbus Master Protocol application is developed using ARM-LINUX-GCC cross compiler and ported onto the Master. The Slave system is built using LPC2148 microcontroller and Modbus Slave protocol is realized on it. The Slave protocol application is developed using KEIL
25

Vision4 Integrated Development Environment and its image flashed onto the slave system using Flash magic tool. The Master System can read the data from the Modbus slave through the serial port. Simultaneously, data can be transmitted from the Master to the monitoring center (PC) through Ethernet interface for monitoring. This is done using an application program written in monitoring center to get data from the Modbus Master. The system uses RS485 standard to establish the communication between the Master and the Slave. Initially whenever, user requires any data or any action to be performed by slave system situated remotely, the monitoring centre sends a request to the Modbus master, the master, when it gets the request from the monitoring centre. In response, master composes a request frame and sends it using serial communication. This frame is level converted to RS485 and transmitted on the RS485 physical channel. Upon reception of the request frame, the slave to which it corresponds responds and constructs the response frame and sends it to the master. The data is also sent to the Monitoring centre. The detailed description of the hardware of the complete architecture is presented below.

3.2 Master System Hardware

S3C2440 microcontroller based Development board is used as core of the hardware for the master system in this work. The block diagram of Master is shown in Figure 3.2 and its hardware is shown in the Figure 3.3. It includes serial port, Ethernet interface, JTAG port, storage systems and other associated devices. JTAG (Joint Test Action Group) is an international test protocol standard. Software simulation, singlestep debug utility and u-boot download can be carried out through the JTAG port, it is a simple and efficient means of developing and debugging embedded systems. The SDRAM capacity in the system is 64MB and data bus is 32-bit. For supporting boot loader in the NAND Flash, a buffer named Steppingstone is equipped in SDRAM. When the system is starting, the first 4KByte content in NAND Flash is loaded into this buffer and executed. During Startup, the contents of the NAND Flash are copied to the SDRAM. A copy of the application program is loaded from NAND Flash to SDRAM and it is executed from SDRAM.
26

LCD

SD Card Interface

2MB NOR Flash

USB Interface

64MB SD RAM 256MB NAND Flash Serial Port

Samsung S3C2440

Reset Ethernet Interface JTAG Port

Audio Interface

Power

Figure 3.2: Block diagram of Master S3C2440 UART provides three serial I/O ports; each port can operate either in interrupt mode or in DMA mode. UART can support a maximum baud rate of 115.2KBps when using the system clock. Each UART channel includes 64-bit

receiver and transmitter FIFOs. The TXD and RXD lines of the UART are connected to an external MAX485 and the logic levels are converted to suit RS485 voltage levels. Using the Ethernet interface, the system is connected to the Monitoring centre to exchange the data with the Master system. USB interface is employed to download the Boot Loader, Kernel Image, Root file system and the Modbus protocol application.

27

Figure 3.3: Master system hardware

3.3 Slave System Hardware

The Slave system is designed using LPC2148 microcontroller. The block diagram of the slave system is shown in the Figure 3.4 and its hardware is shown in the Figure 3.5. The slave system receives the request frames from the master over RS485 communication line. The frames which are received over the RS485 line are received using UART0 module of the LPC2148 microcontroller. The received frames are decoded by the processor and the corresponding actions are carried out. After performing the actions, the slave also sends the response frames to the Modbus Master. The frames are transmitted character by character on the TXD line of the UART0 which in turn sent over the RS485 line. The detailed description of the peripheral interfaces employed in the realization of the Modbus protocol is given below:

28

2x16 CHARACTERS LCD DISPLAY

RS 485 Interface

Connector for UART0 LPC2148

ADC Interface

Reset Connector for UART1 JTAG Port

Relay Interface

GPIO Connector

Switch Interface

Power Supply

Figure 3.4: Block diagram of Slave System

Figure 3.5: Slave system hardware

29

3.4. Functional Blocks 3.4.1 LPC2148 Microcontroller LPC2148 microcontroller uses ARM7 processor core. ARM stands for Advanced RISC Machine. It is a 32 bit processor used for high end applications. The LPC2148 microcontrollers are based on a 16-bit/32-bit ARM7TDMI-S CPU with real-time emulation and embedded trace support, that combine the microcontroller with embedded high speed flash memory ranging from 32KB to 512KB. A 128-bit wide memory interface and unique accelerator architecture enable 32-bit code execution at the maximum clock rate. For critical code size applications, the alternative 16-bit Thumb mode reduces code by more than 30 % with minimal performance penalty. The LPC 2148 microcontroller is shown in Figure 3.6.

Figure 3.6: LPC 2148 Microcontroller IC Due to their tiny size and low power consumption, LPC2148 is ideal for applications where miniaturization is a key requirement, such as access control and point-of-sale. Serial communication interfaces ranging from a USB 2.0 Full-speed device, multiple UARTs, SPI, SSP to I2C-bus and on-chip SRAM of 8 KB up to 40 KB, make these devices very well suited for communication gateways and protocol converters, soft modems, voice recognition and low end imaging, providing both large buffer size and high processing power. Various 32-bit timers, single or dual 10-bit ADC(s), 10-bit DAC, PWM channels and 45 fast GPIO lines with up to nine edge or level sensitive external interrupt pins make these
30

microcontrollers suitable for industrial control and medical systems. The Figure 3.7 and the Figure 3.8 show LPC2148 microcontroller Architecture and Pin diagram respectively. 3.4.1.1 Features of LPC2148 Microcontroller 16-bit/32-bit ARM7TDMI-S microcontroller in a tiny LQFP64 package. 40 KB of on-chip static RAM and 512 KB of on-chip flash memory; 128-bit wide interface/accelerator enables high-speed 60 MHz operation. In-System Programming/In-Application Programming (ISP/IAP) via on-chip boot loader software, single flash sector or full chip erase in 400 ms and Embedded Trace interfaces offer real-time debugging with the on-chip Real Monitor software and high-speed tracing of instruction execution. USB 2.0 Full-speed compliant device controller with 2 KB of endpoint RAM. In addition, the LPC2148 provides 8 KB of on-chip RAM accessible to USB by DMA. One or two (LPC2141/42 Vs, LPC2144/46/48) 10-bit ADCs provide a total of 6/14 analog inputs, with conversion times as low as 2.44 ms per channel. Single 10-bit DAC provides variable analog output (LPC2148 only) Two 32-bit timers/external event counters (with four capture and four compare channels each), PWM unit (six outputs) and watchdog. Low power Real-Time Clock (RTC) with independent power and 32 kHz clock input. Multiple serial interfaces including two UARTs (16C550), two Fast I2C-bus (400 Kbit/s),SPI and SSP with buffering and variable data length capabilities. Up to 45 of 5 V tolerant fast general purpose I/O pins in a tiny LQFP64Package. Up to 21 external interrupt pins available. 60 MHz maximum CPU clock available from programmable on-chip PLL with settling time of 100 ms. On-chip integrated oscillator operates with an external crystal from 1 MHz to 25 MHz and Power saving modes include Idle and Power-down. Individual enable/disable of peripheral functions as well as peripheral clock scaling for additional power optimization.
31

Processor wake-up from Power-down mode via external interrupt or BOD. CPU operating voltage range of 3.0 V to 3.6 V (3.3 V 10 %) with 5 V tolerant I/O.

Figure 3.7: LPC2148 Microcontroller Architecture

32

Figure 3.8 LPC2148 Microcontroller Pin Diagram 3.4.2 Power Supply The Slave system is supplied by an external 7.5V/1A through input Jack. A LM117 voltage regulator is employed that powers all the 3.3V components on board. The LPC2148 microcontroller uses 3.3V as its main supply source. There are some components that require 5V power so a 5V regulator is also provided on the board. The power supply for the slave system is shown in the Figure 3.9

33

Figure 3.9: 3.3V and 5V Power Supply 3.4.3 Reset Circuitry An on-board switch provides the LPC2148 with external reset Control. The RESET pin of LPC2148 is connected to this switch and whenever the switch is pressed the board gets RESET. It makes the chip behave as for a power-on reset. The Reset circuit is shown in the Figure 3.10.

Figure 3.10: Reset Circuit

34

3.4.4 LCD Interface The slave system has 16 characters by 2 lines LCD and it is connected to LPC2148 microcontroller in 8 bit mode. This LCD works with 5V supply. The contrast of LCD is controlled by user using a potentiometer. This LCD is used for user interface to convey the slave operation. It displays the messages corresponding to different frames received and different operations performed on the slave system. The LCD interface is shown in the Figure 3.11. Liquid crystal displays (LCDs) have materials which combine the properties of both liquids and crystals. Rather than having a melting point, they have a temperature range within which the molecules are almost as mobile as they would be in a liquid, but are grouped together in an ordered form similar to a crystal. An LCD consists of two glass panels, with the liquid crystal material sandwitched in between them. The inner surface of the glass plates are coated with transparent electrodes which define the character, symbols or patterns to be displayed polymeric layers are present in between the electrodes and the liquid crystal, which makes the liquid crystal molecules to maintain a defined orientation angle.

Figure 3.11: LCD Interface

35

One each polarizer is pasted outside the two glass panels. These polarizers would rotate the light rays passing through them to a definite angle, in a particular direction. When the LCD is in the off state, light rays are rotated by the two polarizers and the liquid crystal, such that the light rays come out of the LCD without any orientation and hence the LCD appears transparent. When sufficient voltage is applied to the electrodes, the liquid crystal molecules would be aligned in a specific direction. The light rays passing through the LCD would be rotated by the polarizers, which would result in activating / highlighting the desired characters. The LCDs are lightweight with few millimeters of thickness. Since the LCDs consume less power, they are compatible with low power electronic circuits and can be powered for long durations.

Table 3.1: LCD Data & Control Lines Pin 1 2 3 4 Symbol Vss Vcc VEE RS I/O ---I Description Ground +5V power supply Power supply to control contrast RS=0 to select command register RS=1 to select data register 5 R/W I R/W=0 for write R/W=1 for read 6 7 8 9 10 11 12 13 14 E DB0 DB1 DB2 DB3 DB4 DB5 DB6 DB7 I/O I/O I/O I/O I/O I/O I/O I/O I/O Enable The 8-bit data bus The 8-bit data bus The 8-bit data bus The 8-bit data bus The 8-bit data bus The 8-bit data bus The 8-bit data bus The 8-bit data bus

The LCD s wont generate light and so light is needed to read the display. By using backlighting, reading is possible in the dark. The LCDs have long life and a wide
36

operating temperature range. Changing the display size or the layout size is relatively simple which makes the LCDs more customer friendly. The control and Data lines of LCD are described in Table 3.1. The data lines of the LCD are connected to Port1 to the Pins from P1.16 through P1.23 and the control lines are connected to the pins Port0 to the pins P0.11, P0.12 and P0.13. 3.4.5 ADC Interface The slave system has an ADC interface to acquire digital data corresponding to the sensors connected to the analog channels of ADC. This acquisition in Modbus protocol is termed as reading the input register. A potentiometer is connected to the ADC of LPC2148 to realize the function of Read Input Register data type in Modbus protocol. This interface is shown in the Figure 3.12.

Figure 3.12: ADC Interface

3.4.6 General Purpose Parallel I/O (GPIO) Device pins that are not connected to a specific peripheral function are controlled by the GPIO registers. Pins may be dynamically configured as inputs or outputs. Separate registers allow setting or clearing any number of outputs simultaneously. The value of the output register may be read back, as well as the current state of the port pins. LPC2148 introduces accelerated GPIO functions over prior LPC2000 devices:

37

 GPIO registers are relocated to the ARM local bus for the fastest possible I/O timing. Mask registers allow treating sets of port bits as a group, leaving other bits unchanged. All GPIO registers are byte addressable. Entire port value can be written in one instruction. Performing Read/Write of 8 or 16 bits of data from or to the slave system is possible. When the master performs this type of operation then it is termed as read or write of Holding Register. This operation is realized in the present work is done by reading the ON/OFF status of 8 LEDs connected to slave and writing a value onto the LEDs connected. This interface is shown in the Figure. This is done by connecting LEDs to the GPIO lines of LPC2148 microcontroller. It is shown in the Figure 3.13.

Figure 3.13: LED Interface

38

3.4.7 UARTs The slave system has two UART ports UART0 and UART1. These can be used for communication with external RS232 based peripherals. UART0 can also be used for In-System Programming (ISP). Using the same UART0 the Modbus protocol frames are received and transmitted. The RS232 interface is shown in the Figure 3.14.

Figure 3.14: RS-232 Interface 3.4.8 Relay Interface The slave system can turn ON and OFF different electrical appliances connected to it. These appliances connected to the slave system through relays. The power to the electrical appliances is controlled through relay by the microcontroller. This kind of operation in the Modbus protocol is termed as write of the coil. The relay interface is as shown in the Figure 3.15.

39

Figure 3.15: Relay Interface 3.4.9 Switch Interface The status of devices connected to the slave system can be known by reading the status of the line to which the device is connected. The type of operation is referred to as reading Discrete Input in Modbus protocol. This is demonstrated by connecting a switch to the microcontroller and reading its status by the master system by sending request frame to read the status of it. The switch interface to microcontroller is shown in the Figure 3.16. Normally when the switch is open and the I/O line is read, it gives a high value since the I/O line is pulled high to VCC. Whenever the switch is closed, the I/O line is connected to ground because the other end of the switch is connected to ground. It gives zero value when the line is read by the microcontroller. 3.4.10 RS 485 Serial Communication Interface In the present work the Modbus master and the slave communicate using RS485 protocol. RS485 is a differential serial communication interface, commonly used in industrial applications. It has the ability to communicate up to 1200m within a network structure. The RS485 is also a widely used communication interface in data

40

acquisition and control applications where multiple nodes communicate with each other.

Figure 3.16: Switch Interface

3.4.10.1 Cables and Signals Since the signal reference of the RS485 does not have a common zero; several volts difference in the ground level is not a problem. The RS485 signals are floating and each signal is transmitted over a U+ line and a U- line. The RS485 receiver compares the voltage difference between both lines, instead of the absolute voltage level on a signal line. This prevents different potential (ground loop) which is a common source of communication problems. A combination of twisting and shielding increases the noise immunity and is used in networking cables. Differential signals and twisting allows RS485 to communicate over distances of 1200m. Although the interface is fast, its data speed decreases with longer cables. The RS485 waveform is shown in the Figure 3.17.

41

Figure 3.17: RS485 waveform 3.4.10.2 RS485 Functionality By default, all the senders on the RS485 bus are in tri-state with high impedance. The term tri-state indicates that there is a third output state of an RS485 driver in addition to the high and low output states. One of the nodes is defined as a master and the rest are defined as slaves. The master sends queries or commands to the slave nodes over the RS485 bus. Depending on the information in the sent data, zero or more nodes on the line respond to the master. In this situation, bandwidth can be used for almost 100%. There are other implementations of RS485 networks where every node can start a data session on its own. With the implementation of a RS485 network it is necessary that there is an error detection implemented to detect and correct the data corruption by resending the information. Figure 3.18 shows RS485 drivers on a bus.

Figure 3.18: RS485 drivers on a bus RS485 drivers automatically return to their high impedance tri-state within a few microseconds after the data has been sent. Therefore it is not needed to have delays between the data packets on the RS485 bus. The Master and Slave systems are connected to the MAX485 via the UART RX/TX pins and with this configuration the system can handle up to 32 transceivers.
42

The RS485 protocol allows data transfer of frame. The system was easy to build and communication with other units was moderately easy to implement. With a system based on RS485, the master controller initiates all communication and the slave node respond only when enquired.

3.5 Conclusion
The Master system hardware and hardware design of the Slave system are discussed in this chapter.

43

4. DESIGN OF THE SOFTWARE SYSTEM

4.1 Introduction
This chapter gives an overview of software routines, algorithms and device drivers that comprise the software system. It deals with Modbus protocol implementation on the master system, application development on the Monitoring system to interact with the Master and Modbus protocol implementation on the slave.

4.2 Functional Overview of the Master Software

The software architecture of Master system is described in the functional overview, Followed by the description of internal components in the subsequent sections.

Figure 4.1: Master Software Architecture The software implementation for the master involves three tasks and is shown in the Figure 4.1. Linux transplantation

44

Routines written in C for serial driver invocation, construction of request frames and reception of frames.

Socket Programming application development to communicate and share data between monitoring centre and the Modbus Master system.

4.3 Embedded Linux Transplantation

4.3.1 Introduction Software development process based on embedded OS includes: Establishment of cross compiler, the transplantation of Bootloader, transplantation of embedded Linux and root file system. Later the embedded application is ported onto the system, afore mentioned strategy is followed for the Modbus master software development. This section discusses Linux Kernel Transplantation on the Master system. To begin with, system cross-compiler environment using arm-linux-gcc- 4.3.3 is established. Supervivi Bootloader is used as Bootloader. The function of Bootloader is to initialize the hardware devices, establish memory mapping tables, thus establish appropriate hardware and software environment, and prepare for the final call to the operating system kernel. Besides, yaffs file system is made. For compiling the kernel on the ARM9 board cross compiler environment should be created. A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is run. Cross compiler tools are used to generate executables for embedded system. 4.3.2 Establishing cross-build environment The arm-linux-gcc cross compiler is employed to generate the executables for the Master system. The following steps are done to install it. Step1: Latest arm gcc cross compiler source code is obtained. The arm-linux-gcc4.3.2.tgz tar file is copied into a directory. The tar file is extracted as follows and its extraction is shown in the Figure 4.2. # tar xvzf arm-linux-gcc-4.3.2.tgz -C /

45

Figure 4.2: tar file decompression process

Step2: The installed compiler path is added to the system environment variable: PATH. It is done by editing the .bashrc file as follows. # vim / root /.bashrc At the end of the file the following line is added as shown in the Figure 4.3. export PATH = $ PATH: / usr/local/arm/4.3.2/bin Then the file is saved and exit.

Figure 4.3 : Adding Cross Compiler Path to PATH variable

In order to take effects of the above installation the host system is restarted. After rebooting the system the command arm-linux-gcc -v is issued at the command prompt. A message appears, indicating that cross-compiler environment has been successfully installed.
46

4.3.3 Compiling the Kernel For the Linux operating system to work on the board the kernel source code is compiled to create zImage. The following steps are carried out to build zImage: Step 1: The kernel source code is downloaded from http://kernel.org Step 2: The source code is uncompressed with the command # tar xvzf linux-2.6.29.tgz Step 3: After uncompressing the source code and it is required to change to the source directory with the following command. #cd linux2.6.29 Step 3: The command make menuconfig is issued. The kernel configuration interface appears. # make menuconfig The required configuration is chosen and the configuration is saved as shown in the Figure 4.4 Step 5: The kernel image is built using the command. # make zImage After compilation, the Linux kernel image file (zImage) is built into arch/arm/boot directory as shown in Figure 4.5

47

Figure 4.4: Saving the configuration

Figure 4.5: Kernel Image built into boot directory.

4.3.4 Porting the Linux Kernel to ARM9 Platform

DNW tool is installed on Windows operating system to port embedded Linux onto the

Master system. DNW is needed for all functions related to image downloading through USB connection. The DNW tool is opened, USB: OK message is displayed for successful connection. This is shown in the Figure 4.6.

48

Figure 4.6: DNW Tool Menu options

ARM9 board is connected to the host computer through USB cable, the boot switch is put to NOR position and the board is powered ON, the supervivi main menu is appeared on the hyper terminal of the host computer. The hyper terminal is a software utility to view the serial data that is sent to the serial communication port of the host machine. Here, In the ARM9 board the NOR flash holds a BIOS (supervivi) which allows to port the embedded operating system onto the NAND flash. The supervivi menu options are as shown in the Figure 4.7.

Figure 4.7: Supervivi Main Menu

For the Linux operating system to work on the board the following images are needed to be installed. 4.3.4.1 Boot loader A boot loader, also called a boot manager, is a small program that places the operating system (OS) of a computer into memory. When a computer is powered-up or restarted, the basic input/output system (BIOS) performs some initial tests, and then
49

transfers control to the master boot record (MBR) where the boot loader resides. Most new computers are shipped with boot loaders for some version of Microsoft Windows or the Mac OS. If a computer is to be used with Linux, a special boot loader must be installed. For Linux, the two most common boot loaders used are: LILO (Linux Loader) and LOADLIN (LOAD Linux). An alternative boot loader, called GRUB (Grand Unified Boot loader), is used with Red Hat Linux. LILO is the most popular boot loader among computer users that employ Linux as the main, or only, operating system. Vivi boot loader is used for ARM line processors. Supervivi is a boot loader based on Samsung open source vivi. It can be used as a tool to download and burn OS image to the flash on board. It can also be used for parameters configuration. Supervivi is installed in NAND Flash with the following procedure described below: When Supervivi is booting from NOR flash, user can hold down space bar in hyper terminal when board is booting, to force supervivi enter main menu or supervivi will directly boot OS image by default. Because vivi supports only serial interface, to communicate between host PC and embedded system, the host PC is connected to target board by serial cable. After the Supervivi main menu is appeared on hyper terminal, 'v' key is pressed which is the option for loading the boot loader as indicated in the Figure 4.8.

Figure 4.8: Selection of Download vivi option from the menu

50

On DNW tool, USB Port> Transmit/Restore option is chosen to download supervivi image file. After successfully downloading, BIOS will update this new supervivi image to NAND Flash as shown in the Figure 4.9.

Figure 4.9: Supervivi Command Prompt running from NAND Flash.

4.3.4.2 Loading Kernel Image The compiled kernel zImage is loaded on to the target board by pressing 'k' option from Supervivi main menu displayed on hyper terminal as shown in the Figure 4.10.

Figure 4.10: Selection of Download linux kernel option from menu

51

On DNW tool, USB Port> Transmit/Restore option is selected to download the compiled kernel image. The Linux Kernel image will be updated to NAND Flash after successfully downloaded. 4.3.4.3 Installing file system The Linux kernel works hand in hand with what is called the root file system. This is the file system upon which the root directory can be mounted and which contains the files necessary to bring the system to a state where other file systems can be mounted and user space daemons and applications get started. The exact contents of the root file system will vary according to the computer, but they will include the files that are necessary for booting the system and for bringing it up to such a state that the other file systems can be mounted. The contents will include the root directory together with a minimal set of subdirectories and files including /boot, /dev, /etc, /bin, /sbin and sometimes /tmp. To install root file system, y is pressed on hyper terminal as shown in the Figure 4.11.

Figure 4.11: Selection of Download root_yaffs image option from menu

On DNW tool, USB Port> Transmit/Restore option is chosen to select which file system image file to be downloaded. Linux file system image will be updated to NAND Flash after successfully downloaded as shown Figure 4.12.

52

Figure 4.12: Download Status of Linux File System into NAND Flash

The USB cable is unplugged after system is successfully updated, then the switch S2 is put towards NAND side and the reset button is pressed. The Supervivi is restarted and it will boot Linux automatically.

4.4 Modbus Protocol implementation on Master

The Modbus implementation on the Master consists of routines for construction of Request frames, serial driver invocation from the user space for transmission of Request frames, reception of Response frames of Modbus protocol and application development on the Master to interact with Monitoring centre. These are discussed in the subsequent sections. The flowchart for the Master operation is shown in the Figure 4.13. 4.4.1 Construction of Request frames In Modbus protocol different frames are used for performing different operations as discussed in Chapter 2. The Figure 4.14 shows the formation of a frame. Several such frames are formed to carry different operations on the Slave system. Each of these frames has different function code describing the operation to be performed on the slave, address and quantity of inputs or outputs to processed. There are dedicated functions for constructions of the different requests frames used.
53

Start

open the serial communication driver

configure the serial driver

create socket

3 Monitoring centre socket connected YES

NO read choice from Monitoring Centre

YES choice == 1

construct function code1 frame & transmit

NO YES choice == 2 construct function code2 frame & transmit

NO YES construct function code3 frame & transmit

choice == 3

NO YES choice == 4 construct function code4 frame & transmit

NO YES choice == 5 construct function code5 frame & transmit 2

NO 1

54

YES choice == 6 construct function code6 frame & transmit

NO YES choice == 7 construct function code5 frame & transmit

NO receive response frame

write response data to monitoring centre

close socket

close serial driver

Figure 4.13: Flowchart for Master system software operation

The construction remains the same for every frame but the data fields vary from frame to frame. After the frame is constructed the frames are sent to the slave by adopting the procedure described in the section 4.4.2. The function for the construction of the Request frame is shown in the Figure 4.14.

55

Figure 4.14: Modbus Request Frame Formation 4.4.2 Transmission of Request frames The Request frames from the Master to slave are transmitted using serial communication. This is accomplished by using built-in UART of the S3C2440 microcontroller of the Master. As the Master system works with the embedded Linux OS, the task of sending the data serially is performed by the serial driver of Linux system that is transplanted. This serial driver is part of the serial subsystem of the Linux Operating System. The serial subsystem of linux kernel consists of the following drivers: i. ii. iii. Low-level UART driver that handles the internals of UART. A TTY driver layer that interfaces with the low-level driver. Line discipline drivers that are used for data exchange with TTY layer. Line disciplines act as interface between low-level driver and the TTY layer and help support different technologies. A user process can not talk to the serial driver directly. TTY presents a stack of software over the driver and exports the entire functionality via TTY layer. The serial subsystem is split into three layers as shown in Figure 4.15.

56

As Figure 4.15 suggests, every device associated with the serial subsystem is bound to a line discipline that enforces how the transmitted or received data is processed by the low-level driver. Linux offers a default line discipline N_TTY that can be used for using a serial port.

Figure 4.15: Serial subsystem in Linux Figure 4.16 shows how data flows from user space down to hardware interfaces and backwards. Writing data to serial port is straightforward, but the reading is more complex than writing because there's no direct relationship between hardware (that pushes up data when it arrives) and user space (that requests data when it needs it). The solution for this is use of buffering: data received by hardware remains on hold in a kernel buffer until a user space program requests it; whenever a user program asks for data and the buffer is empty, the program is put to sleep, and is awaken only when the buffer is filled at least partially. The write buffer exists as well; however, the write implementation is much more straightforward because each step towards hardware level is directly driven by the step above it. There are no
57

uncontrolled delays in data transmission, and the buffer is only needed to decouple hardware transmission from program flow. When it is required to send Request frame from Master to Slave, the Master application uses the user space write system call to write the data onto the serial port. But the frame is not directly written to the hardware. The write system call calls the tty_write call of the TTY layer. This calls the ldisc_write of the line discipline driver which in turn invokes the driver.write of the UART drive. This actually writes data onto the hardware and the frame is transmitted on the serial line.

Figure 4.16: Data flow and function calls in writing and reading In reading, whenever a response frame arrives from the Slave the Interrupt handler stores that in flip buffer of the UART driver and later is transferred to tty buffer. When the user invokes a read system call from the user space, it calls tty_read of the tty layer, it reads the data from the tty buffer and presents it to the user space read system call, Thus the response frame is received by the Master application.

58

The steps for serial communication transmission in Linux are as follows: Step1: Open the /dev/ttySAC1 serial device port. Step2: Create an instance for the termios structure and the get the attributes of the opened device into the created instance using tcgetattr function. Step3: Set the input and output baud rates to 9600 using cfsetispeed and cfsetospeed functions. Step4: Select number of data bits and stops bits and disable parity using termios structure member c_cflag and initialize other associated settings in c_cflag. Step5: Set the above mentioned properties using tcsetattr function. Step6: Write data to the serial port for transmission. Step7: Close the serial device. The flowchart for the transmission using serial communication is shown in the Figure 4.17 and the its source code implementation is shown in Figure 4.18

Figure 4.17: Flowchart for serial communication transmission in Linux

59

Opening the port

Closing the port

Transmission of request frame

Figure 4.18: code for serial Transmission of Request frame 4.4.3 Reception of Response frames The steps for reception of the data in Linux are same as that of the transmission. In transmission, the data to be transmitted is sent by write system call after the serial port is configured but in reception, received data is read by read system call the flowchart for reception is shown in the Figure 4.19. The reception of the Response frames from
60

the slaves is done by adopting same steps described in section 4.4.2. The code snippet for reception of the Response frame is shown in the Figure 4.20.
start

Open the /dev/ttySAC1 device node

Get attributes of the device using tcgetattr function

Set the baud rate using cfsetispeed & cfsetospeed functions

Select no. of data, start, stop bits and no parity.

Set the above properties using tcsetattr function

Read data received using read system call

Close the serial port device node

stop

Figure 4.19: Flowchart for serial communication reception in Linux

Figure 4.20: Function for the reception of the response frame

61

4.5 Master Interaction with the Monitoring Centre

The communication between the Monitoring Centre and Modbus master is achieved using socket programming. A socket programming is a communication mechanism that allows Client/Server systems to be development across networks. In the present work, the Monitoring Centre is configured as client and the Master System is configured as server. Initially the server application creates the socket. The server creates it using the system call socket. The server process then, gives the socket a name. The socket is named using the system call bind. Then system call, listen, creates a queue for incoming connections. The server can accept them using the system call accept. When the server calls accept, a new socket is created that is distinct from the named socket. This new socket is used solely for communication with this particular client. In monitoring centre application, the client creates a unnamed socket by calling socket. It then calls connect to establish a connection with server by using the servers named socket as an address. Once connection is established, sockets provide two-way data communication using read and write system calls. The Master system acquires data from the Slave system. Acquired data is communicated with the Monitoring Centre using read and write calls after the connection is established using socket. The connection is closed when the data acquisition or operation is completed. The flow chart shown in the Figure 4.21 depicts the Socket programming implementation between the Master system and Monitoring Centre, the Figure 4.22 & 4.23 give the code snippets of Master system and Monitoring Center socket implementations respectively. The flow chart for the Monitoring centre application implementation is shown in the Figure 4.24.

62

server socket() bind()

listen()

client socket()

accept() blocks until connection from a client connection establishment read() data(request) data(reply) write() close()

connect() write()

read() close()

Figure 4.21: TCP/IP Socket Implementation

Figure 4.22: Master socket implementation

63

Figure 4.23: Monitoring Centre Socket Implementation

Start

Cteate Socket

Read & Store the Operation choice from menu

connect to Master using created socket

Write the choice to Master

close socket

Figure 4.24: Flowchart for the Monitoring Centre operation

64

4.6 Transferring the application Files

The procedure adopted for transferring application file to the target board is presented below: 1) FTP login to target board, 2) Upload of compiled file. 3) Change Executable attributes of the uploaded program in the target board. The connection between the host PC and the target board is established by file transfer protocol (ftp) using the following command: #ftp 192.168.1.230 The name and password are entered as plg as shown in Figure 4.25.

Figure 4.25: Transferring file using FTP The binary files are transferred using the command put followed by binary file name. After transferring files successfully to the target board on the target side the minicom is opened with the following command. Minicom is a text-based serial port communications program designed for Linux. It is used to talk to external devices which are connected using RS232.

65

#minicom The transferred files are in the directory /home/plg. The properties of the binary files are changed to be executable with the command. # chmod 777 *.* Now the program is executed by using following command. #./Modbus_master

4.7 Modbus Protocol implementation on Slave

The source code developed for slave system consists of routines for LCD, serial communication, processing of request frames, checking valid request frames, performing requested action and construction of response frames. The software architecture is shown in the Figure 4.26. Whenever slave system receives a request frame from the master. The request frame is processed to extract the function code to know the operation to be carried and the operation is performed by using the other field data specified in the request frame. The response frame is constructed after performing the operation. The flow chart shown in the Figure 4.27 depicts the detailed operation of the slave system. The different routines that are developed for the slave operation are described in the subsequent sections.

Figure 4.26: Slave Software Architecture

66

Start

initialization

configure the serial communication

enable serial communication interrupts

initialize I2C protocol for EEPROM

initialize LCD

2 request frame received NO

YES process request frame

YES Function code == 1

read coil status from hardware

NO

write coil status to memory read coil status from memory

construct response frame & transmit frame

67

YES Function code == 2

read switch status from hardware

NO

write switch status to memory read written switch status from memory

construct response frame & transmit frame

YES Function code == 3

read LEDs status from hardware write status to memory read written status from memory

NO

construct response frame & transmit frame

YES Function code == 4

read ADC from hardware

NO 3

write ADC value to memory read written value from memory

construct response frame & transmit frame

68

Figure 4.27: Flowchart for Slave system software operation

4.7.1 Modbus_main Routine The modbus_main is the main function in the slave software. It is used to initialize the UART, UART interrupts, GPIO ports, LCD and ADC. After the initialization of the functions for the above peripherals, the main function displays the name of project on LCD and runs in an infinite loop till it gets the request frame from the Master on the serial port. When the slave receives a request frame, a flag called Rec_End_Flag in UART ISR is set after the reception of the frame is completed. The main function remains in wait state until the Rec_End_Flag becomes one. When this flag is set, a routine named Process_Request_Data is called by the main which processes the received request frame.

69

In the Process_Request_Data routine the Rec_End_Flag which is set when the request frame received is cleared. The received frame is copied into a local buffer for processing. This frame is checked whether the length of the frame is correct, Slave ID and LRC are matched. This job is performed by a routine called Check_Valid_InReq. If the above three parameters are correct, the Check_Valid_InReq routine checks for the validity of function codes. After this checked is performed, it calls the corresponding response code function. For example, if the function code is 0x01 then it calls a function which constructs the response frame for this function code. In this case the function named Response_Funcode1 routine is called which is concerned with the response frame for the function code, 0x01. 4.7.2 Response Frame Routines The response frames are constructed for every request frame received from the master. After the frame is received, the frame fields are extracted and the function code is known. After function code is decoded the operation corresponding to the function code is performed. The response frame is constructed and sent to the Master using the UART. Here, different response frames are constructed based on the request frames received. The function for constructing the response frame for reading the discrete input is shown in the Figure 4.28. 4.7.3 Serial Communication Routine In the present work, the request frames from the Master and response frames to the Master are received and transmitted using serial communication. The serial communication task in the slave is performed by the on-chip UART module present in the LPC2148 microcontroller. The steps for data transfer using the serial communication are as follows: Step1: Configure the microcontroller pins for serial communication. In LPC2148 microcontroller, there are 48 I/O lines. These I/O lines are used for general purpose and for the other functions associated with on-chip peripherals. The Pin Connect Block present in the microcontroller allows the pins of the controller to have more than one function. Configuration registers control connection between the pins and the onchip peripherals. This pin functionality choice is controlled using Pin Select Register (PINSEL). Here, PINSEL0 register is used to select the P0.0 and P0.1 pins to be used for TXD and RXD lines of UART0. Step2: Configure the Line Control Register to select number of data bits in character, start bits and stop bits and parity bits. 70

Perform the operation corresponding to function code 0x02

Calling LRC calc function

Frame construction

LRC calculation routine

Figure 4.28: Response frame construction & LRC calculation routines

Step3: Select the baud rate. Step4: Place character to be transmitted in the UART0 Transmit Holding Register (U0THR). Step5: Monitor the Transmitter Holding Register Empty (THRE) flag in the UART0 Line Status register to become 1. If the THRE flag is 1, it indicates that the character is successfully transmitted. The steps 4 and 5 are repeated if the frame is required to be transmitted. In the present work, the steps1 through 3 are performed using Serial_Init function and steps 4 and 5 are implemented

71

using Serial_SendString1 function. Flowchart for serial transmission is shown in Figure 4.29 and related software routine is shown in Figure 4.30.

Figure 4.29: Flowchart for Serial Communication Transmission

Figure 4.30: Serial communication Transmission Routine 72

The transmission of the response frames from the slave to the Master is performed by the procedure mention above. The reception of the request frames from the master is carried out in interrupt method, because the request frame from the Master may arrive at any time. The procedure for the reception is as follows: Step1: Initialize the serial port. Step2: Select the IRQ line for the reception interrupt. Step3: Pass the ISR address to the VICVectAddr register. Step4: Enable the serial communication reception interrupt. Step5: Read the character from the Receiver Buffer Register when the interrupt is raised. In the reception of the request frames from the master, the interrupt enabling is performed by the function Com0_Int_Enable routine and reception of the frames is carried out in the serial communication reception ISR. The flowchart for the serial reception is shown in the Figure 4.31 and corresponding routine is shown in the Figure 4.32.

Figure 4.31: Flowchart for serial communication reception

73

Serial reception interrupt enabling

Reception of frame char by char into a buffer

Figure 4.32: Serial communication reception routine 4.7.4 Analog to Digital Conversion Routine The LPC2148 microcontroller has two 10-bit analog to digital converts on chip. The Read Input Register data type of Modbus protocol is realized by reading the ADC value from the slave by the master. The steps to program the built-in ADC of microcontroller are described below and the flow chart is shown in the Figure 4.33. Step 1: Configure the pins of microcontroller as analog channels of ADC using PINSEL register. Step2: Select the analog channel to be sampled using ADC control register. Step3: Select the clock for the ADC. Step4: Start conversion by writing Start conversion bit of ADC control register to 1. Step5: Monitor the DONE flag in the ADC data register to become 1. If DONE flag is 1, it indicates the end of conversion. 74

Step6: Read the converted digital data from the ADC data register. This task of acquisition of ADC data is accomplished by the ADC1_Read routine in the present work.. It is shown in the Figure 4.34.

Figure 4.33: Flowchart for ADC operation

Figure 4.34: Analog to Digital Conversion routine 75

4.7.5 LCD Routine In the present work LCD is used to display the operation that is being carried by the slave. The LCD requires 3 control lines (RS, R/W & EN) and 8 or 4 data lines. The number of data lines depends on the mode of operation. If operated in 8-bit mode then 8 data lines and 3 control lines, a total 11 lines are required. And if operated in 4-bit mode then 4 data lines and 3 control lines, 7 lines are required. The type of mode to be used depends on the availability of the I/O lines on the board. In the present work 8-bit mode is used. When RS is low (0), the data sent on the data lines is treated as a command. When RS is high (1), the data being sent is considered as text data which is to be displayed on the screen. When R/W is low (0), the information on the data bus is being written to the LCD. When RW is high (1), the program is reading from the LCD. Most of the times there is no need to read from the LCD so this line can directly be connected to GND, thus saving one controller line. The ENABLE pin is used to latch the data present on the data pins. A HIGH - LOW signal is required to latch the data. The LCD interprets and executes our command at the instant the EN line is brought low. The code snippet for the LCD operation is shown in the Figure 4.35

76

Figure 4.35: LCD routine

4.7.6 GPIO routines In the present work, the relay, switch and LEDs are connected to GPIO lines. The Modbus operations write coil, read coil, write discrete input, read discrete input and write holding register and read holding register are realized using the above mentioned hardware components. These all operations are carried out by manipulating the GPIO lines of the microcontroller. Four major registers are involved in GPIO operations. They are: A. IODIR IODIR controls the 'direction' of the GPIO pin. This is a 32 bit register. Each bit in this register controls one I/O line. This register is used to set a GPIO pin to either Input (0) or Output (1). If 1 is written the pin is configured as output and a '0' configures it as input. For example, if a GPIO pin to send signals 'out' from the microcontroller to some external device, the corresponding bit in IODIR is required to be set to1. If a GPIO pin to receive information from the outside world (reading it inside the microcontroller), GPIO 0.10 is set to 'Input' (0). In the present work the GPIO line used to connect switch is configured as input and the GPIO lines used to connect relay and LEDs are configured as outputs. B. IOSET and IOCLR If the GPIO pin is set as Output (using the IODIR register mentioned above), The register IOSET is used to set the GPIO pin to 'high' (providing a small 3.3V electrical current) and register IOCLR is used to set it to 'low' (providing a connection to GND). In the present work, the relay is connected to GPIO pin P0.4 and the LEDs are connected to GPIO pins from P1.24 through P1.31. The electrical device connected to relay is turned ON by making that GPIO line high. Similarly the LEDs are turned ON by making the GPIO lines to which LEDs are

77

connected high. This action is accomplished by IOSET register. If a bit in this register is set high the corresponding physical pin becomes high. C. IOPIN Regardless of whether a GPIO pin's direction is set to Input or Output, the IOPIN register is used to read the current 'state' of every GPIO pin in the pin block (the collection of all 32 pins in GPIO). A 1 value means that the pin is currently 'high', and a 0 value means the pin is currently 'low'. In the present work, the switch status and the LEDs status can be read by reading the IOPIN registers of the corresponding ports where these devices are connected. The Figure 4.36 shows the GPIO related operations.

Figure 4.36: GPIO operations in the slave.

4.8 Conclusion
The complete software system of the present work is has been described in this chapter which includes Master and Slave Software designs.
78

5. TESTING AND RESULTS

The complete hardware in respect of this work is shown in the Figure 5.1. The Modbus master service includes the function module to interact with Monitoring Centre, the frame formation module, and the return processing module. Each of these module functionality is realized under the embedded Linux environment. The Monitoring Centre application includes the function choice module which interacts with Modbus master using socket programming. It is shown in the Figure 5.3 This man-machine interaction module is a communication module for the users and the platform. It realizes the function of information inputting.

Figure 5.1: Overall System Hardware setup The user input information is read from Monitoring Centre, according to the user information the Master constructs the request frames and transmits to the slave. At the slave end also Modbus protocol is realized by writing an application in embedded C using the KEIL Micro Vision integrated development environment. This application involves the reception of request frames, processing the request frames,
79

performing the requested action and composing the response frames and transmitting them back to the Master, the slave setup is shown in the Figure 5.2.

Figure 5.2: Slave Hardware setup The devices that are used in the slave for demonstration include, a Toggle switch, a Relay as Discrete Input, coil data types respectively. An ADC, LEDs are used to demonstrate the data types, Input Register and Holding Register respectively. When the function choice 1 is selected on the Monitoring centre, this option is transmitted to the Master, the Master using Modbus Protocol implemented sends a frame consisting of 0x01 function code as shown in the Figure 5.4. The slave upon reception of this frame it extracts it and knows the function code and performs the Read coil operation, which is reading the status of Relay to which an electrical bulb is connected. Here the ON/OFF status of the bulb is known to the Master and thereby to the user at the Monitoring Centre. Based on that, the user can take any further action. Similarly when the master receives function choice 2 from Monitoring Centre it sends

80

the frame for Reading Discrete input that is to know the status of the Switch.

Figure 5.3: Function Choice Menu on Monitoring Centre

Figure 5.4: Read Coil (0x01) This information is conveyed by the slave to the Master. The frame with the function code 0x02 reads the switch status. The function choice 3 makes the Modbus master to transmit the frame with function code 0x03 which reads the status of the LEDs connected to the slave; this is called Read Holding Register data type. This data type reads 8-bit of data from the slave here. Similarly data can also be written onto the LEDs which is done by the same data type. This data type can be read or written. The function code for writing is 0x06 and its request from the Master to slave is shown in the Figure 5.6. The data of the any sensor that is connected to the ADC of the slave is acquired by Master by sending the frame with function code 0x04. The read Discrete Input and read Input
81

Register requests are shown in the Figure 5.5. This data type is termed as Input Register.

Figure 5.5: Read Discrete Input (0x02) & Read Input Register (0x03) Here to demonstrate this, the acquisition of data of an analog voltage fed through a potentio meter connected to the ADC is employed, when the potentio meter is varied, these variations are known by the Master when it sends the corresponding request frame.

Figure 5.6: Write Holding Register (0x06)

82

6. CONCLUSION AND SCOPE FOR FUTURE WORK

6.1 Conclusion
A Modbus protocol communication protocol is realized between two embedded devices in this work and the communication is established between them. The RS485 serial communication channel is employed as the physical bus. To provide the communication, Modbus Master protocol application is developed for ARM9 processor based embedded system and Modbus slave protocol application is developed for ARM7 based system. The data types supported by the Modbus protocol are tested by realizing them in hardware.

6.2 Scope for the Future work

Six main kinds of service processing modes are realized for serial Modbus equipment in this platform, which includes: read coil status, read input status, read holding registers, read input registers, write single coil and write single register. These six kinds of mode cover the basic function demand of Modbus. And it is convenient to expand other functions if required. The Modbus protocol is implemented over serial communication channel in the present work. It can be implemented using TCP/IP as the physical medium and can also be implemented using wireless communication using Zigbee wireless protocol.

83

BIBLIOGRAPHY
[1] Design and Realization of Modbus Protocol Based on Embedded Linux System by PENG Dao-gang, ZHANG Hao, YANG Li, LI Hui ,2009. [2] Embedded Linux System Transplant of Linux and Embedded System of Boot Loader and LED Driver by Guo, Hongjun Wang, Zhian Wang, Xuhui , 2010. [3] Linux Device Drivers, Third Edition, by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. [4] Essential Linux Device Drivers by Sreekrishnan Venkateswaran . [5] Methods and skills on transplanting Linux to ARM S3C2410 by Ci

Wenyan; Chen Xueli; Cai Suhua; Xia Chunmei; Electr. Eng. & Autom. Inst., Nanjing Normal Univ., Nanjing, China, 2010. [6] http://www.friendlyarm.net/ [7] http://www.kernel.org. [8] www.linuxjournal.com/magazine [9] http://www.LWN.net [10] Beginning Linux Programming, Third Edition, Neil Matthew and Richard [11] Index of /pub/linux/kernel. Kernel.org. [12] http://www.arm.com/ [13] Balaguru Swamy, C Programming and data structures, Tata-McGraw-Hill, 2 nd edition. .

84

ANNEXURE A
A.1 Minicom
A.1.1 Introduction Minicom is a communication program which somewhat resembles the shareware program TELIX but is free with source code and runs under most unixes. Features include dialing directory with auto-redial, support for UUCP style lock files on serial devices, a separate script language interpreter, capture to file, multiple users with individual configurations, and more. A.1.2 Minicom setup The -s option use to setup minicom. Type the following command at shell prompt the screen will appear as shown in Figure A.1. $ minicom -s -c on

Figure A.1 minicom menu To configure minicom as serial port use up and down arrows to select menus press down and select Serial port setup, the screen will appear as shown in Figure A.2.

85

Fig.A.2: Configure serial port with minicom A - Serial Device: /dev/ttyS0 B - Lockfile Location: Linux systems use /var/lock. If this directory does not exist, minicom will not attempt to use lock files. C - Callin Program: This is the program to get into dial in mode. D - Callout Program: This to get into dial out mode. E - Bps/Par/Bits: 9600 8N1 F - Hardware Flow Control: Yes G - Software Flow Control: No

Press 'Enter' to

save

the

settings.

To

save all settings to

the

/etc/minicom/minirc.dfl file select 'Save settings as dfl'.

To exit Minicom when in terminal mode press Ctrl-A to get a message bar at the bottom of the terminal window and then press 'X'.
86

A.2 MINI2440 Development Board

The MINI2440 Development Board is based on the Samsung S3C2440 microprocessor. Its PCB is 4-layered board, equipped with professional equal length wiring which ensures signal integrity. All MINI2440 boards are manufactured in mass production and released with strict quality control. It is easy for users to get started. Anyone with very basic knowledge about the C language can become proficient in its development. The physical appearance of MINI2440 is shown in Figure A.3

Fig A.3 Physical appearance of MINI2440

A.2.1 Hardware Features:

CPU *Samsung S3C2440A400MHz Main frequency533Mhz Peak Frequency SDRAM * 64M SDRAM on board
87

* 32 bit data bus * SDRAM clock frequency can reach up to 100MHz Flash Memory * 64M Nand Flash on board, non-volatile * 2M Nor Flash on board, non-volatile LCD control * A 4-wire resistive touch screen interface is integrated on the board, via which the 4-wire Resistive touch screen can be connected Interfaces and Resources * One 10MM Ethernet RJ-45 interface (DM9000 Ethernet chip adopted) * 3 serial ports * One USB Host * One stereo audio output interface, one MIC interface System clock source * 12M passive crystal OS supported * Linux 2.6 *WindowsCE.NET 5.0

A.2.2 Hardware Resources:

A.2.2.1 Memory Map and Chip Selection The S3C2440 CPU chip supports two kinds of boot modes: booting at the NAND flash (which is used by the MINI2440) and booting at the Nor flash. The allocation of the storage space of the chip selections is different in the two boot modes. A.2.2.2 SDRAM Two 32MB SDRAM chip (HY57561620FTP, 4Banks x 4MBit x 16bit)) are utilized on the MICRO2440. The two chips are joined up in parallel to produce 32bit data bus width so as to increase access speed, both of them use the nGCS6 as the chip election, and thus, the physical offset of these two SDRAM chips are determined to be 0x30000000. The Figure A.7 below shows the schematics of the SDRAM chips
88

Fig A.7 Schematics of SDRAM chips

A.2.2.3 Flash Storage Two Flash storage chips are used on the MINI2440. One is 2MB NOR Flash (Model: SST39VF1601), the other is 64MB Nand Flash (Model: K9F1208). Both of these two storages can be used as boot source, i.e., the system can boot from either Nor Flash or Nand Flash.By switching the switch S2, we can select either Nor Flash or Nand Flash as boot source. There is no address wire in the Nand Flash; it is connected to the CPU via a special controller, with a data bus width of 8-bit. A 8-bit data bus width does not mean a slow access speed, in fact most of the u-disks and SD cards are made of Nand Flash chips. The Figure A.8 below shows the schematics of the NAND and NOR flash. The Nor Flash is connected to the CPU via 22 address wires (A1-A22) and 16 data wires. The address starts from A1, which determines that the minimum write/read unit is 2 byte, therefore, the Nor Flash supported by MINI2440 maximally is 8 Mb

89

Fig A.8 Schematics of NAND and NOR flash

A.2.2.4 Serial Ports: The S3C2440 microcontroller itself has 3 serial ports in total, namely UART0, UART1, and UART2. The UART0 and UART1 can be combined as a full-functional serial port. In most practices, only three simply serial port functions are used, i.e., send (TXD) and receive (RXD), they are respectively related to the connectors CON1, CON2 and CON3. CON1, CON2, and CON3 are three TTL serial ports directly led out from the CPU. A.2.2.5 USB Interfaces: There are two USB interfaces on the MINI2440. One is USB Host interface and the other is USB Device interface. The USB Host is the same with the USB interfaces on a PC, it can be used to connect USB camera, USB keyboard, USB mouse, U-disk and etc.; The USB Device interface is usually used for downloading programs to the MINI2440 or WinCE synchronization. For controlling the communication between the USB Device and PC, a signal USB_EN is set as shown in the Figure A.9, which uses the CPU resource GPC5.

90

Fig A.9 Schematic of USB interface to MICRO2440.

A.2.2.6 Ethernet Interface: A 10/100M self-adapting Ethernet chip DM9000 and an Ethernet connector RJ45 are used on the MINI2440. The RJ45 connector contains a coupled inductor, therefore a simple Ethernet cable is used to connect the MINI2440 development board to a router or switch. A.2.2.7 Audio Interface: The S3C2440 micro controller embodies an I2S bus interface, to which we can directly connect a 8/16 bit stereo CODEC. On the MINI2440, an I2S bus-based UDA1341 audio chip is used as stereo CODEC to realise audio codec system. The initialization and configuration of the registries in the UDA1341 chip are controlled by the L3-bus. On the MINI2440, the ports GPB2, GPB3, GPB4 on the CPU are taken to simulate the L3MODE, L3DATA, L3CLOCK signals of the L3-bus, they are no longer used after initializing the UDA1341 chip, and therefore these three wires can also be simulated by using a simple single chip. A 3.5mm stereo hole connector is used on the MINI2440 as audio output interface. The audio input system consists of two channels: one MIC on the board and one 2.0mm CON10 connector. The Figure A.10 below shows schematic of audio chip interfaced to MINI2440.

91

ANNEXURE B
B.1 KEIL Vision IDE
The following section explains how to create an application using Keil IDE. 1. Run the KEIL IDE and go to project and select New Vision Project.

2. Select a directory and enter the name of the project file.

3. Select the CPU target as LPC2148 under the option of NXP in the list.

92

4. Next click YES option in the pop-up window

5. Go to File and select new file option, a new text file is appeared save the file with .c extension. Develop the source code in this file.

93

6. Add the source file to the project as shown below

94

7. To build the target go to project and click build target option.

If the build is successful to create the hex file perform the following settings: 8. Click on Target1 in the left pane, and then go to Options for target1 as shown
95

below and in the next pop-up window select the Output tab and check the option Create HEX file as shown below. Next go to Linker tab and check the Use Memory Layout from Target Dialog and click OK.

96

9. Click on the build icon on top of the left pane, as highlighted below. If the project is successfully compiled, HEX file would be generated in the same path where the project file is stored. The Hex file is flashed using flash magic tool.

B.2 Flash Magic Tool

The slave board is programmed through serial port using Flash Magic. Flash Magic is a freeware windows utility used to download the hex file onto the board. The procedure to program the board using Flash Magic utility is described below. 1. Run the FlashMagic.exe

97

2. Change the settings as shown below

3. Now, click on Browse for the HEX file to be downloaded. 4. Now make the board enter the ISP programming Mode. To get the board into programming mode the following steps are to be followed. i) TURN OFF the board using the Power Switch. ii) Press the ISP button and hold it. iii) Now TURN ON the board. 5. Now click on Start to program the board and wait for the programming to be complete. A message Finished on the Flash Magic Window is appeared when the program is burnt.

98