BORANG PENGESAHAN STATUS TESIS

Transcription

1 UNIVERSITI TEKNOLOGI MALAYSIA PSZ 19 : 16 (Pind. 1/97) BORANG PENGESAHAN STATUS TESIS JUDUL : EMBEDDED TCP/IP IN SENSOR NODES (SENSORNETS) SESI PENGAJIAN: 2005 / 2006 Saya : WARSUZARINA BINTI MAT JUBADI (HURUF BESAR) mengaku membenarkan tesis (PSM/Sarjana/Doktor Falsafah)* ini di simpan di Perpustakaan Universiti Teknologi Malaysia dengan syarat-syarat kegunaan seperti berikut: 1. Tesis adalah hak milik Universiti Teknologi Malaysia. 2. Perpustakaan Universiti Teknologi Malaysia dibenarkan membuat salinan untuk tujuan pengajian sahaja. 3. Perpustakaan dibenarkan membuat salinan tesis ini sebagai bahan pertukaran antara institusi pengajian tinggi. 4. **Sila tandakan ( ) SULIT (Mengandungi maklumat yang berdarjah keselamatan atau kepentingan Malaysia seperti yang termaktub di dalam AKTA RAHSIA RASMI 1972) TERHAD TIDAK TERHAD (Mengandungi maklumat TERHAD yang telah ditentukan oleh organisasi/badan di mana penyelidikkan dijalankan) Disahkan oleh (TANDATANGAN PENULIS) Alamat Tetap: LOT 2694, KG. TELUK RHU, SABAK BERNAM SELANGOR DARUL EHSAN (TANDATANGAN PENYELIA) PROF. DR NORSHEILA BT FISAL (Nama Penyelia) Tarikh : 29 NOVEMBER 2005_ Tarikh : 29 NOVEMBER 2005 CATATAN : * Potong yang tidak berkenaan. ** Jika tesis ini SULIT atau TERHAD, sila lampirkan surat daripada pihak berkuasa/organisasi berkenaan dengan menyatakan sekali sebab dan tempoh tesis ini perlu dikelaskan sebagai SULIT atau TERHAD. Tesis dimaksudkan sebagai tesis bagi Ijazah Doktor Falsafah dan Sarjana secara penyelidikan, atau disertasi bagi pengajian secara kerja khusus dan penyelidikan, atau Laporan projek Sarjana Muda (PSM).

2 I hereby, declare that I have read this thesis and in my opinion this thesis is sufficient in terms of scope and quality for the award of degree of Master of Engineering (Electrical-Electronic & Telecommunication) Signature : Name of Supervisor : PROF DR. NORSHEILA BINTI FISAL Date : 29 NOVEMBER 2005

3 EMBEDDED TCP/IP IN SENSOR NODES (SENSORNETS) WARSUZARINA BINTI MAT JUBADI A project report submitted in partial fulfilment of the requirements for the award of the degree of Master of Engineering (Electrical-Electronics & Telecommunications) Faculty of Electrical Engineering Universiti Teknologi Malaysia NOVEMBER, 2005

4 ii I declare that this thesis entitled Embedded TCP/IP in Sensor Nodes (sensornets) is the result of my own research except as cited in the references. The report has not been accepted for any degree and is not concurrently submitted in candidature of any other degree. Signature : Name : WARSUZARINA BINTI MAT JUBADI Date : 29 NOVEMBER 2005

5 iii To my beloved husband for his support and understanding To my little baby for not giving any problem To my dearest mother, father and family for their encouragement and blessing

6 iv ACKNOWLEDGEMENT First of all, I am greatly indebted to ALLAH SWT on His blessing to make this project successful. I would like to express my gratitude to honourable Professor Dr. Norsheila Bt. Fisal, my supervisor of Master s project. During the research, she inspired me with motivations, guidance, encouragement and assistance which finally led me to the completion of this project. A very big appreciation goes to Mr. David Armstrong; an active members in AVR-GCC mailing list, and also to Mr. Dennis Kuschel, the developer of my-cpu who guide and assist me without any doubt through the s. They have guided me a lot through the compiling of the embedded TCP/IP stack, the biggest part of this project. I would also dedicate my appreciation to my husband, my little baby, my parents and family, and my friends who helped me directly or indirectly help me in this project. I am grateful to Kolej Universiti Teknologi Tun Hussein Onn (KUiTTHO), for supporting me in the form of a scholarship and study leave. Guidance, co-operation and encouragement from all people above are appreciated by me in sincere.

7 v ABSTRACT A sensor network is a group of sensor nodes (sensor) which are connected and communicate each other. Sensor node has the ability to sense environmental data such as humidity, light, weight, and temperature, and has been ported with embedded TCP/IP protocol to perform the networking. A sensor node is equipped with a small microcontroller, a radio transceiver, and an energy source. Sensors are constrained in terms of memory and processing power because of their limited physical size and cost. These constraints have been considered too limiting for physical size sensor to be able to use the TCP/IP protocols. This project was carried out to develop two sensor nodes that able to sense the temperature value, to embed the TCP/IP stack into the sensor nodes, and to apply the SLIP protocol into the TCP/IP stack. One will be the transmitter node while the other is the receiver node. The programming was developed with WinAVR, an AVR-GCC development tools and the hex code was ported using AVRISP connector. Finally, the transmission of data between sensor nodes is measured and result is compared between wired and wireless data.

8 vi ABSTRAK Rangkaian pengesan ialah sekumpulan nod-nod pengesan (pengesan) yang saling berhubungan dan berkomunikasi antara satu sama lain. Nod pengesan mempunyai kebolehan untuk mengesan data daripada persekitaran seperti kelembapan, cahaya, berat dan suhu, dan ia juga dilengkapi dengan protokol TCP/IP terbenam untuk perangkaian. Setiap nod pengesan dilengkapi dengan mikro-pengawal yang kecil, gabungan pemancar dan penerima, dan satu sumber tenaga. Nod-nod pengesan ini terikat dari segi ingatan dan kuasa pemprosesan disebabkan oleh kos dan saiz fizikal yang terhad. Ciri-ciri ini telah dipertimbangkan amat terhad bagi saiz fizikal nod pengesan untuk berupaya menggunakan protokol TCP/IP. Projek ini telah untuk dijalankan untuk membangunkan dua modul nod pengesan yang berupaya untuk mengesan nilai suhu, untuk memprogramkan tindanan TCP/IP ke dalam nod pengesan dan mengaplikasikan protokol SLIP kedalam tindanan TCP/IP tersebut. Satu nod sebagai nod pemancar manakala satu lagi nod sebagai nod penerima. Pengaturcaraan dibangunkan dengan WinAVR, sebuah perkakasan pembangunan AVR-GCC dan kod perenambelasan diprogramkan melalui penghubung AVRISP. Akhir sekali, penghantaran data di antara nod-nod pengesan ditentukan dan keputusan di antara data dengan wayar dan tanpa wayar dibandingkan.

9 vii TABLE OF CONTENTS SUBJECT PAGE TITLE DECLARATION DEDICATION ACKNOWLEDGEMENT ABSTRACT ABSTRAK TABLE OF CONTENTS LIST OF TABLES LIST OF FIGURES LIST OF ABBREVIATIONS LIST OF APPENDICES i ii iii iv v vi vii x xi xiii xv CHAPTER 1 INTRODUCTION Overview Introduction to Sensor Network Problem Statement Objectives Scope of Project Thesis Outline 5

10 viii CHAPTER 2 SENSOR NODES ARCHITECTURE Introduction Sensor Node (Sensornets) Sensor Network Developments and Limitations Application Example Communication Method in Sensor Network Sensor Developments Embedded Operating Systems TCP/IP Overview The structure of TCP/IP Protocol in an 19 Operating System 2.10 Small TCP/IP Protocol Stack IP Address and Hostname Service Port and Socket Addressing Drivers, Layers and Stacks Physical Layer Link Layers SLIP & PPP Choosing a Protocol 29 CHAPTER 3 SENSOR NODES DEVELOPMENT Overview Hardware Development Processor Temperature Sensor RF Communication ISP Connector Software Development uip Code Modifications Temperature Sensing Flowchart Transmit and Receive Data Flowchart 47

11 ix 3.5 Code Compiler AVRGCC WinAVR 50 CHAPTER 4 SENSOR NODES VERIFICATION Overview Embedded Design Application Sensor Nodes ISP Connector Code Verification Serial Device Programmer Converting Data from Analog to Digital Form Temperature Derivation Measured Voltage Reset Voltage Temperature Voltage Data Transmission between Sensor Nodes 70 CHAPTER 5 CONCLUSION & SUGGESTION Conclusion Suggestion For Future Work 76 REFERENCES 78 APPENDIX A 82 APPENDIX B 85 APPENDIX C 108 APPENDIX D 112

12 x LIST OF TABLES NO TITLE PAGE 2.1 The Conceptual Organization of TCP/IP Protocol Code size for uip (AVR) and (x86) Functions of ISP Connector Pin Header Comparing Fuses in AT90S8535 and Atmega

13 xi LIST OF FIGURES FIGURE NUMBER TITLE PAGE 1.1 Sensor Network Structure Structure of Sensor Node Broadcast Mechanism Structure of Node Application Example of uip code size Interfacing uip Sensor Network with Proxy Sensor Network with DTN-Gateway Sensor Network with TCP/IP Communications between Microcontrollers Sensor Node Proposed Design Block Diagram for Transmitter and Receiver Node Schematic Circuit of Transmitter Node Schematic Circuit of Receiver Node ATmega8535 Block Diagram LM335 Pin Configurations Schematic Circuit for Temperature sensor, LM RF transmitter and Receiver Circuit ISP Connector Flow of Software Development 43

14 xii 3.11 Embedded Software Development Process Flowchart for Temperature Sensing Flowchart of Transmitting Character String Flowchart of Receiving Character AVR-GCC Environment Window Programmer Notepad in WinAVR Communications between Microcontrollers Communications between Microcontroller and PC Transmitter Node Prototype Receiver Node Prototype RF Transmitter and Receiver Module ISP Cable Downloader Compiling Code using AVRGCC Error Status when Failure Occur ISP Cable Downloader Compiling Code using AVRGCC Compile and Link Code using WinAVR Memory Size Displayed After Code Compiled Porting Hex Code using PonyProg Measured Supply Voltages Measured Reset Voltage Voltage at Temperature 30 o C Voltage Level at Temperature 26 o C Voltage Level at Temperature 23oC Observed Data during Transmission Digital Data at Temperature 23oC Data During Transmission Process (wired) Data Transmitted from TxD pin Data Received at Receiver Module 74

15 xiii LIST OF ABBREVIATIONS ADC AM ARP AVR-GCC AVR RISC DHCP DNS DTN EEPROM FTP GPRS HTTP ICMP ISP KB LWIP LSB MHz MSB OS PPP RAM RF Analog to Digital Conversion Amplitude Modulation Address Resolution Protocol AVR- GNU Compiler Collection AVR Reduced Instruction Set Computer Dynamic Host Configuration Protocol Domain Name System Delay Tolerant Network Electrically Erasable Programmable Read Only Memory File Transfer Protocol Global Packet Radio Service HyperText Transfer Protoco Internet Control Message Protocol In-Circuit Serial Programmable Kilo Byte Light Weight Internet Protocol Least Significant Bit Megahertz Most Significant Bit Operating System Point-to-Point Protocol Random Access Memory Radio Frequency

16 xiv Rx SLIP SMTP SN SRAM TCP/IP Tx UDP USART Receiver Serial Line Interface Protocol Simple Mail Transport Protocol Sensor Network Static Random Access Memory Transmisson Control Protocol/ Internet Protocol Transmitter User Datagram Protocol Universal Synchronous Asynchronous Receiver Transmitter

17 xv LIST OF APPENDICES APPENDIX A : Transmitter and Receiver Node Source Codes 82 APPENDIX B : uip Modified Codes 85 APPENDIX C : AVRGCC Makefile for uip Stack 108 APPENDIX D : Serial Device Programmer (Ponyprog2000 Manual) 112

18 CHAPTER I INTRODUCTION 1.1 Overview Today, most network infrastructures use the Internet Protocol (IP) as its base technology. It is of particular interest to look how sensor networks can be connected to IP network infrastructures (TCP/IP) and methods to interconnect and embed TCP/IP protocol into the sensor device. By directly employ the TCP/IP suite as the communication protocol in the sensor network enable the integration of the sensor network and TCP/IP network. There have been a number of research and development efforts at all levels of development and usage of sensor networks, including applications, operating systems, architectures, middleware, integrated circuit, and system. Sensor network based on TCP/IP has the advantage of being able to directly communicate with an infrastructure consisting either of a wired IP network or of IP-based wireless technology.

19 2 1.2 Introduction to Sensor Networks A sensor network consists of many spatially distributed sensor nodes (sensors) which are used to monitor or detect phenomena at different locations, such as temperature changes or pollutant levels. Sensor networks enable information gathering, information processing, and reliable monitoring of a variety of environments for both civil and military applications. These sensor nodes can be spread out in hard accessible areas depends on the application fields. A sensor node combines the abilities to compute, communicate and sense [J.Bluementhal et al., 2002]. Figure 1.1 Sensor Network Structure Applications of sensor networks can be found in such diverse areas as wild-life habitat monitoring, forest fire detection, alarm systems, medicine, and monitoring of volcanic eruptions. Communication can be performed using medium such as wireless, optic or acoustic. For nodes with a far distance range from the source node to the destination, traffic is forwarded by other intermediate nodes.

20 3 The development of sensor nodes was influenced by the increasing of the device complexity, high performance of wireless networking technologies, combination of digital signal processing and sensor data acquisition, the advances in the development of micro-electromechanical systems (MEMS) and the availability of high performance development tools. [J.Blumenthal et al., 2002]: 1.3 Problem Statement This project was developed because of: i) Limited resources such as size of memory and processing power is said to be the limiting criteria for a sensor node to run the TCP/IP protocol. This project was run in an 8-bit processor with 8KB flash memory, 512 Bytes of SRAM to proof that porting TCP/IP stack is not a problem into the device itself. ii) uip is a small TCP/IP stack developed for small size microcontroller. Because of this, we tried to embed the uip into the AVR ATmega8535 which has the limited size of memory. iii) Data need to be transmitted and received at a specific time. We also need to work on specific device driver that used in the project. The project was carried out to see the performance of data transmission according to the time/period specified in the uip codes and device driver. (4) Normally IP works with Ethernet interface. In this project, the uip code has been modified to be used with SLIP protocol. We try to observe the transmission of data by using the RF transceiver and direct wire interface at the physical layer.

21 4 1.4 Objectives The objectives of this project are as follows: i) To develop sensor nodes that able to do sensing, processing and networking. Temperature data from a specific area is collected by one sensor node (defined as transmitter node) before it is transmitted to the other sensor node (defined as receiver node). ii) To embed the uip, a TCP/IP stack protocol into sensor nodes. This is done as to make sure the data can be transmitted and received at specific time. The IP address for each node and the periodic transmission of data is determined in the uip stack. iii) To develop sensor networking (between sensor nodes) using SLIP protocol. By using SLIP protocol, data can be transmitted more flexibly with wired or through the wireless link such as RF. 1.5 Scope of Project The scopes of work for this project are: Developing the sensor nodes which implemented TCP/IP protocol using: o Processor : AVR microcontroller o Sensor type: Temperature sensor o Communication link: direct wire, RF transmitter and receiver module

22 5 o Frequency involved: 433 MHz o TCP/IP Protocol: uip stack Programming the microcontroller using C/C++, and then compile the source codes using GNU tools, WinAVR (AVR-GCC). Convert the data collected by the analog temperature sensor into digital representation (A/D Conversion). Build the AVRISP connector to program the INTEL hex code into the AVR microcontroller. Write a device driver for target s network device in uip (serial), and configure the uip codes to be used in the sensor device. Embed uip, a TCP/IP functions into the sensor nodes. This is done to perform a networking between both sensor nodes. 1.6 Thesis Outline This thesis comprises of five chapters. The first chapter briefly overviews the background of sensor network and sensor nodes, objectives and scope of this project. Chapter 2 deals with the previous research and development of sensor nodes (a.k.a sensor) and its application in sensor networks. The design architecture,

23 6 development of sensors, and problem comprises in the development are presented in this chapter. This is followed by Chapter 3 which presents the software and hardware development for each of sensor nodes. This chapter described those resources used and the development steps of both transmitter and receiver node, such as hardware parts used, block diagram, and schematic circuits. In software development, AVR-GCC and its development tools is discussed. This tool is used to ease the microcontroller and application programming as it consists of cross-compiler, linker, object files, etc. Chapter 4 discusses the simulation results. Here, the ADC data for temperature value is analyzed. The performance of the data transmission between transmitter node and receiver node as seen in the oscilloscope for both wired and wireless is compared. For the comparison purposes, data observed at several temperature value has been captured and being analyzed. Finally, Chapter 5 summarizes the works undertaken. Recommendations for future work of this project are presented at the end of the chapter.

24 CHAPTER II SENSOR NODES ARCHITECTURE 2.1 Introduction Wireless sensor network is an information gathering paradigm based on the collective efforts of many small wireless sensor nodes. The sensor nodes were equipped with one or more sensors, a short-range radio transceiver, a small microcontroller, and a power supply [A.Dunkels et al., 2004]. With the success of the Internet, the TCP/IP protocol suite has become a global standard for communication. Therefore, it is interesting to connect the sensornets to TCP/IP networks. For an embedded system, being able to run TCP/IP suite makes it possible to connect the system directly to an intranet or internet [A.Dunkels, J.Alonso, T.Voigt, 2004]. Data transport in a TCP/IP sensor network is done using the two main transport protocols in the TCP/IP stack: the best-effort UDP and the reliable byte-stream TCP. This chapter reviewed the previous and recent works of sensor network and some of them were used in the sensor nodes development in this project.

25 8 J.Hill (2001) had discussed the new direction in wireless system design, extending wireless connectivity to small, low-cost embedded devices for a wide range of applications. The comparisons between conventional and current wireless design was also analyzed. Wider range of applications was introduced in the paper such as inventory asset tracking, roadside traffic pattern and open parking spot detection, individual plant monitoring for precision agriculture, habitat monitoring in nature preserves, and advanced building security and automation. 2.2 Sensor Nodes (Sensornets) A sensor application contains the readout of a sensor as well as the local storage of data. It has full access to the hardware and is able to access the operating system directly. The sensor application provides essential basic functions of the local sensor node, which may be used by the node application. The application field of sensor node was determined by the processor performance, transmission range, radio sensitivity, communication module, power consumption, weight and size [J. Blumenthal et al., 2002]. For examples, the processor performance could be compared in terms of the power consumption, memory size, fast re-programmability, A/D channels and operating supply voltage. A smart sensor network consists of a huge number of small sensors that spread across a geographical area. Each sensor has wireless communication capability and sufficient intelligence for signal processing and networking of the data (MANET, 1999). Sensor nodes development such as UCLA s WINS, Berkeley s Smart Dust, WebS and PicoRadio was a well-known research activity in the field of sensor networks (A.Dunkels et al, 2004).

26 9 Figure 2.1 Structure of Sensor Node A sensor node combines the abilities to compute, communicate and sense. The structure of sensor nodes discussed in [J. Blumenthal et al., 2002] was shown in Figure 2.1. For instance, the development of motes, mica motes, and Commercial-off-the-Shelf Dust (COTS Dust) can be differentiated between each other by the above criteria: processor, sensors chosen, and the communication module. At UC Berkeley, researches had developed small sensor devices called motes, and operating systems called TinyOS, which was especially running on them. 2.3 Sensor Network Developments and Limitations Sensor networks consist of a huge number of small sensor nodes, which communicate wirelessly. These sensor nodes can be spread out in hard accessible areas by what new applications fields can be pointed out. In most ad hoc sensor networks, some areas of the network have higher packet forwarding loads than other areas. For example, in a network where the nodes are uniformly distributed in space, the nodes near the center of the network will tend to carry a higher load when the network routing protocol prefers shortest-path routes.

27 10 Sensor networks based on TCP/IP have the advantage of being able to directly communicate with wired IP network or IP-based wireless technology [A.Dunkels, J.Alonso, T.Voigt, 2004]. Further research had been carried out such as extending the sensor networks into a wireless ad hoc network and analyzed the routing protocol and aggregation of the data. Sensor networks have to be self-organizing. A node has to autonomously set-up an operating network infrastructure by interaction with its neighboring nodes. Traditional wired networks are usually based on the client-server-principle. However, communication in sensor networks should be event-based. In large sensor networks, packets have to be routed from data sources to data sinks over intermediate nodes. That means, besides the measurement task, all nodes had to perform additional tasks to maintain network integrity [J. Blumenthal et al., 2002]. The cooperative processing of tasks should lead to more precise results and new application fields. Sensor networks required security mechanisms that were adaptive to environmental conditions which depend on network application and environmental conditions. Furthermore, all algorithms and protocols must be energy optimized such as implemented the OS for sensor nodes with a low-power task-scheduling. Sensor networks are limited in external bandwidth, i.e. how much data can be delivered to an outside system by the sensor networks. In many cases the externally available bandwidth is a small fraction of the aggregate internal bandwidth [S.Madden et al., 2001]. Thus computing aggregates in-network is also attractive from a network performance and longevity standpoint: extracting all data over all time from all sensors will consume large amounts of time and power as each individual sensor s data is independently routed through the network.

28 11 Unlike fixed wired networks, wireless sensor networks have many operational limitations. For example, the wireless link is constrained by transmission range and bandwidth, and the mobile nodes may be constrained by battery life, CPU, and memory. The mobility of the nodes and the fundamentally limited capacity of the wireless medium, together with wireless transmission effects such as attenuation, multi-path propagation, and interference, combine to create significant challenges for network protocols operating in an ad hoc network. 2.4 Application Examples Most sensor networks applications aim at monitoring or detection phenomena. Sensors can be connected to a mote (S.Hollar, 2000) that can monitor the condition of machinery temperature, number of revolutions, oil level, etc. and log it in the mote's memory. Then, when a truck drives by, the mote could transmit all the logged data. This would allow detailed maintenance records to be kept on machinery (for example, in an oil field), without maintenance personnel having to go measure all of those parameters themselves [A.Dunkels, 2002]. All of these ideas are good; some allow sensors to move into places where they have not been before (such as embedded in concrete) and others reduce the time needed to read sensors individually. However, much of the greatest excitement about motes comes from the idea of using large numbers of motes that communicate with each other and form ad hoc networks.

29 12 Some other examples include office building environment control, wildlife habitat monitoring, forest fire detection, and military sensor networks; to detect enemy movements or the presence of hazardous material such as poisons, chemical or gases. It could be applied in monitoring vehicle traffic on highway or in a congestion part of a city or in parking lot to determine occupied and free spots [A.Dunkels, 2001]. 2.5 Communication Method in Sensor Network In sensor network, signal is transmitted using broadcast mechanism. Two properties of radio communication need to be emphasized. First, radio is a broadcast medium, such that any sensor within hearing distance can hear any message, irrespective of whether or not it is the intended recipient. Second, radio links are typically symmetric: if sensor a 1 can hear sensor b 1, we assume that sensor b 1 also can hear sensor a 1 [S. Meguerdichian et al, 2001]. Figure 2.2 shows the diagram of how the communication is done by broadcasting the signals. a 1 b 1 Figure 2.2 Broadcast Mechanisms

30 13 For example on programming the RF motes in [J.Blumenthal et al., 2002], the implemented operating system was performed serially. While this method of programming is easier to implement than multi-tasking systems, only one process can be run at a time. There are also a number of technical challenges that are unique for wireless ad hoc sensor networks. For example, wireless ad hoc sensor networks pose a number of fundamental problems related to their deployment, location discovery, and tracking, among which, exposure has a special place and role. Previous studies have shown in [A.Dunkels et al, 2004] that aggregation reduces the amount of data routed through the network, increasing throughput and extending the life of battery powered sensor networks as less load is placed on power-hungry radios. 2.6 Sensor Developments A rapid development of sensor nodes has been run by groups of researcher. For example, the development of Smart Dust which refers to a next generation of sensing, processing and communication platforms. The objective of the work is to reduce the size of the platform to sub-cubic millimeter scale [S.Hollar, 2000]. The most common deep-embedded platform used in research is by far is the MOTE series originally developed at UCB. Several models of varying capabilities have been introduced, and various companies are producing the MOTEs commercially,

31 14 making them an easily obtainable testing platform. For example, WeC that was developed on 1998, followed by Rene (1999) and Rene2 (2000), Dot (2000), Mica (2001), Mica2Dot (2002), Mica2 (2002) and Telos on These different types of MOTE were developed with different capabilities. While the Berkeley MOTEs have during the past years become by far the most used deep-embedded research platform, numerous other designs have been documented in the literature. The Computer Systems and Telematics research group at Freie Universität Berlin (the Free University of Berlin) has developed a heterogeneous embedded platform collection called the Scatterweb. The European Smart-Its project [Smart-Its] developed a number of embedded platforms. For a example, ETH Zurich has developed various BTNodes platforms, latest of which are close relatives to the UCB Motes, using Bluetooth as the wireless interface, though. All of these platforms, including the UCB MOTEs seem to share the same design paradigm, being constructed of off-the-shelf components on a circuit board whose size is mainly dictated by that of the external connectors and batteries. 2.7 Embedded Operating Systems The purpose of an operating system, OS is to provide an interface to the underlying hardware and to schedule the available resources in the system. Many OS for networked embedded systems include a TCP/IP stack as well as a set of application layer protocols. Link level protocols such as PPP, SLIP and device drivers for often used networking hardware are also usually provided with the OS. OS for embedded

32 15 systems usually are designed for a specific application. This is different with the PC operating system, which is intended to run a wide variety of applications. Typically, embedded operating systems have all application programs hard-coded at compile time. The simplest embedded systems are usually built without an explicit OS. Such systems do not have behaviors that require complex mechanisms or real-time scheduling of concurrent tasks, and can therefore be implemented using a simple main loop. Dedicated networked embedded systems can usually be implemented without an operating system, but only with a stand-alone protocol stack. For example, many embedded TCP/IP stacks such as uip, lwip, and OpenTCP have the ability to run either with or without a supporting operating system. One example of a networked system that does not require an operating system could be a networked temperature controller that supplies temperature data over TCP/IP. The controller will only be running a single application and there is no need to have an operating system for dealing with multiple threads of control [A.Dunkels et al, 2004]. TinyOS is an operating system specially designed for the constraints and requirements of wireless sensor networks. It is currently the most widely used system for academic research in the area of sensor networks. The foremost feature of TinyOS is its small code size and memory usage, and its component model that lets the system designer specify the system dependencies at compile time [A.Dunkels et al, 2004]. The main drawback is the event-driven concurrency model which restricts applications to be implemented as explicit state machines. TinyOS is widely use in the wireless sensor networking research community, therefore implementations of various communication protocols for sensor network is available. There are, however, no TCP/IP stacks available for TinyOS.

33 16 Another example for a non-real time systems is Contiki. Contiki [A.Dunkels, 2004], is an operating system designed for networked and memory-constrained systems. Contiki is in many aspects similar to TinyOS, but has additional support for threads and dynamically loadable programs. Contiki includes the uip stack for TCP/IP communication. Contiki is based around an event-driven kernel but allows applications to be written in a multi-threaded fashion. Additionally, the lightweight stack-less thread-like construct in Contiki provides linear execution on top of the event-driven kernel. Some examples of embedded real-time systems are ecos, uc/os and uc/os-ii, XMK (extreme Minimal Kernel), OSE (Operating System Embedded), and VRTX (Virtual Real-Time executive). ecos is an open-source system designed to be highly configurable. It includes three different TCP/IP stacks that the developer can choose to use: a port of the OpenBSD TCP/IP stack, a port of the FreeBSD TCP/IP stack, and an adaptation of the lwip TCP/IP stack. uc/os-ii uc/os and its successor uc/os-ii are minimal real-time kernels. The source code for both systems is available from the author, but licensing from the author is required if the code is used in commercial projects [A.Dunkels et al., 2004]. There are a variety of TCP/IP stacks for uc/os, including the native uc/tcp-ip stack, and ports of the lwip and uip stacks. Another one is XMK (extreme Minimal Kernel) which is an open-source real-time kernel that is designed to fit very small microcontrollers, yet be scalable up to larger systems. 2.8 TCP/IP Overview From a high level viewpoint, the TCP/IP stack can be seen as a black box that takes incoming packets, and de-multiplex them between the currently active

34 17 connections. Before the data is delivered to the application, TCP sorts the packets so that they appear in the order they were sent. The TCP/IP stack will also send acknowledgments for the received packets [A.Dunkels, 2002]. The TCP/IP stack protocol is shown in Table 2.1 [Jones,M.Tim, 2002]. Table 2.1: The Conceptual Organization of TCP/IP protocol Conceptual Layer Examples Functions Application DHCP,FTP,WEB, User Data (messages/streams) User application Transport TCP,UDP Transport Protocol Packet, send a message Internet IP, PING, ARP Component parts, Connect, Data, handshake Link PPP,SLIP Customize for & talks to specific hardware Physical RS232, Ethernet The hardware chip so voltage, Frequency, signaling techniques. TCP provides a reliable byte stream to the upper layer protocols. It breaks the byte stream into appropriately sized segments and each segment is sent in its own IP packet. The IP packets are sent out on the network by the network device driver. If the destination is not on the physically connected network, the IP packet is forwarded onto another network by a router that is situated between the two networks. If the maximum packet size of the other network is smaller than the size of the IP packet, the packet is fragmented into smaller packets by the router. The final recipient of the packet will have to reassemble any fragmented IP packets before they can be passed to higher

35 18 layers. In this project, the IP packet was forwarded directly to the destination node without any intermediate routers (A.Dunkels, 2003). It is often assumed that TCP/IP is too heavy-weight to be feasible to implement on a small system such as a sensor node. It was shown in [A.Dunkels, 2001] that even a small system can run the full TCP/IP protocol stack. Figure 2.3 Structure of Node Application Figure 2.3 is the structure of node application discussed in [J. Blumenthal et al, 2002]. The OS-layer is separated into Node-Specific OS and a Driver Layer containts at least one Sensor Driver and several Hardware Driver, such as Timer Driver and RF Driver. The Node-Specific OS handles device-specific tasks e.g bootup, initialization of hardware and memory management.

36 The structure of TCP/IP Protocol in an Operating System Most TCP/IP software runs on the computers that use an operating system (OS) to manage resources, like peripheral devices. Operating systems provide support for concurrent processing. Even on machines with a single processor, multiple programs can be executed simultaneously by switching the CPU among them rapidly. In addition, OS manage main memory that contains executing programs, as well as secondary (nonvolatile) storage, where file systems reside. OS can be classified into Real-time and embedded OS [Jones, M. Tim, 2002]. TCP/IP software usually resides in the operating system, where all application programs running on the machine can share it. That is, the OS contains a single copy of the code for protocol like TCP, and multiple programs can invoke that code. Of course, each invocation must operate independently so that data transferred by one program does not affect the data transferred by another. Some examples of OS are Xinu, UNIX, and LINUX. Operating System such as TinyOS, wec, uip and LWIP have been determined as the embedded TCP/IP OS. For example, Tiny-OS that already provides an advanced framework for sensor networks. It is optimized in terms of memory usage and energy efficiency. Tiny-OS provides mechanisms (events and components) to statically define linking between layers. The predefinition of needed instances at compile time prevents from dynamical memory allocation at runtime. Tiny-OS supports the execution of multiple threads and provides a variety of additional extensions like the virtual machine Maté and the database TinyDB for cooperative data acquisition [A.Dunkels, J.Alonso, T.Voigt,2004].

37 Small TCP/IP Protocol Stack uip [A.Dunkels, 2002] have been developed as an implementation of the TCP/IP protocol stack, and intended for small 8-bit and 16-bit microcontrollers. uip implemented a fully functional TCP/IP stack with the limited resources available (as was discussed in earlier topics) to a micro controller. It provides the necessary protocols for Internet communication, with a very small code footprint and RAM requirements. The uip code size is on the order of a few kilobytes and RAM usage is on the order of a few hundred bytes. For instance, the code was compiled for the 32-bit Intel x86 and the 8-bit Atmel AVR platforms using gcc versions and 3.3 respectively, with code size optimization turned on [A.Dunkels, 2003]. Thus the resulting size of the compiled code can be seen in Tables 2.2. Table 2.2: Code size for uip (AVR) and (x86) Function Code Code size for uip Code size for uip (AVR) [Size: Bytes] (x86) [Size: Bytes] Checksumming IP, ICMP and TCP Total Figure 2.4 shows the code size and RAM usage for uip [A.Dunkels, 2002]. The uip code has been compiled for the 8-bit Atmel AVR architecture using gcc version 3.3 with the code size optimization turned on (-Os).

38 21 Figure 2.4 Example of uip Code Size Some features of uip includes [A.Dunkels, 2002] : provides ARP, SLIP, IP, UDP, ICMP (ping) and TCP protocols includes a set of example applications: web server, web client, sender (SMTP client), Telnet server, DNS hostname resolver. allow any number of concurrently active TCP connections, maximum amount configurable at compile time. allow any number of passively listening (server) TCP connections, maximum amount configurable at compile time. provides RFC compliant TCP and IP protocol implementations, including flow control, fragment reassembly and retransmission time-out estimation. Figure 2.5 shows the relation between uip, the underlying system and the application program. uip provides three functions to the underlying system, uip init(), uip input(), and uip periodic() [A.Dunkels, 2004]. The application must provide a callback function

39 22 to uip. The callback function is called when network or timer events occur. uip provides the application with a number of functions for interacting with the stack. Application UIP APPCALL( ) uip uip input( ) uip periodic( ) System Network Device Driver Periodic Time Figure 2.5 Interfacing uip The sections of code specific to individual AVR devices deal with the hardware timer used to generate periodic calls to uip, and the interface to the network device. Instead, uip used an event based programming model where the application is implemented as a C function that is called by uip in response to certain events. uip calls the application when data is received, when data has been successfully delivered to the other end of the connection, when a new connection has been set up, or when data has to be retransmitted. uip is different from other TCP/IP stacks in that it requires help from the application when doing retransmissions. Other TCP/IP stacks buffered the transmitted data in memory until the data is known to be successfully delivered to the remote end of the connection. If the data needs to be retransmitted, the stack takes care of the retransmission without notifying the application. With this approach, the data has to be

40 23 buffered in memory while waiting for an acknowledgment even if the application might be able to quickly regenerate the data if a retransmission has to be made. In order to reduce memory usage, uip utilizes the fact that the application may be able to regenerate sent data and lets the application take part in retransmissions (A.Dunkels, 2003). In (A.Dunkels et al., 2004), 3 different ways to connect sensor networks with TCP/IP networks had been discussed; a proxy architecture, DTN overlays and TCP/IP for sensor networks. Figure 2.6 shows the connection of sensor networks with proxy. Proxy architecture is a very simple and straightforward way to connect a sensor network and TCP/IP network. The proxy resides as a custom-made program running on a gateway computer which has access to both the sensor network and TCP/IP network. All interaction between client in the TCP/IP network and the sensor nodes is done through the proxy, the communication protocol used in the sensor network may be chosen freely. The advantage is that a proxy can operate as a relay or as a front-end. Best of all, proxy completely decouples the two networks. Figure 2.6 Sensor Network with Proxy Figure 2.7 shows the connection of sensor networks with DTN gateway. A DTN consist a set of regions which share a common layer called the bundle layer that resides above the transport layer. When connecting sensor networks to a TCP/IP using the DTN

41 24 architecture, at least 2 regions was developed as depicted in Figure 2.7: one TCP/IP region where the TCP/IP protocol suite is used and one sensor network region where specialized sensor network protocols are implemented. A DTN gateway node was placed between the two networks, similar to where a proxy would have been placed. The DTN architecture is much more general than a simple proxy based approach; however its architecture allows mapping the sensor network into more than one DTN region, with DTN gateways located within the sensor network. A fully DTN enabled sensor network would easily be extended to a TCP/IP network, simply by connecting one more of DTN gateways to the TCP/IP network. Figure 2.7 Sensor Network with DTN-Gateway By directly employing the TCP/IP protocol suite as the communication protocol in a sensor network, no special intermediary nodes or gateways is needed for connecting a sensor network with a TCP/IP network. Rather, the connection would simply be done by connecting one or more sensor nodes to the TCP/IP network as shown in Figure 2.8. TCP/IP in the sensor network would also provide the possibility route data to and from the sensor network over standard technologies such as GPRS.

42 25 Figure 2.8 Sensor Network with TCP/IP 2.11 IP Address and Hostnames In order for an application to exchange data with a remote process, it must have several pieces of information. The first is the IP address of the CPU that the remote program is running on. Although this address is internally represented by a 32-bit number, it is typically expressed in either dot-notation or by a logical name called a hostname. Each microcontroller needs to either be hard coded with an IP address in dot notation or be allocated an IP address and has no facilities for using hostnames. IP address for each of the sensor nodes was assigned in the TCP/IP stack itself. For a small application which only consists a small number of sensor nodes, Class A IP addressing can be used.

43 Service Port and Socket Addressing In addition to the IP address of the remote CPU, an application also needs to know how to address the specific program on the CPU that it wishes to communicate with. This is because large processors running TCP/IP will typically be multi-tasked and running a number of different links. This was accomplished by specifying a service port, a 16-bit number that uniquely identifies an application running on the CPU. The socket API had defined three types of sockets, which are Stream Sockets, Datagram Sockets and Raw Sockets [J.Martin, J.Leben, 1994]. Many of the socket system calls reference a pointer to a data structure containing information constituting a socket address. A socket address specifies one end of a communication link. Thus, the socket address of the application to be connected-to is required. Once a connection has been established to a socket in the addressee the applications programmer need only consider the data to be read/write. Like hostnames, service names were usually matched to port numbers through a local file. This file lists the logical service name, followed by the port number and protocol used by the Server. A number of standard service ports and names are used by Internet-based applications and these are referred to as well-known services. These services were defined by a standards document and include common application protocols such as FTP, POP3, SMTP and HTTP. Port numbers are reserved for well known services. Client port numbers are called ephemeral ports and values between 1024 and 5000 are usually used [Forouzan, Behrouz A., 2003] When setting up an application specific link (say a straight TCP link between a micro and a PC), avoid using the well-

44 27 known services range. A service name or port number is a way to address an application running on a remote host Drivers, Layers and Stacks The concept of a driver which can be defined t loosely as the combination of function calls and Interrupt Service Routers necessary to operate a piece of hardware at the message level. These functions (with a bit of documentation) allow someone unfamiliar with the details of the hardware to write application programs that will use the device. However, there is usually only one way to use a driver A stack is much more, as it must be a set of co-operating programs written to work together in many different combinations. Their underlying structure is provided by a commonly agreed set of protocols (or message standards) each level of the stack hiding the messy detail of the level below as we become more and more application oriented. The need for something more complex than a conventional driver also arises from the nature of communications networks in that we may have to sustain multiple interactions going on at the same time [Jones, M. Tim, 2002]. For instance, the developments of uip stack and its underlying structures which was clearly elaborated in the uip manual [A.Dunkels, 2002].

45 Physical Layer The most commonly used physical connection to a microprocessor is the RS232 serial connection. For long distances this is converted from its absolute voltage, bit signaling form to a voltage independent, frequency modulated form by a modem. For high speed connections between PC s the most common form of connection is 10Mbit Ethernet using CSMA/CD (Carrier Sense, Multiple Access with Collision Detection). All these are examples of different Physical Layers and their definitions include voltages, signaling mechanisms and timing details. Each different mechanism will have particular characteristics that require data to be specially formatted for it and this is done by the link layer. The link layer handles such problems as how to manage both Escape and Control characters that may perform functions as well as their binary equivalent as part of data [Forouzan, Behrouz A., 2003] Link Layers - SLIP & PPP SLIP stands for Serial Line Interface Protocol and is one of the simplest conventions for sending TCP/IP packages along a serial line. Typically, it was used on a low noise RS232 link between two fixed processors. Although the overhead added by SLIP is minimal, tt suffers from the following problems: each end assumes it knows the identity of the device at the other end. only a single conversation can go on at one time. there is no protection against data corruption at this level and it relies on

46 29 the levels above to detect transmission errors. PPP stands for Point to Point Protocol and is the link layer protocol most commonly used for TCP/IP package communications over modems. If we dial an ISP (Internet Service Provider) to link to the web or send our s, we are probably using PPP. PPP is superior to SLIP as its message structure contains a word (called the Frame Check Sequence or FCS.) that provides error detection. It also defines a number of options including a protocol for configuring and testing lines Choosing a Protocol Figure 2.9 Communications between Microcontrollers For the Micro to Micro link we can use the socket interface and the TCP protocol to ensure reliable communications between the micros over long distance serial links or faster short range Ethernet. If the application has facilities for device polling with good message handshakes we may choose to use UDP. Another application where UDP should be considered is voice or video over IP. UDP s lower overhead will improve throughput and the application does not have time to recover poor data but the human observer is good at ignoring occasional blips.

47 CHAPTER III SENSOR NODES DEVELOPMENT 3.1 Overview This chapter describes the sensor nodes development methodology and the discussion is started with hardware parts, software tools and the TCP/IP stack used to develop the sensor nodes architecture. The sensor nodes were designed with simplicity in mind; the goal was functional generic devices that would provide the sensing and networking ability. As was explained in previous chapter, a sensor network normally consist a large number of sensors. However for prototyping purposes, the sensor network development was carried out for only two nodes; the design of a transmitter and a receiver node. Thus, the data transmission will be verified between this sensor nodes.

48 Hardware Development Temperature sensors Sense/capture Data Data Processing Communication RF Transceiver Figure 3.1 Sensor Node Proposed Design A diagram of the proposed design architecture for a sensor node was presented in Figure 3.1. Sensors such as humidity, temperature, motion, acoustic, and lights sensors could be used for sensing purposes and interfaced to the processor. Each of the sensor nodes; transmitter and receiver node block diagram was designed as shown in the block diagram of Figure 3.2. An AVR microcontroller, ATmega8535 served as the brain of the system, a temperature sensor is used to capture data from surroundings, and the communication between both of the transmitter and receiver nodes was done through direct wire and RF module. Each of sensor nodes used a 5V lithium battery as an energy source. ATMEL AVR ISP Connector was built to allow the programming of AVR microcontroller chip through to the PC parallel port.

49 32 The components in sensor node development are as follow: AVR microcontroller ATmega8535: Analog Temperature sensor, LM335 Transmitter and Receiver circuit (optimal range 100m, MHz version, Data rates up to 2400 bps) A TCP/IP Protocol, uip stack in each sensor nodes ISP Connector PORTB PORTD RF transceiver AVR Microcontroller ATmega8535 Temperature Sensor PORTA Transmitter Node ISP Connector PORTB PORTD RF transceiver AVR Microcontroller ATmega8535 Receiver Node Figure 3.2 Block Diagram for Transmitter and Receiver Node

50 33 The block diagram in Figure 3.2 shows which ports/pins the parts should be connected to. For instance, in transmitter node, temperature sensor connected at PORTA, hex code is downloaded into the microcontroller through some pins in PORTB, and transmitter module attached at PORTD. The details of each input/output pin in every port, their configuration and settings however will be discussed in another topic. The following subtopics described the main components in the sensor nodes development. RESET SCK MISO MOSI Vcc Vcc U1 3.8K 3 SW1 10K C4 4.7uF C1 30pF X1 8MHz 0 C2 30pF PB0 (XCK/T0) PA0 (ADC0) 39 PB1/T1 PA1 (ADC1) 38 PB2(INT2/AIN0) PA2 (ADC2) 37 PB3 (OC0/AIN1) PA3(ADC3) 36 PB4(SS) PA4(ADC4) 35 PB5 (MOSI) PA5(ADC5) 34 PB6(MISO) PA6(ADC6) 33 PB7 (SCK) PA7(ADC7) RESET 32 AREF 31 AGND 30 VCC AVCC GND 29 XTAL1 PC7 (TOSC2) 28 XTAL2 PC6 (TOSC1) 27 PD0 (RXD) PC5 26 PD1 (TXD) PC4 25 PD2 (INT0) PC3 24 PD3 (INT1) PC2 23 PD4 (OC1B) PC1 (SDA) 22 PD5 (OC1A) PC0 (SCL) 21 PD6 (ICP1) PD7 (OC2) 2 1 LM335/TO92 Vcc U3 Vcc MOSI RESET SCK MISO J Vcc CON10AP TxD RxD ATmega8535 C3 100nF MOSI SCK PB0 PB3 1 2 SI SCK SO GND RESETVCC 5 CS WP MISO PB2 10k Transmitter Node 0 AT45DB011B 0 Figure 3.3 Schematic Circuit of Transmitter Node

51 34 Vcc VCC RESET SCK MISO MOSI U1 SW1 10K C4 4.7uF C1 30pF RxD X1 8MHz 0 C2 30pF PB0 (XCK/T0) PA0 (ADC0) PB1/T1 PA1 (ADC1) PB2(INT2/AIN0) PA2 (ADC2) PB3 (OC0/AIN1) PA3(ADC3) PB4(SS) PA4(ADC4) PB5 (MOSI) PA5(ADC5) PB6(MISO) PA6(ADC6) PB7 (SCK) PA7(ADC7) RESET VCC GND XTAL1 XTAL2 PD0 (RXD) PD1 (TXD) PD2 (INT0) PD3 (INT1) PD4 (OC1B) PD5 (OC1A) PD6 (ICP1) ATmega8535 AREF AGND AVCC PC7 (TOSC2) PC6 (TOSC1) PC5 PC4 PC3 PC2 PC1 (SDA) PC0 (SCL) PD7 (OC2) Vcc 100 C3 100nF MOSI SCK PB0 PB3 VCC MOSI RESET SCK MISO 1 2 U3 SI SCK SO GND AT45DB011B RESETVCC 5 CS WP J CON10AP MISO PB2 0 Vcc 10k 0 Receiver Node Figure 3.4 Schematic Circuit of Receiver Node Figure 3.3 and Figure 3.4 depicted the Schematic circuit of both transmitter and receiver nodes. Both of the sensor nodes used an 8 MHz crystal oscillator to generate the clocking for the ATmega8535. The microcontroller was powered by a 5 Volt supply voltage. The RF transmitter and receiver module was not shown in the schematic as we built the RF module in different PCB track. Purposely, this was done as the antenna of transmitter and receiver module should be kept away of any sources of electrical interference. The schematics of the RF modules will be presented in topic

52 Processor In a sensor network, power consumptions and bandwidth is very important. A sensor node was developed with a less consumed power processor. The processor was chosen based on the memory utilizations. For instance, a design of a big application such as taking continuous data, storing, and many processing items required a bigger memory for storing and buffering. The code size of the TCP/IP protocol implemented in the sensor nodes was also a major requirement for choosing the processor size. In Chapter 2, several types of processor that was used by previous researches in sensor nodes/network development had been discussed. This includes Microchip PIC, 8051(older version of AVR), 32-bit processor Strong Thumb and the latest is Rabbit An 8 bit AVR RISC micro-controller was used as the brain of the sensor device as referred in [S.Hollar, 2000]. ATMEL ATmega8535 had 8K bytes of In-System Programmable Flash with Read-While-Write capabilities, 512 bytes EEPROM, 512 bytes SRAM, 32 I/O lines, execution rate of one instruction per clock and can be attached to a PC ISA bus network. Figure 3.5 shows the ATmega8535 block diagram. The block diagram shows all the connection of I/O ports, AVR CPU, Timers, SPI, USART and memory. Furthermore the ADC in ATmega8535 supports differential and amplified measurements. ATmega8535 supports both left adjusted and right adjusted 10-bit results. ATmega8535 supports ADC conversion start on auto-triggering on interrupt sources. In this project, the AVR ATmega8535 was used to take analog data from temperature sensor and convert them into digital representation.

53 36 Figure 3.5 ATmega8535 Block Diagram

54 Temperature Sensor Temperature is one of most common real world characteristics that system needs to measure. An integral part of home automation systems centers around temperature sensing. Temperature sensors were used in measuring outside or inside air temperature, appliances or even a complex system such as power supply generator cabin during measuring the temperature of gases involved. This is why a temperature sensor had been taken into the proposed design as well as it is more convenient and suits the application. It is however necessary to convert these real world analog parameters into a digital form the software can operate on. In this project, a commonly utilized analog temperature sensor LM335 in TO-92 package, which are readily available to perform ADC was used. The LM335 operates from 40 C to This temperature sensor is an easy to use, cost-effective sensor with decent accuracy (around +/- 3 degrees C calibrated). It produced an output of 10mV per degree Kelvin. The sensor is essentially a zener diode whose reverse breakdown voltage was proportional to absolute temperature. The sensors high sensitivity allows it to be used with 10-bit or 12-bit analog. Figure 3.6 shows the pin configuration of LM335. Figure 3.6 LM335 Pin Configurations

55 38 The temperature sensor's voltage output is related to absolute temperature by the following equation: V out = V out T 0 * T / T 0 T 0 : the known reference temperature where V out T 0 was measured. The nominal V out T0 is equal to T0 * 10 mv/k. So, at 25 C, V out T0 is nominally 298 K * 10 mv/k = 2.98 V (to be really accurate, we'd need a reference temperature and a voltmeter, but nominal values are OK for this purposes). Thus, the voltage dropped between +5 and the diode is 5V V = 2.02V. In order to get 2 ma bias current, a 1 K resistor for R1 is used. As the LM335 functions as a zener diode, no load impedance is required. However, current limiting source impedance is required, performed by a resistor 3.8 KΩ to place the device in the proper operating mode. The schematic of the temperature sensor circuit is shown is Figure 3.7. This schematic shows how an LM335 was connected to operate appropriately. The resulting output of temperature voltage was directly fed to the analog to digital converter for measurement.

56 39 5V R1 3.8 Kohm A/D input to PORTA D1 2 LM335A/TO92 3 temperature input 1 Figure Schematic Circuit for Temperature sensor, LM RF Communication One of the basic assumptions of the sensor nodes is that it would communicate with one another wirelessly. Communication between the sensor nodes was done by transceiver module that can transmit and receive the data accordingly to the code programmed as defined in the uip stack. In this project, an RF transmitter and receiver module was used to allow the communication between these sensor nodes. Both transmitter and receiver module was intended for use in the 250MHz to 450MHz band. However, the circuit was constructed to run on frequency 433MHz. Data transmitted by the transmitter module can go as far as 100 meters while the receiver can receive data in 50 meters range. All receivers are compatible, producing a CMOS/TTL output, and require connections to power and

57 40 antenna only. The RF transmitter and receiver circuit for frequency 433 MHz is shown in Figure 3.8. E1 ANTENNA 1 Vcc JR IN DATA(RX) 0 250MHz ~ 450MHz RECEIVER Figure 3.8 RF transmitter and Receiver Circuit

58 ISP Connector After compiling the source program in C, the Intel HEX file can be downloaded into the chip directly. Atmel offers a software package called the Atmel AVR ISP which allows the programming of AVR microcontrollers in circuit with a simple dongle which is attached to the Parallel Port. The circuit diagram of the ISP (In System Programmable) cable is shown in Figure 3.0. It is cheap and was built easily, thus making it an ideal starting point for developing with ATMEL AVR micros. Figure 3.9 ISP Connector The ISP has only four signals to be implemented, which are MOSI, MISO, SCK and RESET. An LED indicator to detect the programmer on/off is an optional.

59 42 However, this LED indication was very useful during the chip programming. Normally, LED turned on at PC start up and during code is written into the chip. Otherwise, there might be some error occurred. Since there was no protection diode, thus ISP cable and the sensor node board must be connected carefully. The 10K resistor pulled pin 19 up to +5V to disable all outputs to float state when LPT1 was disconnected. The 74LS245, an octal tristate buffer was used as the main component, makes the operation is extremely simple. It was used to provide the float state after the hex code has been written into the AVR chip. The two loop-back connections, pin 2 to 12 and 3 and 11 is used to identify the ISP cable or so called as dongle. With both links in place the dongle is identified as a Value Added Pack Dongle. With only pins 2 and 12 links, it is reported as a STK300 or AVR ISP Dongle. With only 3 and 11, the dongle is reported as an STK200 or old Kanda ISP Dongle. 3.4 Software Development The code programming was written in C. Figure 3.10 shows the steps in designing the code programming. First, we had to configure which registers were used and setup specific pins for transmitting and receiving the data. Then, we defined the flowcharts for sensor nodes architecture. The flowchart was used to guide the writing program code. To ease the code programming, each of the flow chart has been created based on the application of sub modules, i.e. sensor, transmitter, and receiver. In this project, the temperature sensing code, data transmit and receive, and also the main loop in which we have to define the timer driver and the device driver were developed. This was done to ensure at a specific time, the data was transmitted and received accordingly.

60 43 After the source codes were developed, those codes needs to be verified and compiled. Some freeware compiler can be downloaded either from ATMEL distributor websites or others to compile the AVR. For examples, AVR-GCC which available in both DOS and Windows version from GNU Group, CodeVision AVR, WinAVR, AVRLib and many other available cross-compiler for AVR. In this project, the codes compilation were carried out using AVR-GCC (DOS version) and a window platform of AVRGCC, WinAVR as it can handled the compiling, debugging and created the hex code as well. Application s Flowchart Programming Code using C/C++ Setup Makefile Upload Code To target Device (PonyProg2000) Get Hex File Compile using WinAVR@ AVRGCC Figure 3.10 Flow of Software Development uip Code Modifications As for the TCP/IP stack, some modifications need was done to the TCP/IP codes. For details, refer to the uip manual in [A.Dunkels, 2001]. The source code of uip that was modified to implement this project is presented in Appendix B. Some important steps that were taken before the uip stack was implemented into each of sensor node are:

61 44 1) Write the device driver for the target's network device. In this case, it had been decided to use a serial driver, SLIP protocol. 2) Determine the actual system integration part (i.e., the main control loop, which should call the uip functions when data arrives and when the periodical timer expires). 3) Setup all the C source codes (compiler files) and header files. (eg: uipopt.h, uip.c, main.c) 4) Setup IP address of both transmitter and receiver nodes. The IP address was setup inside uipopt.h header file : (i) Transmitter , (ii) Receiver ) Setup the socket Port Number. Port number 4500 was selected as it was a Notes: Steps (4) and (5) depends on user applications. The C source code programming development process is shown in Figure This is more details and it lists all the process from creating the code using high-level language (in this case C), the cross-compiler and finally porting the executable file into the target system. For this purposes, the setup of Makefile of every source file is important because it determines the types of Linker, Loader and the object files to be produced.

62 45 Figure 3.11 Embedded Software Development Process

63 Temperature Sensing Flowchart The routine in Figure 3.12 was used to start an A/D conversion. The digital value will be stored in a buffer before any processing is done. The ADC was enabled by setting the ADC Enable bit, ADEN in ADCSRA. Voltage reference and input channel selections will not go into effect until ADEN was set. The comparator need to be set since an A/D conversion is run by comparing each data in every cycle. Timer or prescalar initialized for the ADC execution time. Enable ADC [ADEN] Set Comparator and/or interrupt Enable timer Set Control Pin Output Finish A/D initialization YES NO Finish A/D Conversion? Read Data from ADC Register : ADCH, ADCL Figure 3.12 Flowchart for Temperature Sensing (ADC)

64 47 The analog data input pin is determined by setting the control pin output. Since we set this as Single Conversion mode, always select the channel before starting the conversion. The ADC generates a 10-bit result which is presented in the ADC Data Registers, ADCH and ADCL. By default, the result is presented right adjusted, but can optionally be presented left adjusted by setting the ADLAR bit in ADMUX. We need to check if registers ready for the new data and A/D conversion cycle is finished. If yes, then only data will be buffered Transmit and Receive Data Flowchart In transmitting character string, all the registers involved was initialized. We might want to use the UART interrupt function. In Atmega8535, UART is known as USART. Figure 3.13 is the flowcharts of transmitting character string using the interrupt function. After initialize all register, we have to check if any string is being sent. If no, then USART is ready to send another character in the string. Else, go to next character in string. Check again if it is end of the string. If string has been sent, it will indicate that now USART is ready to send a new string. USART will then send another character in the new string.

65 48 Init variable No Is a string being sent? yes Go to next character in string No End of string? yes Indicate string has been sent Indicate USART ready to send Send next character in string Figure 3.13 Flowchart of Transmitting Character String Data had been received will be stored in the buffer. If USART is ready to send the data, an indicator will be activated. After data had been received, then only data will be read-out from the received buffer. Figure 3.14 is the flowchart for receiving the character string.

66 49 Receive Character Store receive data in buffer Data Received? USART ready to send Read from USART Data buffer Send Character Figure 3.14 Flowchart of Receiving Character 3.5 Code Compiler In developing and compiling the source code, several software that available for free download from the net can be used. The source code was written in C, thus Visual C++ or any other C programmer could be used. But in compiling the code, another compiler that is more convenient for AVR microcontroller was used to compile the code. The selection of software in compiling the code developed depends on the easiest way and without the need of circuit emulator from the vendor. To program the code into the chip, an alternative way such as an ISP connector can be implemented. The followings are the software that might be use as the code compiler as well.

67 AVRGCC An Avrgcc is software developed by GNU, which used to compile AVR. Figure 3.15 shows the AVR-GCC environment windows. It is a DOS-version Cross-Compiler. AVRlib was also included in Avrgcc. This file gives an overview of the C library functions implemented in the avr-libc standard library for the Atmel AVR microcontroller family. Compiling, linking and debugging have to be done by typing the command to create the object file, listing file, eeprom file and hex file. However, all the command was created inside the Makefile and this simplified the code compilation. Figure 3.15 AVR-GCC Environment Window WinAVR Figure 3.16 shows the Programmer Notepad window in WinAVR. In Figure 3.16, the source code is displayed at the back, while the front window shows the makefile setup for the source code. After that, the source code will be executed by hitting Make All command in the Tool menu. WinAVR is a suite of executable, open source software development tools for the ATMEL series of RISC microprocessor

68 51 hosted on the Windows platform. It includes the GNU GCC compiler for C and C++. So far, Win AVR supports only the DOS command-line platform. The user should familiar with DOS commands before using it. The user needs to study the Makefile and AVR-GCC program. WinAVR development tools includes Compilers, Assembler, Linker, Librarian, File converter, Other file utilities, C Library, Programmer software, Debugger, In- Circuit Emulator software, Editor / IDE, and many other support utilities. The compiler in WinAVR is the GNU Compiler Collection, or GCC. This compiler was incredibly flexible and can be hosted on many platforms; it can target many different processors / operating systems (back-ends), and can be configured for multiple different languages (front-ends).. This is ideal for calling the make utility, which executes user s Makefile, which in turn calls the compiler, linker, and other utilities used to build your software. PN will then capture the output and display it in a window. Any GCC warning or error can be clicked and PN will automatically open the file and go to the line where the warning or error occurred. Figure 3.16 Programmer Notepad in WinAVR

69 CHAPTER IV SENSOR NODES VERIFICATION 4.1 Overview This chapter discussed all the verifications of sensor nodes and the results obtained. The application code was successfully compiled using AVRGCC crosscompiler determined in Chapter 3. The result was obtained for both wired and wireless to ensure that data collected at receiver side is as same as what was transmitted. The result then analyzed in terms of how temperature data is converted into digital form, bits observed during transmit-receive process, voltage involved and the performance of data transmission using wired and wireless. Some theory on an embedded design, temperature derivation and an analog to digital conversion is also discussed to support the result.

70 Embedded Design Application A few examples where embedded systems might use these protocols are shown in the figures below. Using these examples, we can consider typical scenarios that will later be used to highlight the relevance of different features of the protocols. Figure 4.1 Communication between Microcontrollers Figure 4.1 shows the communication between microcontrollers. In these examples the application will run on a microprocessor or increasingly on multiple microprocessor configurations used either locally to share the load, or over longer distances to put intelligence close to sensors or actuators. Figure 4.2 Communication between Microcontroller and PC The other one is the communication between microcontroller and PC which was shown in Figure 4.2. There are two reasons why we may be looking at this:-

71 54 1) Where the micro performs data acquisition or control and the PC data processing - in which case the PC s presence may be a necessary part of the total system. 2) Where the PC may be used as a convenient terminal to support complex set-up or diagnostic capabilities without TCP/IP these PC s would typically run an RS232 terminal emulator to communicate with a custom built command line interpreter software module within the application. 4.3 Sensor Nodes Both transmitter and receiver node prototypes is shown in Figure 4.3 and Figure 4.4. Each node was powered by 9 Volt Lithium batteries. The power supply was connected to voltage regulator circuit to regulate the supply to 5 Volt. This is because ATmega8535 can only receive supply voltage from range 3.3 V to 6 Volt. When sensor nodes were connected to the power supply, indication LED was turned on. If this is not seen, it means that sensor node was not function appropriately due to failure of supplied voltage or the circuit connection itself. Firstly, the communication between the sensor nodes was tested using wired. This was done to compare the result between data collected with wired and wireless (with RF transceiver module). The result observed will be discussed in the next topic. Figure 4.3 Transmitter Node Prototype

72 55 Figure 4.4 Receiver Node Prototype The transmitter and receiver module is shown in Figure 4.5. The testing of data transmission was carried in two phases; first transmitter and receiver node was connected using wire/cable and then using the transmitter and receiver module. Both of these modules was built in separate PCB with the sensor node prototypes since the antenna should be kept as far away from sources of electrical interference as physically possible. The antenna hot end should be kept clear of any objects, especially any metal as this will restrict the efficiency of the antenna to receive power. Furthermore, it can be easily plugged or disconnected from the main PCB of sensor nodes. Figure 4.5 RF Transmitter and Receiver Module

73 ISP Connector Table 4.1 shows the functions of ATmega8535 pins that should be connected and its function description. MISO/MOSI pins are used for all the CPUs except Atmega103, which uses TXD/RXD pins instead. The ISP connector cable that was built is shown in Figure 4.6. During uploading the hex code from PonyProg2000 into the microcontroller, we can see that LED lights up. If there is no error occurs during transmission, a success status will be displayed in PonyProg2000 windows. Table 4.1: Functions of ISP Connector Pin Header Name Function Description MOSI Master Out Slave In RESET Target MCU Reset Data being transmitted to the part being programmed is sent on this pin Connect to target AVR. Target AVR is programmed while in Reset State SCK Shift Clock Serial Clock generated by the Programmer MISO Master In Slave Out Data received from the part being programmed is sent on this pin VCC ISP Power Power supply for the ISP. ISP header must supply power to the dongle GND Ground Common Grounf An error status of Figure 4.6 will appear on the PonyProg2000 window if there is failure of downloading the hex code or it cannot recognize the microcontroller. This normally happens when there was no voltage signal connected to the microcontroller or it doesn t recognize the connection between ISP connector and the microcontroller. If the program reports the message "Device not responding" means that user missed to connect the device to read, or the interface is not configured properly.

74 57 Figure 4.6 Error Status when Failure Occur Note that only the devices that support probing report this type of message, other device simply read all 0's of FF's (if the device is missed). The devices that support probing are the 24XX, the AVR and some PIC. In the case of AVR device selected, the program can report the message "Device locked" in case of the locked bits was programmed. Even some preproduction devices don't support auto probing. Since the ISP connector is connected to the PC Parallel Port, the connection must be done before the PC is turned on. The ISP Cable is shown in Figure 4.7 Figure 4.7 ISP Cable Downloader

75 Code Verification After the C source code had been developed, it has to be verified to make sure the code runs an appropriate function as was determined in previous chapter. In this project, the code programming for each of the sub-modules was verified using the cross-compiler from GNU which are AVRGCC and WinAVR as well. Figure 4.8 shows how the compilation was done using AVRGCC. The compiler will create certain files such as <filename>.eep, <filename>. Obj, <filename>.o and <filename>.hex. The netlist in hex file can be directly programmed into the chip by using ISP Cable. If there was an error occurs, it will be displayed in the window as well. Figure 4.8 Compiling Code using AVRGCC

76 59 Figure 4.9 Compile and Link Code using WinAVR The AVRGCC windows version was used as it is easier to write the code in C and it can directly compile the code. The compiler in WinAVR is the GNU Compiler Collection, or GCC. Figure 4.9 illustrated the source code was compiled and linked. This compiler was incredibly flexible and can be hosted on many platforms, it can target many different processors/ operating systems (back-ends), and can be configured for multiple different languages (front-ends). As can be seen in Figure 4.9, the source code was written in the programmer notepad. The output windows shows files created after the code was compiled and executed. If there were errors in the source code, the process exit code will display the error. The GCC included in WinAVR was targeted for the AVR processor, was built to execute on the Windows platform, and was configured to compile C, or C++. GCC compiles a high-level computer language into assembly, and that is all. It cannot work alone. GCC was coupled with another project, GNU Binutils, which provides the assembler, linker, librarian and more. Since GCC is just a "driver" program, it can automatically call the assembler and linker directly to build the final program.

77 60 GNU Binutils is a collection of binary utilities. This also includes the assembler, as. Binutils includes the linker, ld; the librarian or archiver, ar. There are many other programs included that provide various functionality. Binutils was configured for the AVR target and each of the programs is prefixed with the target name. There is one program that brings all of this together. This program is GNU make. The make program reads and interprets a makefile. A makefile is a text file that we write that lists and controls how something is made. It is most often used to control how software is made. The uip stack in this project was compiled using this DOS version. Refer to Figure 4.9 which shows the compiled Makefile. It can be seen that the AVRGCC automatically compiled all the files included in the uip file, do the linking of uip, creating the load file for flash and EEPROM (hex file), extended listing as well as the symbol file. One advantage of this cross-compiler was that it creates the hex code which includes all the files in uip stack into one hex file. User just needed to define the file name of the hex code to be created, i.e uipslip file for this project. This hex code will be downloaded into the microcontroller. On the other hand, code developers don t need to write every single line of the command to do the compiling and linking. Finally, the memory size of each of the compiled code and its address was verified.

78 61 Figure 4.9 Memory Size Display After Code Compiled 4.7 Serial Device Programmer In Chapter 3, the used of PonyProg2000 as the Serial Device Programmer for target microcontroller had been elaborated. Firstly, the interface for serial or parallel connector had to be setup, calibrate the bus timing, define what type of AVR to be used and setup the configuration and security bits as well. This dialog was especially useful for microcontrollers, because they could not work at all without set these bits in a correct way. The ATmega8535 has two operating modes selected through the fuse settings. The S8515C Fuse selects whether the AT90S8535 compatibility mode should be used or not. By default, the S8515C Fuse is unprogrammed and the ATmega8535 does not operate in compatibility mode.

79 62 Table 4.2: Comparing Fuses in AT90S8535 and ATmega8535 After all calibration and setting is done, the hex file to be downloaded into the microcontroller. The hex code will be displayed in the PonyProg2000 window. Hence, the memory location of each of the hex code also displayed before code being programmed into the flash memory or EEPROM. In Serial Programmer Device window shows in Figure 4.11, a dialog box will popup after the hex code was successfully verified. If the verification was failed, there must be problem occurs during the setup and one need to reconfigure the setting or check the connection.

80 63 Figure 4.10 Porting Hex Code using PonyProg Converting Data from Analog to Digital Form The analog to digital conversion which was performed on the input voltage yield a digital number which depends on two variables. First, the size (number of bits) of the converter will dictate how large the resulting digital number will be. Typical converters can be 8 bits, 10 bits or 12 bits, and will yield maximum "counts" of 255, 1023 or 4095 respectively. This means that for an input voltage of 0 volts, any of the converters l yield a "count" of 0. But for an input voltage equal to the maximum allowable for the converter, the values of 255, 1023 or 4095 will be returned. Any voltage in between these limits will be represented by the converter as a fraction of the maximum number in the same proportion as the input voltage is to its maximum. In this project, a 10 bits converter was used, so the maximum value will be 1023.

81 64 The maximum allowable count and maximum allowable voltage were very important parameters in the use of the analog to digital converters. The maximum allowable count can be calculated easily from the number of bits available for the unit being used by using the formula: Maximum count = 2 no of bits - 1 and the total number of counts or steps available is: total count = 2 no of bits since the value of 0 is a valid count or step. The maximum input voltage range must be taken from the manufacturers specifications. 4.8 Temperature Derivation The converter allows a translation of analog voltages into meaningful digital information. But in order for the digital information to be truly meaningful for temperatures, the relationship between temperature and input voltage had to be understood. When configured and biased properly, the temperature sensors had an output voltage which was directly proportional to absolute temperature. This relationship is 10mv per degree Kelvin, meaning that at a temperature of absolute 0, the output voltage will be 0, at a temperature of absolute 0 plus 1 degree ( which is 1 degree Kelvin), the output voltage will be 10mv (.010 volts), etc. Since this relationship was a linear value, any given output temperature can be calculated. Taking the voltage and dividing it by.010 will give us the temperature readings in Kelvin. Some further mathematics required to turn that number degree Celsius. Kelvin reading was turned into Celsius by simply subtracted 273 from the above calculation, since 273 degrees Kelvin is the freezing point of water, or 0 degrees

82 65 Celsius. So, if the input voltage is 2.73 volts, the temperature of the sensor is 0 degrees Celsius. 4.9 Measured Voltage Figure 4.12 shows the observed supply voltage, V CC which was connected to the AVR microcontroller. The supply voltage value was measured to see if it was stable or not. During the testing, a DC power supply unit was used in which we can vary the value more easily. Furthermore, it supplied a regulated voltage to the circuit which was very sensitive to the voltage range. Figure 4.12 Measured Supply Voltages

83 Reset Voltage The AVR controller used an external RESET button. This was done to ensure the RESET pin is working and to confirm the circuit can be reset at anytime it is required to do so. Figure 4.13 shows the measured Reset voltage at initial startup. As the RESET button was pushed, voltage dropped to 0 volt then going up to 5 volt again in the scope. Reset voltage should give the same value as the supply voltage. If this stage was not working, the connection in between microcontroller and the RESET circuit has to be checked. It could be happen the Reset voltage measured less than 5 Volt (in range 2.5V 3V) and sometimes no voltage at all (0 Volt). This shows that the RESET circuit was not working appropriately. After the Reset voltage was measured, thus the temperature voltage could be measured. This will be discussed in the next topic. Figure 4.13 Measured Reset Voltage

84 Temperature Voltage In previous chapter, built the analog temperature circuit was developed using LM335. This circuit then connected to the ATmega8535 at pin5 of PORT A. The analog input channel and differential gain were selected by writing to the MUX bits in ADMUX. It had been defined the MUX bit as bit 5 of PORT A. The ADC converts an analog input voltage to a 10-bit result which was presented in the ADC Data Registers ADCH and ADCL. Since the ADLAR in ADMUX register has been set to 0, so this gives a right adjusted value. Hence, ADCL was read first, and then ADCH, to ensure that the content of the data registers belongs to the same conversion. Here, several value of temperature voltage have been measured and to be compared with the actual voltage and calculation value. For instance, voltage was measured at temperature 30 o C, 26 o C and 23 o C. This was done to see the changes in A/D data and data being transmitted during transmit-receive process. Figure 4.14 shows the measured temperature voltage at 30 o C. This value was then converted into digital form before sent through wired or wireless. From the measurements, the collected value was compared with the calculation value. Figure 4.14 Voltage at Temperature 30 o C

85 68 The voltage as seen in the scope was Volt. From calculation shown in previous section, Volt was divided by This will give a value of Kelvin. As the value was converted into Celsius: Voltage measured from scope = Volt From Calculation : 3.043/.010 = Convert into Celsius : Kelvin = 31.3 o C Actual Voltage : 30 o C Figure 4.15 Voltage Level for Temperature 26 o C At temperature 26 o C, the voltage was measured at Volt. The voltage level was shown in Figure From here, the voltage then divided with and thus gives Kelvin. This value then converted into degree Celsius by subtracting 273 or 2.73 volts from the reading. Thus, the theoretical value is 26.8 o C. There was a slight difference between measured and the actual temperature. This was happen maybe due to the temperature derivation and sensor s sensitivity.

86 69 Voltage measured from scope = Volt From Calculation : 2.998/.010 = Convert value into Celsius : Kelvin = 26.8 o C Actual temperature : 26 o C Figure 4.16 Voltage Level at Temperature 23 o C Another measurement was done at the temperature 23 o C. In Figure 4.16, the average value which of Volt has been taken. This value then divided by and gives Kelvin. By substituting 273 K from the measured value, the temperature will be 23.2 o C. The calculation is shown as follow: Actual Temperature : 23 o C Voltage measured : V Calculation : 2.962/.010 = Convert into Celsius : = 23.2 o C Difference : 23.2 o C o C = 0.2 o C

87 70 The difference of actual and measurement value however does not affect the digital data to be transmitted. Furthermore, there was only a slight difference between both values and it was not affected the A/D conversion of its value. This was because each of these analog data will be converted into digital format by using ADC and its approximate value of ATmega Data Transmission between Sensor Nodes The result will be elaborated in this section; which are analog data that has been converted into the digital form. Since it is a digital data transmission between two sensor nodes, frame format and data rate is important. In previous chapter, it was defined that the data transmission used the USART, with 8 bit frame format, Big Endian byte order and baud rate of 9600 bps. Hence, data rate between transmitter and receiver node must be synchronized in order to handle the data transmission correctly. An essential criterion for determining the capacity of communication lines is the data rate, i.e. the speed at which the data can be transmitted. The data rate is characterized by the number of bits transmitted each second, measured in bps, bits per second. As data rates are extremely high nowadays, such units as kilobit per second (kbit/s) and megabit per second (Mbit/s) are not unusual. To measure the switching speed, i.e. the number of voltage or frequency changes per unit of time, the so-called Baud rate is used. When only one bit is transmitted per transmission unit, the Baud rate [Baud] is identical to the data rate bit per second (bps). All the collected data transmit and received is analyzed to check the Baud rate with defined value, 9600 bps.

88 71 Figure 4.17 Observed Data during Transmission Figure 4.17 shows the observed data during transmission. This data was collected at transmitter pin, TxD of PORT D. A continuous bit pattern of 0 and 1 can be seen according to the temperature measured. Data was sent out using 8 bit frame format, 1 stop bit and no parity bit attached to the bit frame. The bits shifting operation was analyzed according to Big Endian Byte order. Bits in MSB will be shifted first and then followed by the LSB Byte. The Baud rate was measured by dividing the number of bits with the time/sec thus gives a maximum value of 2400 bps. Actual Baud rate can be less than 9600 bps due to the error that occur in Baud rate setting for ATmega8535. At temperature 23 o C, the result in Figure 4.18 was observed when the TxD pin of PORT D was connected to the scope. At the receiver side, the same data as being transmitted should be received by the transmitter node. Data will be transmitted according to the Big Endian byte, thus a bit pattern of 025D or can be seen.

89 72 Figure 4.18 Digital Data at Temperature 23 o C Further analysis on how the bit is shifted is discussed here. If both transmitter and receiver pin were connected to the scope, the result as in Figure 4.19 was observed. The analysis was started by directly connect both nodes with wired. The A/D conversion gives a 10 bits value of Since the readings was taken from both ADC registers; ADCH and ADCL, this gives a 16 bit sequence of the original data and six 0 values append at the MSB value. The result consists of a start bit, a stop bit and the original data was defined in the frame format. The bits were shifted out serially starting with the start bit of 0 as USART data transmission was defined in the source codes. This was followed by the MSB and then the stop bit. For next bit frame, it started with 0 which is the start bit and followed by the least significant value in the sequence. This proofs that the data was transmitted according to the Big Endian format.

90 73 Stop Bit Start Bit Start Bit Stop Bit Bit sequ ence Bit sequ ence Data : Figure 4.19 Data during Transmission Process (wired) After several testing was carried out with direct wire connection, the result for the wireless connection for the sensor nodes is presented in Figure 4.20 and Figure 4.21 respectively. This shows that the data observed at the receiver side of sensor nodes. From here, the same bit sequence as being transmitted was observed and the bits were shifted into the RxD pin of the receiver node. Start Bit Stop Bit Start Bit Bit sequ ence Figure 4.20 Data Transmitted from TxD pin

91 74 Start Bit Stop Bit Stop Bit Start Bit Figure 4.21 Data Received at Receiver Module A slight difference that occur between the measurements and actual result was because of the A/D conversion depends on the AVCC, AGND and AREF pin in order to get a dynamic range of data. During networking of sensor node, only the electrical signal at the transmitter/receiver pin can be observed, but not the actual data. Data received by the receiver node influence by the TX and RX module. Error can occur due to ADC of the temperature data, and the antenna build for both TX and RX module (noise), or length of cable (if wired). The lower the frequency, the higher the noise and error could occur. As the addresses for both transmitter ad receiver nodes had been determined, the data can only be received by receiver node when the connection has been made. Data can only be seen in the scope if when the same socket address is used. Otherwise, data transmitted by transmitter node cannot be received at the receiver side.

92 CHAPTER V CONCLUSION AND SUGGESTION 5.1 Conclusion Implementing a TCP/IP protocol into the small architecture of an embedded system was said to be a hard task. This is due to many constraints and limited resources such as power consumption, energy efficiency, available memory and buffering in the system that need to be considered. Furthermore, many researchers had assumed that TCP/IP is not possible to run in sensor network due to the restricted resources. Furthermore, it was not an easy task to develop the software for the device driver and the main control loop of the system. In this thesis, the development of sensor nodes for both transmitter and receiver part has been presented. Although the development of sensor nodes was done using a small memory size of 8KB, the sensor nodes that can do sensing, processing and networking using TCP/IP protocol have been successfully developed.

93 76 The uip stack was embedded into both sensor nodes to establish the networking. The source code for each of the sensor nodes was written in C. These codes were combined with the uip stack to perform the transmission of data at a periodic time. The IP address and the application port for both transmitter and receiver nodes was reconfigured to matched the sensor nodes prototypes. A SLIP device driver to handle the data at Link Layer and the main control loop to match the application were also developed. All of these codes were successfully programmed into the original version of uip stack and was compiled using AVRGCC Cross-compiler. The verifications of the sensor nodes data transmission was carried out for both wired and wireless connection. The result was also obtained for both transmissions with/without the embedded uip. Networking without uip has been verified using USART data transmission. As elaborated and observed in previous chapter, the data transmission between the sensor nodes was correctly operated as developed in the programming sections. 5.2 Suggestion for Future Work The work carried out in this project emphasized on the development of a sensor node itself, which constraint on sensing the temperature data, porting the uip stack into the sensor node and testing the data transmission as well. During the testing, no further measurement was done to configure the delay, routing protocol, and medium access. For future work, more sensor nodes should be further developed to represent a real sensor network test-bed, and it can be used for educational learning purposes. Several sensor types such as light, humidity, position, pressure can be combined to sense the data from surroundings, depends on the sensor network application.

94 77 Although the performance of data transmission for wired and wireless at frequency of MHz is observed, this project can be upgraded using higher frequency such as Zig-Bee frequency of 2.4GHz and above. Lastly, this project should be developed with smaller size, lower cost, but can be used in wider application and functions since the development was carried out without much constraint on the physical size and cost.

95 REFERENCES 1. Jones, M. Tim (2002). TCP/IP Application Layer Protocols for Embedded Systems. Charles River Media, Inc. 2. A. Dunkels (May 2003). Full TCP/IP for 8-bit architectures. In MOBISYS`03, San Francisco, California. URL: 3. A. Dunkels (January 2002). uip A Free Small TCP/IP Stack. Technical paper. 4. S. Hollar (2000). COTS Dust. Master Thesis, University of California, Berkeley. 5. A.Dunkels, J.Alonso, T.Voigt (2004). Making TCP/IP Viable for Wireless Sensor Networks. EWSN. 6. A.Dunkels, B.Grönvall, M.Johansson, K.Mayer, F.Oldewurtel, O.Raivio, J.Riihijärvi (2004). Reconfigurable Ubiquitous Networked Embedded Systems. Sixth Framework Programme Priority 2 Information Society Technologies. 7. Dr. K.V.K.K. Prasad, V. Gupta, A. Dass, A. Verma, Dreamtech Software Team (2002). Programming for Embedded Systems: Cracking the Code. Wiley Publishing, Inc.

96 79 8. J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister (November 2000). System Architecture Directions for Networked Sensors. In Proceedings of the 9th International Conference on Architectural Support for Programming Languages and Operating Systems. 9. Forouzan, Behrouz A. with Sophia Chung Fegan (2003). TCP/IP Protocol Suite. 2nd Edition, McGraw-Hill Higher Education. 10. A. Dunkels, T. Voigt, J. Alonso, H. Ritter, and J. Schiller (February 2004). Connecting Wireless Sensornets with TCP/IP Networks. In WWIC D. Culler, D. Estrin and M. Srivastava (August 2004). Overview of Sensor Networks. IEEE Computer. Vol. 37. No. 8. Pp James Martin, Joe Leben (1994). TCP/IP Networking : Architecture, Administration and Programming. Prentice Hall. 13. Srisathapornphat, C.Jaikaeo, C.Chien (2000). Sensor Information Networking Architecture. Chung Shen International Workshops on Parallel Processing. Page C. L. Stephens (April 2002). TCP/IP - An Introduction for 8 & 16 bit Microcontroller Engineers. Computer Solution Ltd. Version Sohrabi, J. Gao, V. Ailawadhi, and G. J. Pottie (October 2000). Protocols for Self-Organization of a Wireless Sensor Network. IEEE Personal Comm. 16. S. Meguerdichian, F. Koushanfar, M. Potkonjak, M. Srivastava (April 2001). Coverage Problems in Wireless Add-Hoc Sensor Networks. Proceedings of IEEE INFOCOM. Vol. 3. Pp M. Tubaishat, S. Madria (2003). Sensor Network : An Overview. IEEE Potentials.

97 C. C. Yee and S. P. Kumar (August 2003). Sensor Networks: Evolution, Opportunities, and Challenges. IEEE Proceedings. Vol. 91. No. 8. pp A.Ahmed and M. R. Eskicioglu (June 2004). Current Researches on Sensor Networks. Technical Report TR-01-06/04. Telecommunication Research Labs, Winnipeg, Manitoba, Canada. 20. J. Agre and L. Clare (May 2000). An Integrated Architecture for Cooperative Sensing and Networks. Computer, vol. 33. pp Douglas E.Comer, David L.Stevens (1999). Internetworking with TCP/IP Vol II: Design, Implementation, and Internals. 3rd edition. Prentice Hall. 22. Gharavi, H. Kumar, S.P. (August 2003). Special issue on Sensor Networks and Applications. National Institute of Standards Technology (NIST); Proceedings of the IEEE. Vol 91. Page S.Kumar, F.Zhao, and D.Shepherd (March 2002). Special Issue on Collaborative Signal and Information Processing in Microsensor Networks. IEEE Signal Processing Mag. Vol. 19. Pp J. Blumenthal, M.Handy, F. Golatowski, M. Haase, D.Timmermann (2002). Wireless Sensor Networks New Challenges in Software Engineering. University of Rostock, Germany. 25. Nollet, T.Marescaux, D.Verkest, Jean-Yves Mignolet, S.Vernalde (June 2004). Memory and Network Optimization in Embedded Designs: Operating-System Controlled Network on Chip. Proceedings of the 41st annual conference on Design automation.

98 K. Chandran et al, (February 2001). A Feedback Based Scheme for Improving TCP Performance in Ad Hoc Networks. IEEE Personal Communication Systems (PCS) Magazine Special issue on Ad Hoc Networks. Volume 8. Pp Hong X.; Xu K.; Gerla M. (July/August 2002). Scalable Routing Protocols for Mobile Ad Hoc Networks. IEEE Network. 28. A. Hamidian (January 2003). A Study of Internet Connectivity for Mobile Ad Hoc Networks in NS 2. Master's thesis. 29. C. H. Yih and D. B. Johnson (March 2004). Exploiting MAC Layer Information in Higher Layer Protocols in Multihop Wireless Ad Hoc Networks. Proceedings of the 24th International Conference on Distributed Computing Systems (ICDCS 2004). Pp IEEE. 30. A. Dunkels, The uip TCP/IP Stack for Embedded Microcontroller. Web page. Visited URL: IETF MANET Working Group. Mobile Ad Hoc Networks (MANET) Charter. URL: H. Kipp. Embedded Ethernet Board. Web page. Visited URL: ATMEL corporation Website, URL: GNU groups, AVR-GCC mailing list, URL: A. Dunkels, The Contiki Operating System. Web page. Visited URL:

99 APPENDIX A TRANSMITTER AND RECEIVER NODE SOURCE CODES

100 82 ********************************************************************** Node : TRANSMITTER Code Program : Usart_tr.c Application : to transmit ADC value ********************************************************************** #include <avr/io.h> #define FOSC // Clock Speed #define BAUD 9600 #define UBRR (FOSC/((BAUD)*16l)-1) #define TX PD0 unsigned int x; unsigned int baudrate; void USART_Init(unsigned int baudrate) { /* Set baud rate */ UBRRH = (unsigned char)((ubrr)>>8); UBRRL = (unsigned char)(ubrr); /* Enable receiver and transmitter */ UCSRB = (1<<RXEN) (1<<TXEN); /* Set frame format: 8data, no parity, 1 stop bit */ UCSRC = (1<< URSEL) (1<< UCSZ1) (1<< UCSZ0); //to transmit 16 bits unsigned int USART_Transmit (void) { /* Wait for empty transmit buffer */ while (!(UCSRA & (1<<UDRE))) ; /* Start transmission */ UDR = ((x)>>8); // send most significan't byte /* Wait for empty transmit buffer */ while (!(UCSRA & (1<<UDRE)) ) ; /* Start transmission */ UDR = x; // send least significant byte Return UDR; int main () { USART_Init(baudrate); while(1) { USART_Transmit();; TX=USART_Transmit(); return 0; ********************************************************************* Program Code : Adc1.c A/D conversion ********************************************************************* #include<avr/io.h>

101 83 unsigned int ADCL_data, ADCH_data; int x = 0; int temp (void) { DDRA = 0x00; //set PORTA as input PORTA = 00; DDRB = 0xFF; // port B output DDRC = 0xFF; // Activate ADC with Prescaler 16 --> 1Mhz/16 = 62.5kHz ADCSRA = (1<<ADEN) (1<<ADPS1) (1<<ADPS0); ADMUX = _BV(REFS0); while(1) { ADMUX = _BV(REFS0) 5; // Select pin ADC5 using MUX ADCSRA = _BV(ADSC); //Start conversion while (ADCSRA & _BV(ADSC) ) { // wait until converstion completed //read low byte ADCL_data= (ADCL); //read the high byte ADCH_data= (ADCH); ADC = (ADCL) + (ADCH); // x = ADC; // get converted value //PORTC = ~x>>2; // output the higher 8 bits PORTD=ADCH_data; PORTC=ADCL_data; return x; *********************************************************************** Node : Receiver Node Program Code : Usart_Rx.c *********************************************************************** #include <avr/io.h> #include <stdio.h> #define FOSC // Clock Speed #define BAUD 9600 #define UBRR (FOSC/((BAUD)*16l)-1) unsigned int x; unsigned int baudrate; void USART_Init(unsigned int baudrate) { /* Set baud rate */ UBRRH = (unsigned char)((ubrr)>>8); UBRRL = (unsigned char)(ubrr); /* Enable receiver */

102 84 UCSRB = (1<<RXEN); /* Set frame format: 8data, 1 stop bit, parity none */ UCSRC = (1<< URSEL) (1<< UCSZ1) (1<< UCSZ0) ; unsigned char USART_RX(void) { /* Wait for data to be received */ while (!(UCSRA & (1<<RXC))) ; /* Get and return received data from buffer */ return UDR; int main () { DDRC = 0xFF; USART_Init(baudrate); while (1) { USART_RX(); PORTC=USART_RX(); /* display bit received at PORTC */ return 1;

103 APPENDIX B uip MODIFIED CODES

104 85 * Copyright (c) 2001, Adam Dunkels. All rights reserved. * Redistribution and use in source and binary forms, with or without modification, are permitted *provided that the following conditions are met: * 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the * following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and *the following disclaimer in the documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by Adam Dunkels. * 4. The name of the author may not be used to endorse or promote products derived from this software *without specific prior written permission. * This file is part of the uip TCP/IP stack. *********************************************************************** Filename : app.c This code applied in both transmitter & receiver node *********************************************************************** #include "app.h" void example1_init(void) { uip_listen(4500);; void example1_app(void) { if(uip_newdata() uip_rexmit()) { uip_send("ok\n", 3); ******************************************************************* Program code : app.h (Header file) This code applied in both transmitter & receiver node ******************************************************************** #ifndef _APP_H_ #define _APP_H_ /* UIP_APPSTATE_SIZE: The size of the application-specific state stored in the uip_conn structure. (not used, but has to at least be one) */ #define UIP_APPSTATE_SIZE 1 #include "uip.h" void example1_init(void); void example1_app(void); #define FS_STATISTICS 0 #define UIP_APPCALL example1_app #endif ********************************************************************* Program Code : main.c This code applied in both transmitter & receiver node ********************************************************************* #include "uip.h" #include "rs232dev.h" #include "adc1.h" #include <stdio.h> #include "compiler.h" #include <avr/io.h>

105 86 #define TIMER_PRESCALE 1024 #define F_CPU #define TIMERCOUNTER_PERIODIC_TIMEOUT (F_CPU / TIMER_PRESCALE / 2 / 256) static unsigned char timercounter; void inittimer(void) { TCCR0=0x07; TIMSK =_BV(TOIE0); timercounter = 0; #ifdef IMAGECRAFT #pragma interrupt_handler SIG_OVERFLOW0:iv_TIMER0_OVF #endif SIGNAL(SIG_OVERFLOW0) { timercounter++; int main(void) { u8_t i; u8_t *uip_appdata; *uip_appdata = temp(); rs232dev_init(); uip_init(); example1_init(); while(1) { uip_len = rs232dev_poll(); if(uip_len > 0) { uip_process(uip_data); if(uip_len > 0) { rs232dev_send(); for(i = 0; i < UIP_CONNS; ++i) { uip_periodic(i); if(uip_len > 0) { rs232dev_send(); return 0; ****************************************************************** Program code : rs232_tty.c File type : target device file. This code applied in both transmitter & receiver node ****************************************************************** TITLE: Keil C51 v7.00 port of Adam Dunkel's uip v0.9 º º REVISION: VER 0.0 º º REV.DATE: º º AUTHOR: Murray R. Van Luyn, º ******************************************************************

106 87 #ifndef TEST_APP_H #define TEST_APP_H #include "uip.h" #include "slipdev.h" #endif /* TEST_APP_H */ #include <string.h> #include <stdio.h> #include <stdlib.h> #include <ctype.h> #include "rs232dev.h" #include "uip.h" char indata[] = "\ b d \ 00 3c 9a 7d ba ea \ 58 be c \ a 6b 6c 6d 6e 6f \ C0 \ b d \ 00 3c 9a 7d ba ea \ 58 be c \ a 6b 6c 6d 6e 6f \ C0 \ b d \ 00 3c 9a 7d ba ea \ 58 be c \ a 6b 6c 6d 6e 6f \ C0 \ "; char *indataptr; #define SLIP_END 0300 #define SLIP_ESC 0333 #define SLIP_ESC_END 0334 #define SLIP_ESC_ESC 0335 u8_t getchar_hextty_findnext() { u8_t c; char v; while (*indataptr &&!isalnum((int) (*indataptr))) { indataptr++; if (*indataptr) { v = *indataptr++; else { exit(0); if ((v >= '0')&&(v <= '9')) c = v - '0'; else c = toupper(v) - 'A' + 10; return c; u8_t getchar_hextty() {

107 88 u8_t c; c = getchar_hextty_findnext(); c = (c << 4) + getchar_hextty_findnext(); return c; void putchar_hextty(u8_t c) { static int ctr = 0; printf("%.2x ", c); ctr++; if (ctr == 16) { ctr = 0; printf("\n"); #define SIO_RECV(c) c=getchar_hextty() #define SIO_POLL(c) (c=getchar_hextty()) #define SIO_SEND(c) putchar_hextty(c) #define MAX_SIZE UIP_BUFSIZE static u8_t slip_buf[max_size]; #if MAX_SIZE > 255 static u16_t len, tmplen; #else static u8_t len, tmplen; #endif /* MAX_SIZE > 255 */ /* */ * rs232dev_send(): Sends the packet in the uip_buf and uip_appdata buffers. The first 40 bytes of the packet (the IP and TCP headers) are read from the uip_buf buffer, and the following bytes (the application data) are read from the uip_appdata buffer. /* */ void rs232dev_send(void) { #if MAX_SIZE > 255 u16_t i; #else u8_t i; #endif /* MAX_SIZE > 255 */ u8_t *ptr; u8_t c; SIO_SEND(SLIP_END); ptr = uip_buf; for(i = 0; i < uip_len; ++i) { if(i == 40) { ptr = (u8_t *) uip_appdata; c = *ptr++; switch(c) { case SLIP_END: SIO_SEND(SLIP_ESC); SIO_SEND(SLIP_ESC_END); break; case SLIP_ESC: SIO_SEND(SLIP_ESC); SIO_SEND(SLIP_ESC_ESC); break; default:

108 89 SIO_SEND(c); break; SIO_SEND(SLIP_END); /* /* rs232dev_poll(): * Read all avaliable bytes from the RS232 interface into the slip_buf buffer. If no more bytes are available, it returns with 0 to indicate that no packet was immediately ready. When a full packet has been read into the buffer, the packet is copied into the uip_buf buffer and the length of the packet is returned. /* >*/ #if MAX_SIZE > 255 u16_t #else u8_t #endif /* MAX_SIZE > 255 */ rs232dev_poll(void) { u8_t c; static u8_t lastc; while(1) { SIO_POLL(c); switch(c) { case SLIP_ESC: lastc = c; break; case SLIP_END: lastc = c; /* End marker found, we copy our input buffer to the uip_buf buffer and return the size of the packet we copied. */ memcpy(uip_buf, slip_buf, len); tmplen = len; len = 0; return tmplen; default: if(lastc == SLIP_ESC) { lastc = c; /* Previous read byte was an escape byte, so this byte will be interpreted differently from others. */ switch(c) { case SLIP_ESC_END: c = SLIP_END; break; case SLIP_ESC_ESC: c = SLIP_ESC; break; else { lastc = c; slip_buf[len] = c; ++len; if(len > MAX_SIZE) { len = 0;

109 90 break; return 0; /* */ * rs232dev_init(): * Initializes the RS232 device and sets the parameters of the device. /* */ void rs232dev_init(void) { indataptr = indata; /* #ifndef RS232DEV_H #define RS232DEV_H #include "uip.h" void rs232dev_init(void); u8_t rs232dev_read(void); void rs232dev_send(void); #if UIP_BUFSIZE > 255 u16_t rs232dev_poll(void); #else u8_t rs232dev_poll(void); #endif /* UIP_BUFSIZE > 255 */ #endif /* RS232DEV_H */ ******************************************************************************************** This is a small implementation of the IP and TCP protocols (as well as some basic ICMP stuff). The implementation couples the IP, TCP and the application layers very tightly. To keep the size of the compiled code down, this code also features heavy usage of the goto statement. The principle is that we have a small buffer, called the uip_buf, in which the device driver puts an incoming packet. The TCP/IP stack parses the headers in the packet, and calls upon the application. If the remote host has sent data to the application, this data is present in the uip_buf and the application read the data from there. It is up to the application to put this data into a byte stream if needed. The application will not be fed with data that is out of sequence. If the application whishes to send data to the peer, it should put its data into the uip_buf, 40 bytes from the start of the buffer. The TCP/IP stack will calculate the checksums, and fill in the necessary header fields and finally send the packet back to the peer. */ #include "uip.h" /* #include "uipopt.h" */ #include "uip_arch.h" /* */ /* Variable definitions. */ u8_t uip_buf[uip_bufsize]; /* The packet buffer that contains incoming packets. */ volatile u8_t *uip_appdata; /* The uip_appdata pointer points to application data. */ #if UIP_BUFSIZE > 255 volatile u16_t uip_len; /* The uip_len is either 8 or 16 bits,depending on the maximum packet size. */ #else volatile u8_t uip_len; #endif /* UIP_BUFSIZE > 255 */

110 91 volatile u8_t uip_flags; /* The uip_flags variable is used for communication between the TCP/IP stack and the application program. */ struct uip_conn *uip_conn; /* uip_conn always points to the current connection. */ struct uip_conn uip_conns[uip_conns]; /* The uip_conns array holds all TCP connections. */ u16_t uip_listenports[uip_listenports]; /* The uip_listenports list all currently listning ports. */ static u16_t ipid; /* Ths ipid variable is an increasing number that is used for the IP ID field. */ static u8_t iss[4]; /* The iss variable is used for the TCP initial sequence number. */ #if UIP_ACTIVE_OPEN static u16_t lastport; /* Keeps track of the last port used for a new connection. */ #endif /* UIP_ACTIVE_OPEN */ /* Temporary variables. */ static u8_t c, opt; static u16_t tmpport; /* Structures and definitions. */ typedef struct { /* IP header. */ u8_t vhl, tos, len[2], ipid[2], ipoffset[2], ttl, proto; u16_t ipchksum; u16_t srcipaddr[2], destipaddr[2]; /* ICMP (echo) header. */ u8_t type, icode; u16_t icmpchksum; u16_t id, seqno; ipicmphdr; #define TCP_FIN 0x01 #define TCP_SYN 0x02 #define TCP_RST 0x04 #define TCP_PSH 0x08 #define TCP_ACK 0x10 #define TCP_URG 0x20 #define IP_PROTO_ICMP 1 #define IP_PROTO_TCP 6 #define ICMP_ECHO_REPLY 0 #define ICMP_ECHO 8 /* Macros. */ #define BUF ((uip_tcpip_hdr *)&uip_buf[uip_llh_len]) #define ICMPBUF ((ipicmphdr *)&uip_buf[uip_llh_len]) #if UIP_STATISTICS == 1 struct uip_stats uip_stat; #define UIP_STAT(s) s #else #define UIP_STAT(s) #endif /* UIP_STATISTICS == 1 */

111 92 #if UIP_LOGGING == 1 #define UIP_LOG(m) printf("%s\n", m) #else #define UIP_LOG(m) #endif /* UIP_LOGGING == 1 */ /* */ void uip_init(void) { for(c = 0; c < UIP_LISTENPORTS; ++c) { uip_listenports[c] = 0; for(c = 0; c < UIP_CONNS; ++c) { uip_conns[c].tcpstateflags = CLOSED; #if UIP_ACTIVE_OPEN lastport = 1024; #endif /* UIP_ACTIVE_OPEN */ /* */ #if UIP_ACTIVE_OPEN struct uip_conn * uip_connect(u16_t *ripaddr, u16_t rport) { struct uip_conn *conn; /* Find an unused local port. */ again: ++lastport; if(lastport >= 32000) { lastport = 4096; for(c = 0; c < UIP_CONNS; ++c) { if(uip_conns[c].tcpstateflags!= CLOSED && uip_conns[c].lport == lastport) goto again; for(c = 0; c < UIP_CONNS; ++c) { if(uip_conns[c].tcpstateflags == CLOSED) goto found_unused; for(c = 0; c < UIP_CONNS; ++c) { if(uip_conns[c].tcpstateflags == TIME_WAIT) goto found_unused; return (void *)0; found_unused: conn = &uip_conns[c]; conn->tcpstateflags = SYN_SENT UIP_OUTSTANDING; conn->snd_nxt[0] = conn->ack_nxt[0] = iss[0]; conn->snd_nxt[1] = conn->ack_nxt[1] = iss[1]; conn->snd_nxt[2] = conn->ack_nxt[2] = iss[2]; conn->snd_nxt[3] = conn->ack_nxt[3] = iss[3];

112 93 if(++conn->ack_nxt[3] == 0) { if(++conn->ack_nxt[2] == 0) { if(++conn->ack_nxt[1] == 0) { ++conn->ack_nxt[0]; conn->nrtx = 0; conn->timer = 1; /* Send the SYN next time around. */ conn->lport = htons(lastport); conn->rport = htons(rport); conn->ripaddr[0] = ripaddr[0]; conn->ripaddr[1] = ripaddr[1]; return conn; #endif /* UIP_ACTIVE_OPEN */ /* */ void uip_listen(u16_t port) { for(c = 0; c < UIP_LISTENPORTS; ++c) { if(uip_listenports[c] == 0) { uip_listenports[c] = htons(port); break; /* */ void uip_process(u8_t flag) { uip_appdata = &uip_buf[40 + UIP_LLH_LEN]; /* Check if we were invoked because of the perodic timer fireing. */ if(flag == UIP_TIMER) { /* Increase the initial sequence number. */ if(++iss[3] == 0) { if(++iss[2] == 0) { if(++iss[1] == 0) { ++iss[0]; uip_len = 0; if(uip_conn->tcpstateflags == TIME_WAIT uip_conn->tcpstateflags == FIN_WAIT_2) { ++(uip_conn->timer); if(uip_conn->timer == UIP_TIME_WAIT_TIMEOUT) { uip_conn->tcpstateflags = CLOSED; else if(uip_conn->tcpstateflags!= CLOSED) { /* If the connection has outstanding data, we increase the connection's timer and see if it has reached the RTO value in which case we retransmit. */ if(uip_conn->tcpstateflags & UIP_OUTSTANDING) { --(uip_conn->timer); if(uip_conn->timer == 0) { if(uip_conn->nrtx == UIP_MAXRTX) { uip_conn->tcpstateflags = CLOSED; /* We call UIP_APPCALL() with uip_flags set to UIP_TIMEDOUT to inform the application that the connection has timed out. */

113 94 uip_flags = UIP_TIMEDOUT; UIP_APPCALL(); /* We also send a reset packet to the remote host. */ BUF->flags = TCP_RST TCP_ACK; goto tcp_send_nodata; /* Exponential backoff. */ uip_conn->timer = UIP_RTO << (uip_conn->nrtx > 4? 4: uip_conn->nrtx); ++(uip_conn->nrtx); /* Ok, so we need to retransmit. We do this differently depending on which state we are in. In ESTABLISHED, we call upon the application so that it may prepare the data for the retransmit. In SYN_RCVD, we resend the SYNACK that we sent earlier and in LAST_ACK we have to retransmit our FINACK. */ UIP_STAT(++uip_stat.tcp.rexmit); switch(uip_conn->tcpstateflags & TS_MASK) { case SYN_RCVD: /* In the SYN_RCVD state, we should retransmit our SYNACK. */ goto tcp_send_synack; #if UIP_ACTIVE_OPEN case SYN_SENT: /* In the SYN_SENT state, we retransmit out SYN. */ BUF->flags = 0; goto tcp_send_syn; #endif /* UIP_ACTIVE_OPEN */ case ESTABLISHED: /* In the ESTABLISHED state, we call upon the application to do the actual retransmit after which we jump into the code for sending out the packet (the apprexmit label). */ uip_len = 0; uip_flags = UIP_REXMIT; UIP_APPCALL(); goto apprexmit; case FIN_WAIT_1: case CLOSING: case LAST_ACK: /* In all these states we should retransmit a FINACK. */ goto tcp_send_finack; else if((uip_conn->tcpstateflags & TS_MASK) == ESTABLISHED) { /* If there was no need for a retransmission, we poll the application for new data. */ uip_len = 0; uip_flags = UIP_POLL; UIP_APPCALL(); goto appsend; goto drop; /* This is where the input processing starts. */ UIP_STAT(++uip_stat.ip.recv); /* Check validity of the IP header. */

114 95 if(buf->vhl!= 0x45) { /* IP version and header length. */ UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.vhlerr); UIP_LOG("ip: invalid version or header length."); goto drop; /* Check the size of the packet. If the size reported to us in uip_len doesn't match the size reported in the IP header, there has been a transmission error and we drop the packet. */ #if UIP_BUFSIZE > 255 if(buf->len[0]!= ((uip_len - UIP_LLH_LEN) >> 8)) { UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.hblenerr); UIP_LOG("ip: invalid length, high byte."); /* IP length, high byte. */ goto drop; if(buf->len[1]!= ((uip_len - UIP_LLH_LEN) & 0xff)) { UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.lblenerr); UIP_LOG("ip: invalid length, low byte."); /* IP length, low byte. */ goto drop; #else if(buf->len[0]!= 0) { /* IP length, high byte. */ UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.hblenerr); UIP_LOG("ip: invalid length, high byte."); goto drop; if(buf->len[1]!= (uip_len - UIP_LLH_LEN)) { /* IP length, low byte. */ UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.lblenerr); UIP_LOG("ip: invalid length, low byte."); goto drop; #endif /* UIP_BUFSIZE > 255 */ if(buf->ipoffset[0] & 0x3f) { /* We don't allow IP fragments. */ UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.fragerr); UIP_LOG("ip: fragment dropped."); goto drop; /* Check if the packet is destined for our IP address. */ if(buf->destipaddr[0]!= htons(((u16_t)uip_ipaddr0 << 8) UIP_IPADDR1)) { UIP_STAT(++uip_stat.ip.drop); UIP_LOG("ip: packet not for us."); goto drop; if(buf->destipaddr[1]!= htons(((u16_t)uip_ipaddr2 << 8) UIP_IPADDR3)) { UIP_STAT(++uip_stat.ip.drop); UIP_LOG("ip: packet not for us."); goto drop; if(uip_ipchksum()!= 0xffff) { /* Compute and check the IP header checksum. */ UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.chkerr);

115 96 UIP_LOG("ip: bad checksum."); goto drop; if(buf->proto == IP_PROTO_TCP) /* Check for TCP packet. If so, jump to the tcp_input label. */ goto tcp_input; if(buf->proto!= IP_PROTO_ICMP) { /* We only allow ICMP packets from here. */ UIP_STAT(++uip_stat.ip.drop); UIP_STAT(++uip_stat.ip.protoerr); UIP_LOG("ip: neither tcp nor icmp."); goto drop; UIP_STAT(++uip_stat.icmp.recv); /* ICMP echo (i.e., ping) processing. This is simple, we only change the ICMP type from ECHO to ECHO_REPLY and adjust the ICMP checksum before we return the packet. */ if(icmpbuf->type!= ICMP_ECHO) { UIP_STAT(++uip_stat.icmp.drop); UIP_STAT(++uip_stat.icmp.typeerr); UIP_LOG("icmp: not icmp echo."); goto drop; ICMPBUF->type = ICMP_ECHO_REPLY; if(icmpbuf->icmpchksum >= htons(0xffff - (ICMP_ECHO << 8))) { ICMPBUF->icmpchksum += htons(icmp_echo << 8) + 1; else { ICMPBUF->icmpchksum += htons(icmp_echo << 8); /* Swap IP addresses. */ tmpport = BUF->destipaddr[0]; BUF->destipaddr[0] = BUF->srcipaddr[0]; BUF->srcipaddr[0] = tmpport; tmpport = BUF->destipaddr[1]; BUF->destipaddr[1] = BUF->srcipaddr[1]; BUF->srcipaddr[1] = tmpport; UIP_STAT(++uip_stat.icmp.sent); goto send; /* TCP input processing. */ tcp_input: UIP_STAT(++uip_stat.tcp.recv); if(uip_tcpchksum()!= 0xffff) { /* Compute and check the TCP checksum. */ UIP_STAT(++uip_stat.tcp.drop); UIP_STAT(++uip_stat.tcp.chkerr); UIP_LOG("tcp: bad checksum."); goto drop; /* Demultiplex this segment. */ /* First check any active connections. */ for(uip_conn = &uip_conns[0]; uip_conn < &uip_conns[uip_conns]; ++uip_conn) { if(uip_conn->tcpstateflags!= CLOSED && BUF->srcipaddr[0] == uip_conn->ripaddr[0] && BUF->srcipaddr[1] == uip_conn->ripaddr[1] &&

116 97 BUF->destport == uip_conn->lport && BUF->srcport == uip_conn->rport) goto found; /* If we didn't find and active connection that expected the packet, either this packet is an old duplicate, or this is a SYN packet destined for a connection in LISTEN. If the SYN flag isn't set, it is an old packet and we send a RST. */ if(buf->flags!= TCP_SYN) goto reset; tmpport = BUF->destport; /* Next, check listening connections. */ for(c = 0; c < UIP_LISTENPORTS && uip_listenports[c]!= 0; ++c) { if(tmpport == uip_listenports[c]) goto found_listen; /* No matching connection found, so we send a RST packet. */ UIP_STAT(++uip_stat.tcp.synrst); reset: /* We do not send resets in response to resets. */ if(buf->flags & TCP_RST) goto drop; UIP_STAT(++uip_stat.tcp.rst); BUF->flags = TCP_RST TCP_ACK; uip_len = 40; BUF->tcpoffset = 5 << 4; /* Flip the seqno and ackno fields in the TCP header. */ c = BUF->seqno[3]; BUF->seqno[3] = BUF->ackno[3]; BUF->ackno[3] = c; c = BUF->seqno[2]; BUF->seqno[2] = BUF->ackno[2]; BUF->ackno[2] = c; c = BUF->seqno[1]; BUF->seqno[1] = BUF->ackno[1]; BUF->ackno[1] = c; c = BUF->seqno[0]; BUF->seqno[0] = BUF->ackno[0]; BUF->ackno[0] = c; /* We also have to increase the sequence number we are acknowledging. If the least significant byte overflowed, we need to propagate the carry to the other bytes as well. */ if(++buf->ackno[3] == 0) { if(++buf->ackno[2] == 0) { if(++buf->ackno[1] == 0) { ++BUF->ackno[0]; /* Swap port numbers. */ tmpport = BUF->srcport; BUF->srcport = BUF->destport; BUF->destport = tmpport;

117 98 /* Swap IP addresses. */ tmpport = BUF->destipaddr[0]; BUF->destipaddr[0] = BUF->srcipaddr[0]; BUF->srcipaddr[0] = tmpport; tmpport = BUF->destipaddr[1]; BUF->destipaddr[1] = BUF->srcipaddr[1]; BUF->srcipaddr[1] = tmpport; /* And send out the RST packet! */ goto tcp_send_noconn; /* This label will be jumped to if we matched the incoming packet with a connection in LISTEN. In that case, we should create a new connection and send a SYNACK in return. */ found_listen: /* First we check if there are any connections avaliable. Unused connections are kept in the same table as used connections, but unused ones have the tcpstate set to CLOSED. */ for(c = 0; c < UIP_CONNS; ++c) { if(uip_conns[c].tcpstateflags == CLOSED) goto found_unused_connection; for(c = 0; c < UIP_CONNS; ++c) { if(uip_conns[c].tcpstateflags == TIME_WAIT) goto found_unused_connection; /* All connections are used already, we drop packet and hope that the remote end will retransmit the packet at a time when we have more spare connections. */ UIP_STAT(++uip_stat.tcp.syndrop); UIP_LOG("tcp: found no unused connections."); goto drop; /* This label will be jumped to if we have found an unused connection that we can use. */ found_unused_connection: uip_conn = &uip_conns[c]; /* Fill in the necessary fields for the new connection. */ uip_conn->timer = UIP_RTO; uip_conn->nrtx = 0; uip_conn->lport = BUF->destport; uip_conn->rport = BUF->srcport; uip_conn->ripaddr[0] = BUF->srcipaddr[0]; uip_conn->ripaddr[1] = BUF->srcipaddr[1]; uip_conn->tcpstateflags = SYN_RCVD UIP_OUTSTANDING; uip_conn->snd_nxt[0] = uip_conn->ack_nxt[0] = iss[0]; uip_conn->snd_nxt[1] = uip_conn->ack_nxt[1] = iss[1]; uip_conn->snd_nxt[2] = uip_conn->ack_nxt[2] = iss[2]; uip_conn->snd_nxt[3] = uip_conn->ack_nxt[3] = iss[3]; uip_add_ack_nxt(1); /* rcv_nxt should be the seqno from the incoming packet + 1. */ uip_conn->rcv_nxt[3] = BUF->seqno[3]; uip_conn->rcv_nxt[2] = BUF->seqno[2]; uip_conn->rcv_nxt[1] = BUF->seqno[1]; uip_conn->rcv_nxt[0] = BUF->seqno[0]; uip_add_rcv_nxt(1); /* Parse the TCP MSS option, if present. */ if((buf->tcpoffset & 0xf0) > 0x50) { for(c = 0; c < ((BUF->tcpoffset >> 4) - 5) << 2 ;) { opt = uip_buf[40 + UIP_LLH_LEN + c];

118 99 if(opt == 0x00) { /* End of options. */ break; else if(opt == 0x01) { ++c; /* NOP option. */ else if(opt == 0x02 && uip_buf[40 + UIP_LLH_LEN + c + 1] == 0x04) { /* An MSS option with the right option length. */ tmpport = (uip_buf[40 + UIP_LLH_LEN + c + 2] << 8) uip_buf[40 + UIP_LLH_LEN + c + 3]; uip_conn->mss = tmpport > UIP_TCP_MSS? UIP_TCP_MSS: tmpport; /* And we are done processing options. */ break; else { /* All other options have a length field, so that we easily can skip past them. */ c += uip_buf[40 + UIP_LLH_LEN + c + 1]; /* Our response will be a SYNACK. */ #if UIP_ACTIVE_OPEN tcp_send_synack: BUF->flags = TCP_ACK; tcp_send_syn: BUF->flags = TCP_SYN; #else /* UIP_ACTIVE_OPEN */ tcp_send_synack: BUF->flags = TCP_SYN TCP_ACK; #endif /* UIP_ACTIVE_OPEN */ /* We send out the TCP Maximum Segment Size option with our SYNACK. */ BUF->optdata[0] = 2; BUF->optdata[1] = 4; BUF->optdata[2] = (UIP_TCP_MSS) / 256; BUF->optdata[3] = (UIP_TCP_MSS) & 255; uip_len = 44; BUF->tcpoffset = 6 << 4; goto tcp_send; /* This label will be jumped to if we found an active connection. */ found: uip_flags = 0; /* We do a very naive form of TCP reset processing; we just accept any RST and kill our connection. We should in fact check if the sequence number of this reset is wihtin our advertised window before we accept the reset. */ if(buf->flags & TCP_RST) { uip_conn->tcpstateflags = CLOSED; UIP_LOG("tcp: got reset, aborting connection."); uip_flags = UIP_ABORT; UIP_APPCALL(); goto drop; /* All segments that are come thus far should have the ACK flag set, otherwise we drop the packet. */ if(!(buf->flags & TCP_ACK)) { UIP_STAT(++uip_stat.tcp.drop); UIP_STAT(++uip_stat.tcp.ackerr);

119 100 UIP_LOG("tcp: dropped non-ack segment."); goto drop; /* Calculated the length of the data, if the application has sent any data to us. */ c = (BUF->tcpoffset >> 4) << 2; /* uip_len will contain the length of the actual TCP data. This is calculated by subtracing the length of the TCP header (in c) and the length of the IP header (20 bytes). */ uip_len = uip_len - c - 20; /* First, check if the sequence number of the incoming packet is what we're expecting next. If not, we send out an ACK with the correct numbers in. */ if(uip_len > 0 && (BUF->seqno[0]!= uip_conn->rcv_nxt[0] BUF->seqno[1]!= uip_conn->rcv_nxt[1] BUF->seqno[2]!= uip_conn->rcv_nxt[2] BUF->seqno[3]!= uip_conn->rcv_nxt[3])) { goto tcp_send_ack; /* Next, check if the incoming segment acknowledges any outstanding data. If so, we also reset the retransmission timer. */ if(buf->ackno[0] == uip_conn->ack_nxt[0] && BUF->ackno[1] == uip_conn->ack_nxt[1] && BUF->ackno[2] == uip_conn->ack_nxt[2] && BUF->ackno[3] == uip_conn->ack_nxt[3]) { uip_conn->snd_nxt[0] = uip_conn->ack_nxt[0]; uip_conn->snd_nxt[1] = uip_conn->ack_nxt[1]; uip_conn->snd_nxt[2] = uip_conn->ack_nxt[2]; uip_conn->snd_nxt[3] = uip_conn->ack_nxt[3]; if(uip_conn->tcpstateflags & UIP_OUTSTANDING) { uip_flags = UIP_ACKDATA; uip_conn->tcpstateflags &= ~UIP_OUTSTANDING; uip_conn->timer = UIP_RTO; /* Do different things depending on in what state the connection is. */ switch(uip_conn->tcpstateflags & TS_MASK) { /* CLOSED and LISTEN are not handled here. CLOSE_WAIT is not implemented, since we force the application to close when the peer sends a FIN (hence the application goes directly from ESTABLISHED to LAST_ACK). */ case SYN_RCVD: /* In SYN_RCVD we have sent out a SYNACK in response to a SYN, and we are waiting for an ACK that acknowledges the data we sent out the last time. Therefore, we want to have the UIP_ACKDATA flag set. If so, we enter the ESTABLISHED state. */ if(uip_flags & UIP_ACKDATA) { uip_conn->tcpstateflags = ESTABLISHED; uip_flags = UIP_CONNECTED; uip_len = 0; UIP_APPCALL(); goto appsend; goto drop; #if UIP_ACTIVE_OPEN case SYN_SENT: /* In SYN_SENT, we wait for a SYNACK that is sent in response to our SYN. The rcv_nxt is set to sequence number in the SYNACK plus one, and we send an ACK. We move into the ESTABLISHED state. */ if((uip_flags & UIP_ACKDATA) && BUF->flags == (TCP_SYN TCP_ACK)) {

120 101 /* Parse the TCP MSS option, if present. */ if((buf->tcpoffset & 0xf0) > 0x50) { for(c = 0; c < ((BUF->tcpoffset >> 4) - 5) << 2 ;) { opt = uip_buf[40 + UIP_LLH_LEN + c]; if(opt == 0x00) { /* End of options. */ break; else if(opt == 0x01) { ++c; /* NOP option. */ else if(opt == 0x02 && uip_buf[40 + UIP_LLH_LEN + c + 1] == 0x04) { /* An MSS option with the right option length. */ tmpport = (uip_buf[40 + UIP_LLH_LEN + c + 2] << 8) uip_buf[40 + UIP_LLH_LEN + c + 3]; uip_conn->mss = tmpport > UIP_TCP_MSS? UIP_TCP_MSS: tmpport; /* And we are done processing options. */ break; else { /* All other options have a length field, so that we easily can skip past them. */ c += uip_buf[40 + UIP_LLH_LEN + c + 1]; uip_conn->tcpstateflags = ESTABLISHED; uip_conn->rcv_nxt[0] = BUF->seqno[0]; uip_conn->rcv_nxt[1] = BUF->seqno[1]; uip_conn->rcv_nxt[2] = BUF->seqno[2]; uip_conn->rcv_nxt[3] = BUF->seqno[3]; uip_add_rcv_nxt(1); uip_flags = UIP_CONNECTED UIP_NEWDATA; uip_len = 0; UIP_APPCALL(); goto appsend; goto drop; #endif /* UIP_ACTIVE_OPEN */ case ESTABLISHED: /* In the ESTABLISHED state, we call upon the application to feed data into the uip_buf. If the UIP_ACKDATA flag is set, the application should put new data into the buffer, otherwise we are retransmitting an old segment, and the application should put that data into the buffer. If the incoming packet is a FIN, we should close the connection on this side as well, and we send out a FIN and enter the LAST_ACK state. We require that the FIN will have to acknowledge all outstanding data, otherwise we drop it. */ if(buf->flags & TCP_FIN) { uip_add_rcv_nxt(1 + uip_len); uip_flags = UIP_CLOSE; uip_len = 0; UIP_APPCALL(); uip_add_ack_nxt(1); uip_conn->tcpstateflags = LAST_ACK UIP_OUTSTANDING; uip_conn->nrtx = 0; tcp_send_finack: BUF->flags = TCP_FIN TCP_ACK; goto tcp_send_nodata;

121 102 /* If uip_len > 0 we have TCP data in the packet, and we flag this by setting the UIP_NEWDATA flag and update the sequence number we acknowledge. If the application has stopped the dataflow using uip_stop(), we must not accept any data packets from the remote host. */ if(uip_len > 0 &&!(uip_conn->tcpstateflags & UIP_STOPPED)) { uip_flags = UIP_NEWDATA; uip_add_rcv_nxt(uip_len); /* If this packet constitutes an ACK for outstanding data (flagged by the UIP_ACKDATA flag, we should call the application since it might want to send more data. If the incoming packet had data from the peer (as flagged by the UIP_NEWDATA flag), the application must also be notified. When the application is called, the global variable uip_len contains the length of the incoming data. The application can access the incoming data through the global pointer uip_appdata, which usually points 40 bytes into the uip_buf array. If the application wishes to send any data, this data should be put into the uip_appdata and the length of the data should be put into uip_len. If the application don't have any data to send, uip_len must be set to 0.*/ if(uip_flags & (UIP_NEWDATA UIP_ACKDATA)) { UIP_APPCALL(); appsend: if(uip_flags & UIP_ABORT) { uip_conn->tcpstateflags = CLOSED; BUF->flags = TCP_RST TCP_ACK; goto tcp_send_nodata; if(uip_flags & UIP_CLOSE) { uip_add_ack_nxt(1); uip_conn->tcpstateflags = FIN_WAIT_1 UIP_OUTSTANDING; uip_conn->nrtx = 0; BUF->flags = TCP_FIN TCP_ACK; goto tcp_send_nodata; /* If uip_len > 0, the application has data to be sent, in which case we set the UIP_OUTSTANDING flag in the connection structure. But we cannot send data if the application already has outstanding data. */ if(uip_len > 0 &&!(uip_conn->tcpstateflags & UIP_OUTSTANDING)) { uip_conn->tcpstateflags = UIP_OUTSTANDING; uip_conn->nrtx = 0; uip_add_ack_nxt(uip_len); else { uip_len = 0; apprexmit: /* If the application has data to be sent, or if the incoming packet had new data in it, we must send out a packet. */ if(uip_len > 0 (uip_flags & UIP_NEWDATA)) { /* Add the length of the IP and TCP headers. */ uip_len = uip_len + 40; /* We always set the ACK flag in response packets. */ BUF->flags = TCP_ACK; /* Send the packet. */ goto tcp_send_noopts; goto drop; case LAST_ACK: /* We can close this connection if the peer has acknowledged our FIN. This is indicated by the UIP_ACKDATA flag. */

122 103 if(uip_flags & UIP_ACKDATA) { uip_conn->tcpstateflags = CLOSED; break; case FIN_WAIT_1: /* The application has closed the connection, but the remote host hasn't closed its end yet. Thus we do nothing but wait for a FIN from the other side. */ if(uip_len > 0) { uip_add_rcv_nxt(uip_len); if(buf->flags & TCP_FIN) { if(uip_flags & UIP_ACKDATA) { uip_conn->tcpstateflags = TIME_WAIT; uip_conn->timer = 0; else { uip_conn->tcpstateflags = CLOSING UIP_OUTSTANDING; uip_add_rcv_nxt(1); goto tcp_send_ack; else if(uip_flags & UIP_ACKDATA) { uip_conn->tcpstateflags = FIN_WAIT_2; goto drop; if(uip_len > 0) { goto tcp_send_ack; goto drop; case FIN_WAIT_2: if(uip_len > 0) { uip_add_rcv_nxt(uip_len); if(buf->flags & TCP_FIN) { uip_conn->tcpstateflags = TIME_WAIT; uip_conn->timer = 0; uip_add_rcv_nxt(1); goto tcp_send_ack; if(uip_len > 0) { goto tcp_send_ack; goto drop; case TIME_WAIT: goto tcp_send_ack; case CLOSING: if(uip_flags & UIP_ACKDATA) { uip_conn->tcpstateflags = TIME_WAIT; uip_conn->timer = 0; goto drop; /* We jump here when we are ready to send the packet, and just want to set the appropriate TCP sequence numbers in the TCP header. */ tcp_send_ack: BUF->flags = TCP_ACK; tcp_send_nodata: uip_len = 40; tcp_send_noopts:

123 104 BUF->tcpoffset = 5 << 4; tcp_send: /* We're done with the input processing. We are now ready to send a reply. Our job is to fill in all the fields of the TCP and IP headers before calculating the checksum and finally send the packet. */ BUF->ackno[0] = uip_conn->rcv_nxt[0]; BUF->ackno[1] = uip_conn->rcv_nxt[1]; BUF->ackno[2] = uip_conn->rcv_nxt[2]; BUF->ackno[3] = uip_conn->rcv_nxt[3]; BUF->seqno[0] = uip_conn->snd_nxt[0]; BUF->seqno[1] = uip_conn->snd_nxt[1]; BUF->seqno[2] = uip_conn->snd_nxt[2]; BUF->seqno[3] = uip_conn->snd_nxt[3]; BUF->srcport = uip_conn->lport; BUF->destport = uip_conn->rport; #if BYTE_ORDER == BIG_ENDIAN BUF->srcipaddr[0] = ((UIP_IPADDR0 << 8) UIP_IPADDR1); BUF->srcipaddr[1] = ((UIP_IPADDR2 << 8) UIP_IPADDR3); #else BUF->srcipaddr[0] = ((UIP_IPADDR1 << 8) UIP_IPADDR0); BUF->srcipaddr[1] = ((UIP_IPADDR3 << 8) UIP_IPADDR2); #endif /* BYTE_ORDER == BIG_ENDIAN */ BUF->destipaddr[0] = uip_conn->ripaddr[0]; BUF->destipaddr[1] = uip_conn->ripaddr[1]; if(uip_conn->tcpstateflags & UIP_STOPPED) { /* If the connection has issued uip_stop(), we advertise a zero window so that the remote host will stop sending data. */ BUF->wnd[0] = BUF->wnd[1] = 0; else { #if (UIP_TCP_MSS) > 255 BUF->wnd[0] = (uip_conn->mss >> 8); #else BUF->wnd[0] = 0; #endif /* UIP_MSS */ BUF->wnd[1] = (uip_conn->mss & 0xff); tcp_send_noconn: BUF->vhl = 0x45; BUF->tos = 0; BUF->ipoffset[0] = BUF->ipoffset[1] = 0; BUF->ttl = UIP_TTL; BUF->proto = IP_PROTO_TCP; #if UIP_BUFSIZE > 255 BUF->len[0] = (uip_len >> 8); BUF->len[1] = (uip_len & 0xff); #else BUF->len[0] = 0; BUF->len[1] = uip_len; #endif /* UIP_BUFSIZE > 255 */ ++ipid; BUF->ipid[0] = ipid >> 8; BUF->ipid[1] = ipid & 0xff; /* Calculate IP and TCP checksums. */ BUF->ipchksum = 0;

124 105 BUF->ipchksum = ~(uip_ipchksum()); BUF->tcpchksum = 0; BUF->tcpchksum = ~(uip_tcpchksum()); UIP_STAT(++uip_stat.tcp.sent); send: UIP_STAT(++uip_stat.ip.sent); /* The data that should be sent is not present in the uip_buf, and the length of the data is in the variable uip_len. It is not our responsibility to do the actual sending of the data however. That is taken care of by the wrapper code, and only if uip_len > 0. */ return; drop: uip_len = 0; return; ******************************************************************** Program Code : uipopt.h File Type : uipopt Header file for transmitter node ******************************************************************** * $Id: uipopt.h,v /01/13 21:12:41 adam Exp $ #ifndef UIPOPT_H #define UIPOPT_H /* This file is used for tweaking various configuration options for uip. You should make a copy of this file into one of your project's directories instead of editing this example "uipopt.h" file that comes with the uip distribution. */ /* */ /* First, two typedefs that may have to be tweaked for your particular compiler. The ux_t types are unsigned integer types, where the X is the number of bits in the integer type. Most compilers use "unsigned char" and "unsigned short" for those two, respectively. */ typedef unsigned char u8_t; typedef unsigned short u16_t; /* */ /* The configuration options for a specific node. This includes IP address, netmask and default router as well as the Ethernet address. The netmask, default router and Ethernet address are appliciable only if uip should be run over Ethernet. All of these should be changed to suit your project. */ /* UIP_IPADDR: The IP address of this uip node. */ #define UIP_IPADDR0 10 #define UIP_IPADDR1 2 #define UIP_IPADDR2 0 #define UIP_IPADDR3 10 /* */ /* The following options are used to configure application specific setting such as how many TCP ports that should be avaliable and if the uip should be configured to support active opens.these should probably be tweaked to suite your project. */ /* Include the header file for the application program that should be used. If you don't use the example web server, you should change this. */ #include "app.h" /* UIP_ACTIVE_OPEN: Determines if support for opening connections from uip should be compiled in. If this isn't needed for your application, don't turn it on. (A web server doesn't need this, for instance.) */ #define UIP_ACTIVE_OPEN 1 /* UIP_CONNS: The maximum number of simultaneously active connections. */

125 106 #define UIP_CONNS 10 /* UIP_LISTENPORTS: The maximum number of simultaneously listening TCP ports. For a web server, 1 is enough here. */ #define UIP_LISTENPORTS 10 /* UIP_BUFSIZE: The size of the buffer that holds incoming and outgoing packets. */ #define UIP_BUFSIZE 180 /* UIP_STATISTICS: Determines if statistics support should be compiled in. The statistics is useful for debugging and to show the user. */ #define UIP_STATISTICS 0 /* UIP_LOGGING: Determines if logging of certain events should be compiled in. Useful mostly for debugging. The function uip_log(char msg) must be implemented to suit your architecture if logging is turned on. */ #define UIP_LOGGING 0 /* UIP_LLH_LEN: The link level header length; this is the offset into the uip_buf where the IP header can be found. For Ethernet, this should be set to 14. For SLIP, this should be set to 0. */ #define UIP_LLH_LEN 0 /* */ /* The following configuration options can be tweaked for your project, but you are probably safe to use the default values. The options are listed in order of tweakability. */ /* UIP_ARPTAB_SIZE: The size of the ARP table - use a larger value if this uip node will have many connections from the local network. */ #define UIP_ARPTAB_SIZE 8 /* The maxium age of ARP table entries measured in 10ths of seconds. An UIP_ARP_MAXAGE of 120 corresponds to 20 minutes (BSD default). */ #define UIP_ARP_MAXAGE 120 /* UIP_RTO: The retransmission timeout counted in timer pulses (i.e., the speed of the periodic timer, usually one second). */ #define UIP_RTO 3 /* UIP_MAXRTX: The maximum number of times a segment should be retransmitted before the connection should be aborted. */ #define UIP_MAXRTX 8 /* UIP_TCP_MSS: The TCP maximum segment size. This should be set to at most UIP_BUFSIZE - UIP_LLH_LEN */ #define UIP_TCP_MSS (UIP_BUFSIZE - UIP_LLH_LEN - 40) /* UIP_TTL: The IP TTL (time to live) of IP packets sent by uip. */ #define UIP_TTL 255 /* UIP_TIME_WAIT_TIMEOUT: How long a connection should stay in the TIME_WAIT state. Has no real implication, so it should be left untouched. */ #define UIP_TIME_WAIT_TIMEOUT 120 /* */ /* This is where you configure if your CPU architecture is big or little endian. Most CPUs today are little endian. The most notable exception are the Motorolas which are big endian. Tweak the definition of the BYTE_ORDER macro to configure uip for your project. */ #ifndef LITTLE_ENDIAN #define LITTLE_ENDIAN 3412 #endif /* LITTLE_ENDIAN */ #ifndef BIG_ENDIAN #define BIG_ENDIAN 1234

126 107 #endif /* BIGE_ENDIAN */ // SPARC IS BIG_ENDIAN, INTEL IS LITTLE_ENDIAN #ifndef BYTE_ORDER #define BYTE_ORDER BIG_ENDIAN #endif /* BYTE_ORDER */ #endif /* UIPOPT_H */ ********************************************************************************* Uipopt.h code for receiver should only be changed in the IP address. Others is same as uipopt.h for transmitter node. ********************************************************************************* /* */ /* The configuration options for a specific node. This includes IP address, netmask and default router as well as the Ethernet address. The netmask, default router and Ethernet address are appliciable only if uip should be run over Ethernet. All of these should be changed to suit your project. */ /* UIP_IPADDR: The IP address of this uip node. */ #define UIP_IPADDR0 10 #define UIP_IPADDR1 2 #define UIP_IPADDR2 0 #define UIP_IPADDR3 5

127 APPENDIX C AVRGCC MAKEFILE FOR uip STACK

128 108 ****************************************************************************** This Makefile from AVRGCC was applied for both source code of transmitter and receiver nodes ******************************************************************************* # MCU name MCU = atmega8535 # Output format. (can be srec, ihex, binary) FORMAT = ihex # Target file name (without extension). TARGET = UIPslip # Optimization level, can be [0, 1, 2, 3, s]. 0 turns off optimization. OPT = s # List C source files here. (C dependencies are automatically generated.) LINK = rs232_tty.c SLIP = $(LINK) UIP = uip.c uip_arch.c SRC = main.c app.c $(LINK) $(UIP) # If there is more than one source file, append them above, or modify and # uncomment the following: #SRC += foo.c bar.c # You can also wrap lines by appending a backslash to the end of the line: #SRC += baz.c \ #xyzzy.c ASRC = EXTRAINCDIRS = CFLAGS = -g -O$(OPT) \ -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums \ -Wall -Wstrict-prototypes \ -Wa,-adhlns=$(<:.c=.lst) \ $(patsubst %,-I%,$(EXTRAINCDIRS)) CFLAGS += -std=gnu99 ASFLAGS = -Wa,-adhlns=$(<:.S=.lst),-gstabs # Optional linker flags. LDFLAGS = -Wl,-Map=$(TARGET).map,--cref # Additional libraries LDFLAGS += -lm # Programming support using avrdude. Settings and variables. AVRDUDE_PROGRAMMER = stk500 AVRDUDE_PORT = com1 # programmer connected to serial device #AVRDUDE_PORT = lpt1 # programmer connected to parallel port AVRDUDE_WRITE_FLASH = -U flash:w:$(target).hex #AVRDUDE_WRITE_EEPROM = -U eeprom:w:$(target).eep AVRDUDE_FLAGS = -p $(MCU) -P $(AVRDUDE_PORT) -c $(AVRDUDE_PROGRAMMER) # Uncomment the following if you want avrdude's erase cycle counter. # Note that this counter needs to be initialized first using -Yn, # see avrdude manual. #AVRDUDE_ERASE += -y # Uncomment the following if you do /not/ wish a verification to be # performed after programming the device.

129 109 #AVRDUDE_FLAGS += -V # Increase verbosity level. Please use this when submitting bug # reports about avrdude. See # to submit bug reports. #AVRDUDE_FLAGS += -v -v # Define directories, if needed. DIRAVR = c:/winavr DIRAVRBIN = $(DIRAVR)/bin DIRAVRUTILS = $(DIRAVR)/utils/bin DIRINC =. DIRLIB = $(DIRAVR)/avr/lib # Define programs and commands. SHELL = sh CC = avr-gcc OBJCOPY = avr-objcopy OBJDUMP = avr-objdump SIZE = avr-size # Programming support using avrdude. AVRDUDE = avrdude REMOVE = rm -f COPY = cp HEXSIZE = $(SIZE) --target=$(format) $(TARGET).hex ELFSIZE = $(SIZE) -A $(TARGET).elf # Define Messages # English MSG_ERRORS_NONE = Errors: none MSG_BEGIN = begin MSG_END = end MSG_SIZE_BEFORE = Size before: MSG_SIZE_AFTER = Size after: MSG_COFF = Converting to AVR COFF: MSG_EXTENDED_COFF = Converting to AVR Extended COFF: MSG_FLASH = Creating load file for Flash: MSG_EEPROM = Creating load file for EEPROM: MSG_EXTENDED_LISTING = Creating Extended Listing: MSG_SYMBOL_TABLE = Creating Symbol Table: MSG_LINKING = Linking: MSG_COMPILING = Compiling: MSG_ASSEMBLING = Assembling: MSG_CLEANING = Cleaning project: # Define all object files. OBJ = $(SRC:.c=.o) $(ASRC:.S=.o) # Define all listing files. LST = $(ASRC:.S=.lst) $(SRC:.c=.lst) # Combine all necessary flags and optional flags. # Add target processor to flags. ALL_CFLAGS = -mmcu=$(mcu) -I. $(CFLAGS) ALL_ASFLAGS = -mmcu=$(mcu) -I. -x assembler-with-cpp $(ASFLAGS) # Default target. all: begin gccversion sizebefore $(TARGET).elf $(TARGET).hex $(TARGET).eep \ $(TARGET).lss $(TARGET).sym sizeafter finished end

130 110 # Eye candy. # AVR Studio 3.x does not check make's exit code but relies on # the following magic strings to be generated by the compile $(MSG_BEGIN) $(MSG_ERRORS_NONE) # Display size of file. [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_BEFORE); $(ELFSIZE); echo; fi [ -f $(TARGET).elf ]; then echo; echo $(MSG_SIZE_AFTER); $(ELFSIZE); echo; fi # Display compiler version information. gccversion --version # Convert ELF to COFF for use in debugging / simulating in COFFCONVERT=$(OBJCOPY) --debugging \ --change-section-address.data-0x \ --change-section-address.bss-0x \ --change-section-address.noinit-0x \ --change-section-address.eeprom-0x $(MSG_COFF) $(TARGET).cof $(COFFCONVERT) -O coff-avr $< $(TARGET).cof $(MSG_EXTENDED_COFF) $(TARGET).cof $(COFFCONVERT) -O coff-ext-avr $< $(TARGET).cof # Program the device. program: $(TARGET).hex $(TARGET).eep $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH) $(AVRDUDE_WRITE_EEPROM) # Create final output files (.hex,.eep) from ELF output file. $(MSG_FLASH) $@ $(OBJCOPY) -O $(FORMAT) -R.eeprom $< $@ $(MSG_EEPROM) $@ -$(OBJCOPY) -j.eeprom --set-section-flags=.eeprom="alloc,load" \ --change-section-lma.eeprom=0 -O $(FORMAT) $< $@ # Create extended listing file from ELF output file. $(MSG_EXTENDED_LISTING) $@ $(OBJDUMP) -h -S $< > $@

131 111 # Create a symbol table from ELF output file. $(MSG_SYMBOL_TABLE) $@ avr-nm -n $< > $@ # Link: create ELF output file from object files..secondary : $(TARGET).elf.PRECIOUS : $(OBJ) $(MSG_LINKING) $@ $(CC) $(ALL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS) # Compile: create object files from C source files. %.o $(MSG_COMPILING) $< $(CC) -c $(ALL_CFLAGS) $< -o $@ # Compile: create assembler files from C source files. %.s : %.c $(CC) -S $(ALL_CFLAGS) $< -o $@ # Assemble: create object files from assembler source files. %.o $(MSG_ASSEMBLING) $< $(CC) -c $(ALL_ASFLAGS) $< -o $@ # Target: clean project. clean: begin clean_list finished end $(MSG_CLEANING) $(REMOVE) $(TARGET).hex $(REMOVE) $(TARGET).eep $(REMOVE) $(TARGET).obj $(REMOVE) $(TARGET).cof $(REMOVE) $(TARGET).elf $(REMOVE) $(TARGET).map $(REMOVE) $(TARGET).obj $(REMOVE) $(TARGET).a90 $(REMOVE) $(TARGET).sym $(REMOVE) $(TARGET).lnk $(REMOVE) $(TARGET).lss $(REMOVE) $(OBJ) $(REMOVE) $(LST) $(REMOVE) $(SRC:.c=.s) $(REMOVE) $(SRC:.c=.d) # Automatically generate C source code dependencies. %.d: %.c set -e; $(CC) -MM $(ALL_CFLAGS) $< \ sed 's,\(.*\)\.o[ :]*,\1.o \1.d :,g' > $@; \ [ -s $@ ] rm -f $@ # Remove the '-' if you want to see the dependency files generated. -include $(SRC:.c=.d) # Listing of phony targets..phony : all begin finish end sizebefore sizeafter gccversion coff extcoff \ clean clean_list program

132 APPENDIX D SERIAL DEVICE PROGRAMMER (PONYPROG2000 MANUAL)

133 112 How to use PonyProg2000 for the Microrobot AVR Products(Rev 0.3) Contents What is PonyProg2000? How to install? Preparation How to download a program using PonyProg2000 What is PonyProg2000? PonyProg is a serial device programmer software with a user-friendly GUI framework available for Windows95, 98, 2000 & NT and Intel Linux. Its purpose is reading and writing every serial device. At the moment it supports I²C Bus, Microwire, SPI EEPROM, the Atmel AVR and Microchip PIC micro. For more details, visit or read Ponyprog2000.html in the CD. How to install? Run the setup.exe file. Preparation Supply proper power to the (CPU) board. Connect the downloading adapter to the PC printer port. Then connect the downloading adapter and the board with the flat cable. Turn on the power switch on the board. Power LED turns on (when applicable). Compile the source file you want to download. How to download a program using PonyProg2000 Run the PonyPorg2000 program.

134 113 Fig 1.0 Click on OK. The following window appears. Fig 1.1 Click on OK. Select Setup Calibration. Fig 1.2

135 114 Click on Yes button. The following window appears. Fig 1.3 Click on OK. Select Setup interface Setup and set up as shown below (Parallel, Avr ISP I/O, LPT1) and click on Probe. Test Ok message appears. Click on OK. Click on OK. Fig 1.4 Fig 1.4.2

136 115 Select the device you want. ( Device AVR micro XXX, XXX is the device you want) Select Command Program Options and check as shown below. (Reload Files, Erase, Write Program memory) Click on OK. Fig 1.5 Some devices require Flash Fuse Bits Setting for the desired clock source setting. For example, CKSEL3..0 bits of the ATmega8535 and Atmega8515 devices need to be set 1 to select the External Crystal clock source mode. Refer to Clock Options of the device sheet for the detailed bit setting. If you need to set the bits, select Command Security and Configuration Bits. Click on Read button, uncheck the CKSEL3..0 bits and then click on Write button. Fig 1.6 shows a Security and Configuration Bits dialog box as an example.

137 116 Fig 1.6 CKSEL bits Setting for ATmega8535(MR-8535) Note: If the board has an AT90S-type CPU instead of ATmega-type, the setting is not required. Select File Open Program File and load the *.rom(or *.hex) file. Select Command Program or press Ctrl + P to start the downloading. If no Program Failed message appears, the downloading has been completed successfully.