Ethernet has migrated from PCs to embedded systems, a much more constrained environment. It can bring a lot of capabilities if you’re careful about its implementation
Embedded Ethernet
Ethernet has become a reality for low-cost embedded systems. The Ethernet standard (IEEE 802.3) was originally designed for networking computers over local area networks (LAN), but it has since been adapted for other purposes. Today it has become so popular that it is hard to find a PC or laptop without an Ethernet port. Now this capability is migrating to the embedded world, where the ColdFire? family excels. The IEEE 802.3 specification defines a mechanical/electrical connection between devices (physical layer) and a multi-node addressable communications protocol (Media Access Control — MAC — layer).
Ethernet physical layer
The Ethernet physical layer (PHY) defines the physical connections between nodes. The 802.3 standard defines many physical layers, including everything from coaxial cable to fiber optics. Through the years, the most common choice for this purpose has changed drastically from thick multi-strand cables with large connectors (called thicknet) to the small RJ-45 8-pin connector we use today.
The common modern copper physical layer is referred to as 100base-TX (a type of 100base-T). This copper-based twisted-pair medium contains eight wires grouped in four twisted pairs. Two twisted pairs are used for communication in each direction. The cable is referred to as a category 5 (cat 5 for short). The category 5 standard defines a cable consisting of four twisted pairs capable of carrying frequencies up to 100 MHz.
ColdFire Ethernet for Diverse Applications/TZM112_Coldfire_Ethernet_Fig_1.jpg" alt="Figure 1: The Modern Ethernet Jack."/>
Figure 1: The Modern Ethernet Jack.
Most Ethernet embedded devices have integrated MACs (discussed in the next section) with external PHY. ColdFire offers a seven-member family of microcontroller units (MCU) with integrated MAC/PHY called MCF5223x.
Most modern buildings and residences are wired using category 5 cables for their PC networks and broadband, making this an ideal medium for distributed processing/sensing in a building or residential environment.
Ethernet MAC layer
The MAC protocol layer defines the communication that occurs over the physical layer. Ethernet is a multi-node protocol, so each node has a unique address. This address is defined in the MAC layer. In Ethernet communication, MAC addresses are 48 bits long (six bytes, or octets). The device’s MAC address never changes — usually it is programmed at the factory. The MAC address must be unique, so MAC addresses are managed and distributed by the IEEE.
The MAC address, along with various other fields, is contained in the Ethernet MAC header. As the name implies, the header sits in front of the Ethernet packet. It contains the MAC address of the source node, the MAC address of the destination node, and a type field.
| Preamble | Destination Address | Source Address | frame Type | frame User Data | frame User Data |
| 8 Bytes | 6 Bytes | 6 Bytes | 2 Bytes | 46-1500 Bytes | 4 Bytes |
Figure 2: Ethernet MAC header.
Ethernet can be used directly without any additional layers. It provides a simple point-to-point communication mechanism, with some error checking (FCS checksum). Ethernet by itself does not provide the high degree of communications robustness of which we have become accustomed. Additional layers are required to add features such as multiple ports, packet re-transmission, packet timeouts, and connections. These additional layers are defined by the seven-layer OSI model.
Seven-Layer OSI model
The seven-layer OSI model defines the functions of the various layers in a communication stack. The lowest layers (physical and MAC/data link layers) are traditionally implemented in hardware. The five layers above the MAC/DDL are usually implemented in software.
The network or IP layer (for a TCP/IP stack) provides an additional layer of addressing (IP addresses in the hexadecimal format of xx.xx.xx.xx) and multiplexing. Multiplexing splits a single communications channel into multiple time-divided communications channels (ports, in TCP/IP terminology).
The transport layer adds the most critical feature to the communication stack. TCP (transmission control protocol) is one of the transport layers in TCP/IP. This layer is responsible for creating a virtual connection between two logical points (not nodes). The logical points are referred to as sockets. The socket’s API is actually defined by the session layer.
Last, at the highest level, is the application layer. This application defines the common protocols used on the Internet: HTTP, SMTP, and TFTP. This layer can also be used for custom protocols.
ColdFire Ethernet for Diverse Applications/TZM112_Coldfire_Ethernet_Fig_3.jpg" alt="Figure 3: Seven-layer OSI model."/>
Figure 3: Seven-layer OSI model.
ColdFire family of microcontrollers
The ColdFire family of microcontrollers is based on the 32-bit ColdFire core is available in four varieties, each a superset of the core below it. The cores are completely scalable, with the differences consisting of additional instructions or add-on modules (for instance, MMU) and longer pipelines to increase frequency and performance for demanding applications. The current V1 core contains the base register and instruction set. The V2 core adds additional instructions and addressing modes to the V1 core, along with an optional eMAC (Enhanced Multiply/Accumulate unit).
![]( "<a title=")
ColdFire cores: scalable instruction sets, features and performance" src="~/media/Images/Article Library/TechZone Articles/2011/April/ColdFire Ethernet for Diverse Applications/TZM112_Coldfire_Ethernet_Fig_4.jpg" alt="Figure 4: ColdFire cores: scalable instruction sets, features and performance."/>
Figure 4: ColdFire cores: scalable instruction sets, features and performance.
Advantage of a 32-bit architecture
The true 32-bit architecture of ColdFire microcontrollers lends itself well to efficient communication stack data movement. In a communication stack such as TCP/IP, the packet comes in at the bottom of the stack and propagates up. Data to be sent starts at the top of the stack as a buffer, and then works its way to the bottom of the stack to be sent out as a packet.
Movement up and down the stack is an area of inherent inefficiency in a communication stack. To improve efficiency, higher-performance stacks use pointers instead of copying the data multiple times (this is sometimes referred to as zero copy). Pointer arithmetic is significantly more efficient with a 32-bit core using true 32-bit registers. This is a big advantage for the ColdFire 32-bit architecture.
In addition, extracting data from individual fields in a header can become a single-instruction operation by using advanced addressing modes with offset capability.
Figure 5: Seven-layer OSI model with communication stack overlaid on top.
ColdFire Fast Ethernet Controller (FEC)
The FEC module is the ColdFire interface to the Ethernet world. The FEC module is consistent from the highest-performance V4-core-based part all the way down to the V1 core. This consistency means that drivers written for one Ethernet-enabled ColdFire processor will work on any Ethernet-enabled ColdFire processor (memory allocation would be the biggest difference).
The FEC module is a high-performance Ethernet engine with a very rich heritage. The FEC module started out in the MPC860T. This high-performance, Power Architecture-based processor quickly became a powerhouse in the Ethernet world, going into high-performance routers and telecommunication equipment. The MPC860T was so popular in the Ethernet world that if you make a call today, chances are that somewhere along the way the voice data of your call will pass through an MPC860T.
The MPC860T came out in the mid-1990s. The FEC module has been tested and improved upon for over ten years in some of the highest performance Ethernet environments. The FEC module from the MPC860T is now in the ColdFire line of processors.
ColdFire FEC features
Ethernet MAC is designed to support 10 Mbps and 100 Mbps Ethernet/IEEE 802.3 networks
IEEE 802.3 full-duplex flow control
Support for full-duplex operation (200 Mbps throughput)
Retransmission from transmit FIFO after a collision (no use of processor bus)
Automatic internal flushing of the receive FIFO for runts (collision fragments) and address recognition rejects (no use of processor bus)
Address recognition
-frames with broadcast address may be always accepted or always rejected
-Exact match for single 48-bit individual (unicast) address
-Hash (64-bit hash) check of individual (unicast) addresses
-Hash (64-bit hash) check of group (multicast) addresses
-Promiscuous mode
Dedicated DMA controller to allow for packet transmission and reception with no processor overhead.
The Fast Ethernet Controller supports both 10 Mbps and 100 Mbps, allowing ColdFire to interface with both old (10base-T networks) and newer (100base-TX) networks (with the appropriate 10/100 PHY). Full-duplex operation means that packets can be sent and received at the same time (remember the PHY uses separate wires for TX and RX). At 100 Mbps this translates to a maximum 200 Mbps throughoutput.
The hardware performs all the functions of the 802.3 Ethernet MAC layer without software intervention. The software simply initializes the FEC, writes the node’s MAC address into the MAC address register, and initializes the RX and TX buffer rings. The FEC will automatically receive, process, and verify (via CRC) incoming packets, and DMA the packet into an RX buffer. For TX, the FEC is triggered by software, and then automatically DMA’s the packet from the TX buffer, calculates a CRC, serializes the packet, and sends it out to the PHY. If a collision is detected, the FEC will perform a random back-off and retry without processor intervention. After the packet is transmitted, the FEC reports a status.
The advantage of this high level of functional integration into the FEC is reduced software overhead. The software simply has to create the packet and give it to the FEC for transmission via the TX ring buffer. On the receive side, the software simply has to take the packet from the RX ring buffer. The ring buffers are managed by the FEC hardware.
ColdFire TCP/IP stack
TCP/IP is the communication protocol of the Internet. The name refers to two layers of the communication stack: TCP and IP. The term TCP/IP actually describes multiple protocols within the two layers. Each protocol is defined by an IEEE RFC (Request for Comment).
Proper TCP/IP stack operation requires multitasking. The ColdFire TCP/IP stack is integrated with a simple multi-tasking operating system. This simple round-robin OS can also be used by the application code. The OS is non-preemptive, but does provide two modes of operation (single-stack (super-loop) and multi-stack). Additional OS features include an interactive real-time upgradeable menu system, user timers, and heap memory management.
ColdFire TCP/UDP/IP stack features
HTTP (Hypertext Transfer Protocol), Serial-to-Ethernet Gateway, TFTP (Trivial File Transfer Protocol)
Mini-IP Application Interface
DHCP (Dynamic Host Configuration Protocol) or manual IP
configuration, DNS (Domain Name System)
TCP (Transmission Control Protocol), UDP (User Datagram Protocol)
ICMP (Internet Control Messaging Protocol), BOOTP (BOOTstrap Protocol)
ARP (Address Resolution Protocol), IP (Internet Protocol)
Figure 6: ColdFire TCP/IP stack and RTOS.
The TCP/IP stack implements the protocols described in these RFCs (please refer to www.rfc-editor.org/rfcxx00.html for details):
RFC 791: Internet Protocol (IP)
RFC 792: Internet Control Message Protocol (ICMP)
RFC 768: User Datagram Protocol (UDP)
RFC 793: Transmission Control Protocol (TCP)
RFC 826: Ethernet Address Resolution Protocol (ARP)
RFC 1035: Domain Names - Implementation and Specification (DNS)
RFC 2131: Dynamic Host Configuration Protocol (DHCP)
RFC 2132: DHCP Options and BOOTP Vendor Extensions
The session/presentation layer is a mini-socket interface similar to the familiar BSD (Berkeley Software Distribution) socket interface. The stack has been optimized for embedded applications using zero-copy functionality for minimum RAM usage.
Figure 7: ColdFire TCP/IP stack details.
DHCP client
The Dynamic Host Configuration Protocol (DHCP) is used to acquire network parameters at runtime. The DHCP protocol is defined in RFC 2131 and RFC 2132. The stack runs a DHCP client which searches for a DHCP server (this is referred to as discovery).
Packets are transferred using the UDP layer and BOOTP ports (67 and 68). Because the IP stack does not have an IP address yet, discovery is done using strictly broadcast addresses. Included in the discovery packet is a unique transaction ID (xid). A listening DHCP server sends an offer message containing the xid sent by the client and the suggested network parameters, again using broadcast addressing. Encoded in the offer is a unique server ID. The client will use this server ID when sending a request packet back to the server, indicating that it accepts the network parameters that were offered. Finally the server ACK’s the client using its new IP address.
DNS client
The DNS client is used to communicate with the DNS (Domain Name Server). The purpose of the DNS system is to translate domain names into IP addresses. The DNS protocol is described in RFC 1035. DNS can use UDP or TCP, with port 53. The DNS protocol is stateless — all the information is contained in a single message. This message is fully documented in RFC 1035.
Available examples and application notes
All application notes mentioned in this article are available at www.freescale.com.
HTTP web server and flash file system
The HTTP web server and flash file system are described in detail in application note AN3455, ColdFire Lite HTTP Server.
The features are:
HTTP 1.0 compliant server with connection persistence and multiple sessions
Multiple HTTP connections supported
Flash file system which supports both ColdFire internal flash and external SPI flash
Web pages can be updated in flash over Ethernet or built in at compile time
HTTP GET method supported, with a simple mechanism for adding other methods
Dynamic HTML (Hypertext Markup Language) support with replace and conditional tokens
Serial interface support for Dynamic HTML variables
Run-time and compile-time flash file systems
Long filename support with subdirectories
“DIR” command supported on serial interface
PC utilities for compressing compile-time and run-time downloadable images of multi-page web pages
PC utility for downloading run-time downloadable web page image through port 80 (to get through firewalls)
32-byte ASCII key for web page download security
UDP/TCP clients and servers — Example source code
The ColdFire Lite stack project includes almost a dozen built-in usage examples. These examples are designed to highlight various features in the stack and demonstrate how to use them. The TCP/IP stack and RTOS, along with all the sample applications listed below, are discussed in AN3470, ColdFire TCP/UDP/IP Stack, and RTOS. Code examples include:
ColdFire_Lite
Barebones TCP/IP stack
ColdFire_Lite_RTOS
How to use the RTOS application
ColdFire_Lite_TFTP
TFTP server application
ColdFire_Lite_UDP_client
UDP client application for UDP performance testing
ColdFire_Lite_UDP_server
UDP server application for UDP performance testing
ColdFire_Lite_TCP_client
TCP client application for TCP performance testing
ColdFire_Lite_TCP_server
TCP server application for TCP performance testing
ColdFire_Lite_TCP_serial_client
TCP to serial/serial to TCP client
ColdFire_Lite_TCP_serial_server
TCP to serial/serial to TCP server
ColdFire_Lite_TCP_with_Web_Server
Web (HTTP) server with dynamic HTML
ColdFire_Lite_TCP_alarm
The alarm demo application includes both PC-side and ColdFire-side firmware. This code is an example of a remote sensor application, where a remote sensor periodically sends data over TCP to a host server.
Figure 8: ColdFire TCP alarm.
HTTP client firmware
The HTTP client provides the ability to read web pages and XML data from the Internet using a ColdFire processor. The HTTP client uses the DHCP client to automatically acquire an IP address and other TCP/IP information, including the IP address of any DNS server. Then the HTTP client uses the DNS client to translate any user-provided URLs into IP addresses.
The HTTP client uses the GET method to request a page from the server. Along with the GET request is the HTTP header. The HTTP header is hard-coded in the HTTP client via constant strings declared in the file emg_http_client.c.
Wget command – An example of using the HTTP client
The Wget command is a command often found in Linux distributions that transfer files using the HTTP protocol. The Wget command is a console-based HTTP client. Using the menuing system provided by the ColdFire TCP/IP stack (explained in application note AN3470) and the HTTP client, Wget functionality can be added to the ColdFire TCP/IP stack.
RSS/XML character data filter
To extract the character data (the information you actually want to read) from the RSS stream, all the meta-text must be filtered out. Any valid HTML must be translated and processed. For instance, the HTML tag that causes a line break is
. This would appear as
in the RSS stream. The filter must correctly translate
into a carriage return and line feed.
Other HTML tags that are routinely embedded in character data include paragraph tags
and image tags. In the stream these tags appear as
and ![]()
respectively. The paragraph tab can be translated to a carriage return and line feed, but the image tag must be ignored unless the embedded system can process images.
The filter takes in an XML or RSS data stream and a list of tags. It outputs only the character data from the selected tags. The tag list is an array of pointers to those tag strings that need to be filtered. Normally the filter returns 0. When the filter processes the “>” in a tag in the list, it returns to the filter array the index + 1 for the tag that it found. Example: after detecting a Title Tag in an RSS or XML stream the filter will return 1. After detecting a tag in a stream the filter will return 2. Normally the filter returns 0.
Example embedded appliance — RSS/XML feed reader
The RSS/XML feed reader is an embedded appliance that allows users to display and even hear real-time content from the World Wide Web. The purpose of the embedded appliance is to provide instant real-time information without booting a PC. There are many types of real-time data available on the web; weather data (current and forecast), online DVD queue data, online auction data, sports score data, real-time news data, real-time stock data, medical and health data, and much more. All this data is available on the webaseither an XML feed or an RSS feed. This appliance connects to the web, gets the desired feed, and parses the text information or character data from the feed. That data is displayed on the LCD, sent to the serial port, and spoken through the speech processor.
For complete details on the RSS feed reader, please see AN3518, Advanced ColdFire TCP/IP Clients.
Figure 9: The RSS/XML feed reader.
M52233DEMO board from Freescale Semiconductor
The M52233DEMO board is a reference board used to evaluate Freescale’s ColdFire MC52233 processor. The inexpensive board includes a serial port, USB BDM debug port, and Ethernet port. The board along with the free CodeWarrior tools (up to 128K of flash) are all you need to get up and running on your Ethernet projects. Freescale provides a free public source TCP/IP stack on their website. This TCP/IP stack is what the application in this article runs on. The ColdFire TCP/IP stack is documented thoroughly in application note AN3470.
The demo board includes a 40-pin header fiving the use access to most of the Coldfire signals, a 3-axis accelerometer, a potentiometer, and two user buttons.
LCD
The parallel LCD is a 4 × 20 character display that uses the standard Hitachi instruction set. The LCD is used in its 4-bit mode, requiring only six connections to the micro, the 4-bit data bus, a clock signal (E), and a register select line (RS). The firmware also includes a library to drive the LCD.
Voice synthesizer
The RC Systems V-Stamp voice synthesizer is an easy-to-use, text-to-speech processor. The V-Stamp is a fully self-contained module, requiring only power, a speaker, a resistor, two capacitors, and a serial connection to an embedded system. The V-Stamp communicates with the embedded system using a UART. The module automatically sets its baud rate to that of the embedded system. From both a hardware and firmware point of view, there is very little work required to add the V-Stamp module to the RSS feed reader.
Firmware
ColdFire Ethernet for Diverse Applications/TZM112_Coldfire_Ethernet_Fig_10.jpg" alt="Figure 10: Firmware block diagram."/>
Figure 10: Firmware block diagram.
HTTP
HTTP is the communication protocol of the World Wide Web. HTTP is used to transfer web pages (hypertext documents) across the Internet. An HTTP connection has two parts, the HTTP client (web browser), and the HTTP server. The HTTP client is used to receive and view the web pages. The HTTP server is used to store, organize, and transfer the web pages.
ColdFire Ethernet for Diverse Applications/TZM112_Coldfire_Ethernet_Fig_11a.jpg" alt="Figure 11."/>
HTTP is defined by RFC 1945 and RFC 2616. RFC 1945 defines HTTP 1.0, and RFC 2616 defines the latest version, HTTP 1.1.
HTTP is a request-response protocol. The client requests a web page from the server and the server responds with the web page contents. HTTP can be used to send any type of data, including binary data. The client requests a file using the GET method (HTTP is an ASCII protocol). The server responds with an HTTP header followed by the file contents. Within the request, the version number of the HTTP is also embedded in ASCII. This tells the server the limitations of the client.
Figure 11: HTTP communication protocol.
Really Simple Syndication (RSS)
RSS feeds are available everywhere on the Internet. The idea behind the RSS feed is to convey dynamic textual information in a simple standard format.
RSS originated in 1999 with the idea of providing content in a simple easy-to-understand format. Instead of describing a complete document in the way that HTML does, RSS feeds use XML to describe data. An RSS feed is simply an XML document containing data. The methods used to convey the data within the XML document are described in the RSS 2.0 specification. All RSS files must conform to the XML 1.0 specification. RSS feeds generally use HTTP as the transport mechanism.
Extensible Markup Language (XML)
The XML 1.0 specification can be found at www.w3.org/TR/REC-xml/.
XML is a language used to describe and parse information. It is very similar to structures in C.
Data is organized into elements, with each element assigned to a tag. The data in the element is surrounded by a start tag and an end tag. The name in the start and end tags defines the element’s type. The end tag name must be the same as the start tag name, except the end tag is identified by the addition of a “/” before the tag name.
Tags
Here is an example of an XML tag:
TITLE is the type,is the end tag. The data is between the tags. Just like a C data structure, the data is associated with the type. The data between the start and end tags is referred to as the element’s content.
Elements can contain other elements, which provide a method of grouping data of different types under a single name. Just like a C structure, the particular piece of data is referenced by specifying a path to the data. a single name. Just like a C structure, the particular piece of data is referenced by specifying a path to the data.
Special characters and escape sequences
The “&”, “
