Proof of Concept Implementation of Embedded Ethernet System

Proceedings of the 2011 ASEE Northeast Section Annual Conference University of Hartford

Copyright © 2011, American Society for Engineering Education

Proof of Concept Implementation of Embedded Ethernet System

Saeid Moslehpour, Hesham Elsaghir College of Engineering, Technology and Architecture,

University of Hartford [email protected]

[email protected] Abstract: With today’s incredible and vast changes in technologies, today's embedded systems engineers are progressively asked to incorporate Ethernet connectivity into their systems. As demand increases for larger and farther remote systems, the old serial communication systems are incapable of fulfilling our speed and data connection needs. Moreover, with the rapid disappearance of serial and parallel ports from today’s personal computers, the idea of incorporating Ethernet into embedded system is getting the full attention in today’s embedded system markets. Ethernet's persistence and durability in connecting computers to a network makes it an attractive networking choice for embedded systems. Over the years, the cost of Ethernet connectivity has dropped significantly. The use of Ethernet offers many benefits. System designers can now reuse the Ethernet interface to perform product-service-related tasks that were once handled by RS-232 or similar interfaces. Aside from the obvious competitive advantages of an Ethernet-enabled system, from a system designer's perspective, the key advantage to connecting over Ethernet lies in the overall savings in software development. If system designers use standard software protocols over Ethernet, they could take advantage of a superfluity of software that's already installed on many of today's computers and handheld devices,

ithout worrying about compatibility between multiple operating systems. w Keywords: Ethernet transceivers, Embedded Ethernet System, TCP/IP, real-time operating system. INTRODUCTION Embedded Ethernet hardware and software development:

Until recently, complexity has prevented many embedded systems designers from deploying Ethernet connectivity in their applications. This needn't be the case, the many ready-made reference designs available from various silicon and third-party vendors can help designers get a head start in embedded Ethernet designs.

These reference designs are based on vendors' Ethernet transceivers and help engineers evaluate embedded Ethernet applications. Most of them carry tutorial examples on a CD-ROM, with links to the vendors' homepages.

mailto:[email protected]%20,%20%[email protected]

mailto:[email protected]



Software is vital for fast product development and is often an enabler in product-feature differentiation. For developing embedded Ethernet applications, designers have three options: develop their own, open source, or commercial.

Each option has advantages and disadvantages. System designers must understand all implications and select the optimal solution. Developing their own software takes time and money, typical optimized TCP/IP stacks with a few application modules may alone require many months of development time. In addition, designers must be prepared to spend time adding and maintaining new protocols and application modules.

On the other hand, many open source and commercial solutions exist. Although open-source solutions offer a variety of capabilities, their memory footprint and processing requirements may be out of reach for small-embedded systems. Some may also require the use of a real-time operating system (RTOS), which in turn increases overall resource requirements. Some open-source solutions have licensing terms requiring full or partial source code disclosure. Another variation of open-source software is the software provided by the silicon vendors. A handful of these vendors provide complete TCP/IP software for free, as long as you use their products. When selecting vendor-supplied software, designers must ensure that it includes all necessary protocols and modules that their system will need.

System designers may also consider commercially available software solutions. Each has varying licensing and payment terms to suit particular needs. Some commercial solutions may require the use of a specific RTOS, which must be purchased separately. Beware though, adding an RTOS to support a TCP/IP stack may significantly increase the overall cost.

Whatever solution we choose, the availability of full source code is the key to effectively debugging application code. Not only does the object-only (binary) solution prevent source-level debugging, but also it inhibits the required understanding of the systems' limitations and behavior under certain conditions.

Implementation of TCP/IP stack architecture:

A significant component in the design of an embedded Internet device is the TCP/IP stack firmware. An embedded Ethernet device can only support the processing of Ethernet packets. However, higher-layer protocols must be supported in firmware. Figure 1 shows a simplified block diagram of a TCP/IP stack. The stack consists of multiple layers, and each layer contains multiple modules. Each layer is responsible for providing a specific networking function. The application layer, for example, is where various high-level applications interface with low-level stack layers.

Figure 1: Simplified block diagram of a TCP/IP stack

Each module within a layer is responsible for managing a specific protocol. The Address Resolution Protocol (ARP), for example, is responsible for resolving the Internet Protocol (IP) address into the corresponding MAC address. Some modules are optional depending on the final application, while others are mandatory. For instance, Ethernet, ARP, and IP are mandatory. A system must also have either a user datagram protocol (UDP) or transmission control protocol (TCP) or both, depending upon the upper layer of the application selection.

Table 1: Simplified table of a TCP/IP stack

Web server, mail client, DHCP Client Application Layer UDP, TCP Transport Layer IP, ARP Network Layer Ethernet Physical Layer

Based on the TCP/IP block diagram, one way to implement the TCP/IP stack is to divide it into multiple layers. A strict TCP/IP reference model-based stack requires each layer to use the services of layers immediately below it. This design attitude may be too costing for small embedded systems.

On the other hand, to accelerate protocol processing, modules in an embedded TCP/IP stack may directly access one or more layers that aren't directly below it. Designers can decide when a layer bypasses its adjacent module for the services it needs, based on the amount of overhead and whether a given service needs intelligent processing before it can be passed to the next layer.

In the interest of optimizing the stack, an embedded TCP/IP stack must be tightly integrated to an Ethernet controller. Most full-featured stacks retrieve Ethernet data packets into a host controller's RAM for processing. This approach increases RAM requirements on the host controller.

Instead, an embedded stack can use the controller's on-chip RAM as a buffer, until a higher-level module needs to access the data. As required by TCP specs, each TCP segment contains a checksum that covers the entire TCP packet, including the data area. To reduce RAM requirements, the TCP layer may use the controller RAM buffer to





perform the checksum calculation. Some Ethernet controllers even provide hardware-based checksum engines to compute the packet checksum. This additional support can significantly decrease the total processing time of TCP and UDP packets.

The TCP/IP stack uses a concept called "socket" where application-layer modules can establish multiple virtual connections to remote nodes using one copy of the underlying transport layer module, such as UDP or TCP. An embedded stack with limited RAM can implement this concept using the "shared-socket buffer" approach. Instead of allocating a dedicated data buffer for each socket, the embedded stack only allocates one buffer and reuses it for multiple sockets. This approach, however, places a programming restriction that a socket must be fully processed and released before accessing the next data packet.

User interface:

The choice of a user interface (UI) plays a key role in the final product's acceptance. There are security implications associated with each different UI, as well. Depending on the application, typical UI options include the Web server, e-mail, simple network management protocol (SNMP) agent, and short message service (SMS) interfaces. A home automation system may use a combination of Web-server, e-mail, and SMS interfaces, while a factory automation floor may use an SNMP interface.

A Web server is appropriate when on-demand monitoring and control are desired. Looking closely at the SNMP option, although SNMP is a widely used management protocol for enterprise-computing networks, it can be made suitable for embedded systems. A key advantage of using SNMP protocol is the availability of multiple third-party PC-based monitoring software programs.

TCP, on the other hand, provides a more reliable transport with an increased program memory requirement. When employing a UDP, most of the SNMP-management applications perform extra timeout and error checking to ensure a reliable management connection. As a result, the choice of using UDP or TCP as a transport service really depends on the amount of resources available. For small embedded systems with limited program and data memory, UDP is the choice of transport.

System design:

To design this complex system using a small embedded microprocessor, I had to combine two parts, one is the microcontroller from Renesas Technology [1] M30626FHPFP and interface it with the Lan91C111 10/100 Non-PCI Ethernet Single Chip MAC + PHY to achieve a full embedded Ethernet system capable of performing the microcontroller tasks while providing the fast speed communication line of Ethernet technology.

The system is based on the super loop algorithm. The super loop manages all system tasks and takes care of hardware resources and communications. The super loop is an infinite loop that would execute for ever and all tasks are called and returned to the loop



until the system shuts down. To handle this complicated system with multi tasking requirements, the following tasks are executed consequently

• Real Time Timer Task • Serial Input/Output Task • TCP/IP Task • UDP Task • DHCP Task • Web Server Task • I/O Tasks LED’s and Keypad • ADC Task

Real time timer task is the time keeper task that keeps tics of the system and calculates seconds, minutes and hours. Real time timer task also handles the delay calls that requested by the system and other tasks. Serial input/output task is the task that manages the serial ports and makes sure data in is handled correctly and moved to the receive buffer and system is notified to make use of the data received. Also, any data out sent by the system to either serial is handled by the serial input/output task. TCP/IP task is one of the most time demanding task as it requires big slice of the system process. Even though the TCP/IP Task requires a lot of process form the microcontroller, it does not happen all the time, it interrupts the system only when the MAC/PHY received a buffer via the Ethernet connection. DHCP Task is very similar to the TCP/IP task. This task is always off unless a valid TCP/IP connection has been established and a UDP connection is requested.Each of these tasks is discussed in details later in the next couple of sections.

Super-Loop the Virtual RTOS

Before we get into the super-loop process, we will navigate the system initialization that prepares all resources to work in a little orchestra and play our great symphony “The Embedded Ethernet System”. At the beginning we go through the most important key in the Ethernet part which is the MAC address. The MAC address should be built in and stored in a location that is read only to the system, I used a constant Variable that will be stored in the Flash and never over-written. Right after this we construct the second main

If default IP forced switch is pressed then “192.168.0.175” is forced

If we will use the DHCP to request a dynamic IP address

With these two options we give the system the flexibility to work in different environments without the limitation of the source of where we get an IP address. Following initializing the network keys we jump to initializing the reset of the system:

• Init MICRO • Init ARP • Init UDP • Init TCP

• Init UART0 and UART2 • Init HTTPS • Init RTC

Now after we have a fully initialized system we start the main infinite loop, the Super-Loop. The Super-Loop will work as RTOS that will visit each of the sub tasks according to the events that will be set or cleared. By using this algorithm, we prevent wasting any time in a task if there is no need to check that resource task.

Real Time Clock Task

The Real-Time-Clock RTC, for short, is one of the simplest tasks implemented in the system. The RTC task is an interrupt service routine that gets interrupted every second. Once it starts it will:

• Increment the seconds count • Mange the proper increment of Second, Minutes and Hours • Updates the LCD display Flag correctly if required

Because the RTC always run using an interrupt service routine, we know that the background functions will never get out of line or loose sync as the foreground is very fast and restores all values to the system once it is finished (The Service Routines) [6]. The foreground functions are very important functions that run only on request of a resource and will service that resource very fast and will set a flag to let the system know about the instance. Also, in this task we manage to let the system know about the one second that is passed by setting a flag so, any other task checks for interested to know if a second went by or not will be able to discover that.

Figure 2 Order of different tasks

Serial Input/Output Task





This task can count as the second simplest task implemented after the RTC. Even though there are a lot involved here to handle the two different UARTs of the system in the UART Driver, once we do with the driver, the task is very simple to mange. In our system we have three UARTs to use, however, UART1 is used by the debugger and cannot be used unless system is not under debug. For this reason I temporarily not including this UART in the system and working only on UART0 and UART2. as I mentioned earlier there is a driver that controls the UARTs and this is the part that uses Interrupt Service Routine, ISR for short. The driver is responsible of taking any inbound data on the Rx line of either UART and pushing it to the software Rx buffer. The Driver also will monitor the Tx buffer and pushes any outbound data to the Tx line. See Figure 3. Once this is done, we go back to the Serial I/O task. The task is invoked only if the UART flag is set which means there are some data needs to be sent or analyzed from or to the serial ports we have in the system. The system has a dedicated port that any data sent from it will be sent to the Ethernet connection if one is opened. That is UART0. This future gives the system an option to connect to a terminal or any other embedded system that is not capable of using an Ethernet connection and send any serial data to it. Also, this port can be used for debugging the system and send any messages to the terminal to get feedback from the user or programmer. The second UART port, UART2, is designed to serve as an internal communication port to hook the system to any intelligent device out there and be able to control that system. In some how it is similar functionality as UART0, but, it is designed to handle generic serial communication including TTL and RS232 levels. With this port I was able to connect to a voice synthesizer and mange to convert all my LCD messages to voice which is more attractive than reading a LCD display. See Figure 4.

Figure 3 Hardware Driver Controlling I/O lines

UART Driver Uses ISR

Rx Hardware

Line

Tx Hardware

Line

Rx Software Buffer

Tx Software Buffer



Figure 4 Embedded Ethernet System as a Gateway Serial to Ethernet

The process of the serial driver can be summarized in the following code segment: void uart_init(char ch,unsigned long BAUD_RATE); This function will initialize the serial communication for both channel 0 and 2 void ErrSub(char ch); This function will clear any serial errors if we got any void uart0_xirq(void); This function will handle transmitting data in the transmit buffer for channel 0 void uart0_rirq(void); This function will handle receiving data from the receiving register of channel 0 void uart2_xirq(void); This function will handle transmitting data in the transmit buffer for channel 2 void uart2_rirq(void); This function will handle receiving data from the receiving register of channel 2 void Put_str(char ch, _far unsigned char *A); This function will transmit a string using either channel 0 or 2 void Put_Ch(char ch, unsigned char A); This function will transmit a character using either channel 0 or 2 unsigned int Get_Char(char ch); This function will get a character from either channel 0 or 2 void Say_Str(_far unsigned char *A); This function will transmit a voice command to the voice synthesizer processor using only channel TCP/IP Task

Embedded Ethernet System

Ethernet Connection

Serial Embedded System

TTL or RS232



The process of the serial driver can be summarized in the following code segment: void uart_init(char ch,unsigned long BAUD_RATE); This function will initialize the serial communication for both channel 0 and 2 void ErrSub(char ch);

This function will clear any serial errors if we got any void uart0_xirq(void); This function will handle transmitting data in the transmit buffer for channel 0 void uart0_rirq(void); This function will handle receiving data from the receiving register of channel 0 void uart2_xirq(void); This function will handle transmitting data in the transmit buffer for channel 2 void uart2_rirq(void); This function will handle receiving data from the receiving register of channel 2 void Put_str(char ch, _far unsigned char *A);

This function will transmit a string using either channel 0 or 2 void Put_Ch(char ch, unsigned char A);

This function will transmit a character using either channel 0 or 2 unsigned int Get_Char(char ch);

This function will get a character from either channel 0 or 2 void Say_Str(_far unsigned char *A);

This function will transmit a voice command to the voice synthesizer processor using only channel TCP/IP Task

Port Numbers

Port numbers are the mechanism for identifying particular client and server applications. Servers select a port to wait for a connection. Most services have well-known port numbers. For example, HTTP uses port 80. When a web browser (the client) requests a web page it specifies port 80 when contacting the server.

Clients usually have temporary port numbers since they exist only as long as the session lasts. Some of the common well-known TCP port numbers are listed in the table below

Table 2: List Port Numbers

Port Number Listing application 7 ECHO request 20/21 File Transfer protocol (FTP) 23 Telnet 25 Simple Mail Transfer Protocol (SMTP) 53 Domain Name Server 80 HTTP Server

TCP/IP Protocol Stack

TCP/IP is the protocol suite upon which all Internet communication is based. Different vendors have developed other networking protocols, but even most network operating systems with their own protocols, such as Netware, support TCP/IP. It has become the standard. Protocols are sometimes referred to as protocol stacks or protocol suites. A protocol stack is an appropriate term because it indicates the layered approach used to design the networking software. See figure 5. Each host or router in the internet must run a protocol stack. The details of the underlying physical connections are hidden by the software. The sending software at each layer communicates with the corresponding layer at the receiving side through information stored in headers. Each layer adds its header to the front of the message from the next higher layer. The header is removed by the corresponding layer on the receiving side. In this section I will discusses the protocols available in the TCP/IP protocol suite. The following figure shows how they correspond to the 5-layer TCP/IP Reference Model. This is not a perfect one-to-one correspondence; for instance, Internet Protocol (IP) uses the Address Resolution Protocol (ARP), but is shown here at the same layer in the stack. See figure 6.

Figure 5: Flow of Data Between Two Computers Using TCP/IP Stacks



Figure 6: TCP/IP Protocol Flow

IP IP provides communication between hosts on different kinds of networks (i.e., different data-link implementations such as Ethernet and Token Ring). It is a connectionless, unreliable packet delivery service. Connectionless means that there is no handshaking, each packet is independent of any other packet. It is unreliable because there is no guarantee that a packet gets delivered; higher-level protocols must deal with that. IP Address IP defines an addressing scheme that is independent of the underlying physical address (e.g, 48-bit MAC address). IP specifies a unique 32-bit number for each host on a network. This number is known as the Internet Protocol Address, the IP Address or the Internet Address. These terms are interchangeable. Each packet sent across the internet contains the IP address of the source of the packet and the IP address of its destination. For routing efficiency, the IP address is considered in two parts: the prefix which identifies the physical network, and the suffix which identifies a computer on the network. A unique prefix is needed for each network in an internet. For the global Internet, network numbers are obtained from Internet Service Providers (ISPs).

Proceedings of the 2011 ASEE Northeast Section Annual Conference

University of Hartford Copyright © 2011, American Society for Engineering Education



IP Address Classes The first four bits of an IP address determine the class of the network. The class specifies how many of the remaining bits belong to the prefix (aka Network ID) and to the suffix (aka Host ID). The first three classes, A, B and C, are the primary network classes. When interacting with mere humans, software uses dotted decimal notation; each 8 bits is treated as an unsigned binary integer separated by periods. IP reserves host address 0 to denote a network. 140.211.0.0 denotes the network that was assigned the class B prefix 140.211. See Table 3

UDP Task This task is used to stream ADC values to the remote. So it is functioning only when a TCP/IP connection has been established.The following flow chart descries the process of the task. See figure 7.

Difference between TCP and UDP

TCP is a connection-oriented protocol; a connection can be made from client to server, and from then on any data can be sent along that connection.

Reliable - when a message is sent along a TCP socket, it will get to its destination unless the connection fails completely. If it gets lost along the way, the server will re-request the lost part. This implies complete integrity: data doesn't get corrupted.

Ordered - if two messages are sent along a connection, one after the other, the first message will reach the receiving application first. When data packets arrive in the wrong order, the TCP layer holds the later data until the earlier data can be delivered to the application.

Heavyweight - TCP requires three packets just to set up a socket, before any actual data can be sent. When the low level parts of the TCP "stream" arrive in the wrong order, resend requests have to be sent, and all the out-of-sequence parts have to be put back together, so it requires a bit of work to piece together.

Streaming - Data is read as a "stream," with nothing distinguishing where one packet ends and another begins. There may be multiple packets per read call.

UDP is a simpler message-based connectionless protocol. With UDP messages (packets) cross the network in independent units.

Unreliable - When a message is sent, it can't be known if it will reach its destination; it could get lost along the way.

Not ordered - If two messages are sent to the same recipient, the order in which they arrive cannot be predicted.

Lightweight - There is no ordering of messages, no tracking connections, etc. It's just "fire and forget". This means it's a lot quicker, and the network card / OS have to do very little work to translate the data back from the packets.

Table 3: IP Address Classes

Class

First 4 Bits Number of Prefix Bits

Max # Of Networks

Number Of Suffix Bits

Max # Of Hosts Per Network

A 0xxx 7 128 24 16,777,216 B 10xx 14 16,384 16 65,536 C 110x 21 2,097,152 8 256 D 1110 Multicast E 1111 Reserved for

future use.

Figure 7: UDP Task





Datagram

Packets are sent individually and are guaranteed to be whole if they arrive. One packet per one read call. DHCP Task Here the DHCP Task is a little complex but it does not take a lot of process from the system as it would run in different modes depends on the current state. The different states of DHCP Task are:

• DHCP_STATE_INIT • DHCP_STATE_SELECTING • DHCP_STATE_REQUESTING • DHCP_STATE_RENEWING

DHCP_STATE_INIT When initializing the DHCP by calling the dhcpc_init function, it starts by setting the local IP to 0xFFFFFFFF which is 255.255.255.255 this will be used as part of the DHCP discovery packet that will be sent later. Next the MAC address of the system is loaded. Also, it sets the standard port numbers for server 67 and for the client 68. These are the standard UDP ports assigned to DHCP communication between the client and the server. DHCP_STATE_SELECTING This is the state where the DHCP task is to monitor the communication states and makes sure that we did not time out and/or if we did not receive any respond to our requests. If the task decides that we are in a situation that requires the communication phases to be reset and start over, DHCP task will be reset and started over from initialization. This is very helpful if the system sent a request to DHCP server and never got any response because there is no DHCP server out on this network and the system has to flag an error to the user or ask for other boot option. DHCP_STATE_ REQUESTING In this state, the DHCP Task manages the four different phases. These phases set the type of communication between the embedded system and the DHCP server. The order of these phases is very important and is a standard communication protocol. The phases are:

• Discovery • Offer • Request • Acknowledge

Figure 8 Phases of Typical DHCP Communication sessions

Discovery phase: The system will generate a packet consists of the system MAC address and IP, then identifies the packet as a UDP broadcast that will target the DHCP server. This packet will let the DHCP server understand that a system out there on the network is requesting an IP address to start communicating with other network enabled devices. The DHCP server will then send the Offer. Offer Phase: When DHCP receives the Discovery packet from the system, it generates a packet that contains the MAC address of the requested system and a new IP that is not being used by any other devices on that network segment. This packet will be a UDP broadcast also, as the client does not have a legitimate IP yet that can identify it. When the client receives the Offer packet it scans it and makes sure it was targeting the client with the correct MAC address. At this point the client has to send a Request packet. Request Phase: Receiving the Offer packet is not good enough for the client to start using the offered IP address. The DHCP server has to know that the client received the Offer packet and decided to use that IP, otherwise the server will assume that the client did not receive the packet or received another IP Offer from another DHCP server and the DHCP server will decide to recall that IP and keep it for another offer. So, our system, the client, will have to generate a new packet that contains the system MAC address, the new IP that was offered from the DHCP server, and address it to be a Request packet that confirms what the server sent first in the Offer packet. The Request packet is still a UDP broadcast packet as the system, the client, did not have a final permission to use the new offered IP. When the server receives that packet it will officially send the final packet, the Acknowledge packet that means that the system can now use the offered IP address and use it to identify it self in any type of network communications on this subnet. It also means that the server will assign this IP address to that client and will not offer this IP again to any client until the lease time expires and the client does not request it



http://upload.wikimedia.org/wikipedia/commons/2/28/DHCP_session_en.svg



again. The lease time is one of the fields that get sent in the Offer and Acknowledge packets. Acknowledge Phase: This is the final UDP broadcasting between the server and the client confirming that the offered IP is now belongs to the client with the specified MAC address. This packet also, contains all the subnet mask and other settings that the client will need to communicate on this subnet. These settings are:

• DHCP server IP • Gateway IP • Subnet Mask • DNS Server IP, or IP’s • Lease time start • Lease time expire

From now, the client can be addressed by the new IP and communicate freely on the network. dhcpc_send_message is the function that manages the type of message will be sent to the server. DHCP_STATE_RENEWING In this state, the DHCP is done and already leased an IP from the server. But, leasing an IP from a DHCP server does not mean we can keep this IP for ever. The lease comes with leasing time information. So the DHCP task has to sleep and wait for the lease time to expire then send another request to either keep the IP we already have or renew with a new one.For reference, check the DHCP Task Flow chart at the reference section.

Web Server Task The Server Task is a great future was added to the system to increase the overall system benefits as it can be remotely controlled via a internet browser. The web server in this project is very simple as it only has two html pages. First page shows some information about the system and the second confirms when we send a message to the system LCD from the first html page. Typically HTTP or web server used TCP connection and uses port 80. The client that is using the internet browser will start by typing the system IP address in the browser address. This will initiate the communication by sending a request to the web server to display the main html page. The special future about out web server that the html page it loads has special tags. That while the task is loading the html page it will pause at these tags and replace each tag with the corresponding system variable and then send the complete page to the browser. When the browser gets that html page it will run some script commands and be able to make use of these variables and display them on the screen. https_run function is the one that manages sending these pages according to the request from the client.



HTTP defines eight methods indicating the desired action to be performed on the identified resource. HEAD

Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

GET Requests a representation of the specified resource. By far the most common method used on the Web today. Should not be used for operations that cause side-effects.

POST Submits data to be processed to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both. This function is used to send some text from the web browser to be displayed in the system LCD.

PUT Uploads a representation of the specified resource. This is not used in our simple web server.

DELETE Deletes the specified resource. This is not used in our simple web server.

TRACE Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request. This is not used in our simple web server.

OPTIONS Returns the HTTP methods that the server supports. This can be used to check the functionality of a web server.

CONNECT Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication HTTPS through an unencrypted HTTP proxy.

HTTP servers are supposed to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method.

For reference, check the Web Server Task Flow chart at the reference section.

I/O Tasks LED’s and Keypad For any microcontroller to interact with the outside world it must have the following resources:

• I/O Input/Output :gives the user the option to interact with and control the microcontroller

• LED’s : this is part of the user’s interface and can be used to keep the user informed of some operations being executed

Keypad is the old style of user input to have more control on the process the microcontroller is doing or to select one or more option of executions schemes, now the touchpad and other finger print readers are used to interact with the microcontroller and they considered part of the Input/output devices. To perform this task efficiently without wasting any clock cycles, I used some interrupts to flag the task if there is a new input from the keypad, I/O need to be changed or a request to change the status of an LED. If so, the task will run the following flow chart. This segment of code will take care of keypad input that is connected to one of the microprocessor ports. And will be executed only if a flag is checked. A similar task will be executed only when a flag is checked that will take care of the LED’s status.

Figure 8: I/O Task Flow Chart



ADC Task The ADC task is managed completely as the previous task, the I/O LED and Keypad task. The interrupt service routine is used to update any changes to the ADC inputs and a flag is checked. When the ADC task starts and discovers that the flag is clear it is terminated immediately, but if the flag is checked then the task will execute and process the change to the proper resource.

Figure 9: ADC Task Flow Chart

As you can see from the above Figure segment, there are four different ADC channels being used and tested for every time the task is executed.

Graphical User Interface: To give the user the option to interact remotely with the embedded system, a GUI interface was designed using MS Visual C++ and MFC.Figure 10 shows the M16C communicator Graphical User Interface “GUI” that communicates with the embedded Ethernet system via any network connection with a valid IP address. The M16C communicator was designed using Microsoft Visual C++ 6.0 and Microsoft Foundation Classes “MFC”. The M16C communicator contains of the following features:





• IP Address Configuration • Port Number • Send and Receive options • LED and Buttons Status • Serial Translator Future • UDP Data Stream Future • Variable Data Entry

To make use of the Ethernet future, the M16C Communicator was designed to give the user the ability to fully control the Embedded System remotely.

IP Address Configuration: Having the option to configure the IP address gives the user the flexibility to wide range of IP’s that the Embedded System can obtain via a static configuration or DHCP IP offering from a DHCP server.

Port Number: Just like the IP address is flexible, the port number is also flexible and easy to change. By using different port numbers we can insure that the software application will not conflict with any other application running on the PC at the same time with M16C Communicator. In MS Windows, we are allowed to open a socket with a port number. That port number can be used only with one application.

Send and Receive options: The M16C Communicator gives the user the option to send text messages to the embedded system via Ethernet connection. After selecting IP address and Port number the use would click on the connect button. Once the M16C communicator is connected to the embedded system, the user can type a text message to be sent to the embedded system and then just click on the send button.

Figure 10: M16C Communicator

LED and Buttons Status: The LED and Button Status are great future that gives the user real time monitoring to inputs and outputs in the embedded system. These output devices can be:

• Motor • Light systems • Solenoid control • Door control

And the input devices can be: • Motion sensors • Control buttons • Touch or pressure sensors • Temperature sensors

Serial Translator Future: This future demonstrates how our embedded system can be configured to be the serial to Ethernet system that provides Ethernet connectivity to an old embedded system via a UART or a RS232 port. Any text typed in the “Send” text box and pressing “Send Serial 19200” button, a test packet will be sent to the Embedded System with a command to stream the contents of the packet to the serial port and any device connected to the serial port will receive that contents in the “Send” text box.

UDP Data Stream Future: When enabling this future a stream of data that represent the ADC read values from the Embedded System Analog port input. With this future we can monitor any temperature or Infra Red sensors connected to the Embedded System in real time.





Also, this future will log all these data to a log file that can be retrieved and used in system diagnostics in later tasks.

Variable Data Entry: This variable data entry will act like a motor or arm controller. It will send numerical values to the Embedded System that can be used to control PWM, positioning system, reference value or any variable that needs to be controlled manually. Connection Status: Serial Data Option: Older RS232 system data transfer Stream UDP Data Option: real time data stream and monitor Variable Data Entry: control a speed, angle, or a variables on real time manipulation Testing procedure: Working on this embedded system, I learned to test each component separately before connecting them to the final project. Using this sequence did prevent a lot of glitches and any mistakes in the preparation of system. Also, by testing and completely understanding each part functionality and requirements I simplified putting together a complex embedded system with multi functions such as Ethernet. Commands Used to communicate between Embedded System and GUI:The commands are stored in the packet sent from the GUI to the Embedded System. These commands describe the function that the reset of the packet will be applied to. The command is stored in the first byte and can start from 1 to 255 giving the user the option to implement more commands to system. The following table lists the command set used to establish communication between the Embedded System and the GUI:

Table 4: Command set used between GUI and Embedded System

ID Function Usage 1 Display the packet contents on the LCD Display Communication 2 Start UDP streaming UDP Enable 3 Stop UDP streaming UDP Disable 4 Send back current status Communication 5 Send the contents of the Packet to the serial port Serial to Ethernet 6 Packet contains LED status Communication

Results:

We can build/design a full embedded system that is capable of using Ethernet technology and small enough o fit our budget on one or two chips. The use of Real Time



Operating System, RTOS was not necessary but it will add a complication to the embedded system and can be eliminated depending on the complexity of the system being designed.

Graphical User Interface, GUI:

To make great applications of this embedded system a well designed graphical user interface “GUI” is necessary to demonstrate all the fantastic futures of heaving a network enabled embedded system. For this important task, a general GUI was designed to illustrate the countless futures and flexibility the network embedded system can offer.

In this GUI, a new protocol and handshaking was developed and introduced to provide the communications between the PC and the embedded system.

Features are:

Table 5: Protocol Description

ID Protocol Number Description 1 01 Print out what we received to LCD 2 02 Start streaming UDP values 3 03 Stop streaming UDP values 4 04 Send back current status 5 05 Recieve what I need to send to the serial port 6 06 Received LED status

Interfacing to Excel and producing a data log file:

As a real-time embedded system that can provide real-time information and measurements, a data logger was created to allow the operator to make use of all these measurements and insert it into a spread sheet. Through the GUI interface an option was added to log the contents of UDP packets that contain values that represent ADC measurement of connected devices to the embedded system. These values are stored in a data file with comma delimited format that MS Excel is capable of reading and sorting. User can easily make use of these data and create any graphs or use them for any lab data sheets.



Bibliography:

[1] Renesas Technology http://www.renesas.com/ [2] Microchip http://www.microchip.com/ [3] Rabbit Semiconductor http://www.rabbitsemiconductor.com/ [4] Freescale “Motorola”, http://www.freescale.com/ [5] SMSC Embedded Ethernet controller LAN91C111-NE http://www.smsc.com/ [6] Moore, Ralph. The link Service routine for better interrupt handling

http://www.smxinfo.com/articles/lsr_art/lsr_art.htm [7] Garcia, Gerardo. 2007. Choose an RTOS for High Speed. Embedded Systems Design.

Volume 20, Number 11 [8] Bilek, Jan. 2003. Evolutionary Trends of Embedded Systems. IEEE. [9] Pereira, Dias. 2006. A Low-Cost Tide Measurement System for Water Quality

Assessment. IEEE. [10] Gracanin, Denis., Tsourveloudis, Nikos., Matijasevic, Maja and Valavanis, Kimon.

1999. Virtual Reality Test bed for mobile Robots. IEEE. [11] Wu, Helei., Ming, Jing., Yang, Yirong., Zhu, Shanan. 2004. Integrating Embedded-web

technology and Real-Time Ethernet for Modern Distributed Control. IEEE. [12] Li, Dan., Zhong, Chongquan., Yuan, Ziaofeng., and Zhang, Li. 2006. Study on

Embedded Equipment Web Monitoring and Control Based on Industrial Ethernet. IEEE.

Biography

Hesham Elsaghir was born in Alexandria, Egypt, the son of Kadria Nour-Eldin and Mohamed Elsaghir. Started the under graduate degree as a part time student in NVCTC, Trinity college, then entered university of Hartford, college of Engineering. He received his degree of Bachelor of since in Electrical engineering with concentration in computers in Dec, 2004.

During the following years he was employed as design engineer at Control Module Inc, then Pyramid Technologies LLC. He attended the University of Hartford, school of engineering for his Graduate degree while working as a design engineer.

http://www.renesas.com/

http://www.microchip.com/

http://www.rabbitsemiconductor.com/

http://www.freescale.com/

http://www.smsc.com/

http://www.smxinfo.com/articles/lsr_art/lsr_art.htm

Documents

Proof of Concept Implementation of Embedded Ethernet System