The Power of 802.15.4 and Ethernet

802.11 networks and 802.15.4 networks, for the most part, have the same type of structure. They are usually star or point-to-point networks. A star network might have many end devices communicating to one gateway or network bridge.

Figure 1: 802.11 Network Configuration

Figure 2: 802.15.4 Network Configuration

When comparing the network topology of an 802.11 system (Figure 1) with an 802.15.4 network (Figure 2), we see that the 802.15.4 IP network needs an extra bridge device or gateway to convert 802.15.4 wireless messages into IP-based messages, whereas the 802.11 network connects directly to the IP infrastructure.

So if an 802.11 device can connect directly to the IP network, why even consider using 802.15.4 technology that requires an extra bridge? The reasons are cost, power consumption, and complexity.

Cost Using embedded Wi-Fi usually requires a higher-end microcontroller or microprocessor to avoid a bottleneck of messages in 802.11 traffic. Bigger, better processors are more costly.

Power consumption An 802.11 system needs a constant connection to allow data to get through, and this involves much more power consumption. Although 802.11 systems can be designed to shut down their connections when they aren’t being used, whenever any communication needs to be done, the system must take the time to reconnect; this reconnection uses precious energy.

Complexity Because an 802.11 connection is a constant wireless link, more complex software is required to handle cases in which the connection is dropped. With 802.15.4 there is no connection that needs to stay open – the end device can just wake up, send its message, wait for an acknowledgment, and then go back to sleep. This allows the device to transmit at higher power levels (which means a longer range) and save more power by spending less time with an active RF connection. This simple wake up / send a message / go back to sleep technique allows for a much simpler system. And the simpler the system, the smaller the processor needed to make the system work, which means a savings in cost.

The Firmware

Let’s take a look at what’s required for a reliable 802.15.4-to-Ethernet device to function as a gateway for all 802.15.4 traffic. The first requirement is an Ethernet-enabled microcontroller. Several companies make small, cost-effective microcontrollers that can handle 802.15.4-to-Ethernet bridging. The ARM Cortex-M3 microcontroller family provides a great solution, and manufacturers provide these with a built-in Ethernet MAC and PHY. The microcontroller also needs a UART, SPI, or I2C interface to communicate to an 802.15.4 wireless module or IC. Once the hardware has been picked, it’s all up to the firmware to do the job of bridging the 802.15.4 messages to the Ethernet interface.

Running Ethernet on an embedded system requires a TCP/IP stack to handle all low-level Ethernet data. The TCP/IP stack provides an easy-to-use interface for sending and receiving TCP or UDP messages without having to understand or develop the low-level Internet protocol messages. A great reliable TCP/IP stack that can be used on embedded systems is lwIP¹. lwIP features full TCP, UDP, and DHCP functionality. Best of all, it is an open source project and, being licensed under BSD, it is free to use. It is written in standard C, and the user is only required to provide the low-level functions to initialize and use the Ethernet interface on the specific processor. lwIP provides a very easy-to-use socket-based API to send and receive IP messages.

The following example shows how to create a UDP connection and send UDP data in lwIP.

Once the device has an operational Ethernet port and communication to the 802.15.4 module or IC is working, the message flow must be tied together with some sort of task scheduler or simple operating system. FreeRTOS² is a free open source real-time operating system designed for embedded processors. It has a great task and queue system for managing the flow of data on an embedded system. There are also many ports for a variety of processors already available to get FreeRTOS up and running fast.

In FreeRTOS, tasks are used to accomplish work by the OS. The tasks (or threads) can run independently of each other in a parallel fashion to complete separate goals of the system. Even though the tasks seem to run at the same time, they are really executing one at a time, but the OS switches back and forth between the tasks at high speed so each task can do its work. This is known as context switching.

The following example shows how to create a task in FreeRTOS:

To easily pass data between different tasks, FreeRTOS uses message queues that allow data to be sent safely between tasks. The queues act as a first in / first out buffer system. Any data in a queue is placed there as a copy, not by reference. If large amounts of data need to be transferred between tasks, the queues should contain pointers to the data instead of the data itself. This will allow for much better performance, but the user’s application must keep track of what task is using the data to make sure it isn’t accessed by two separate tasks at the same time.

The following example shows how to create queues in FreeRTOS:

Remote Connectivity for Your Wireless Device with HTTP

As described above, bringing the power of Ethernet into your next 802.15.4 wireless design can be a cost-effective way to bridge the wireless world with the wired. Using Ethernet, developers can utilize the vast and proven IP infrastructure with their embedded designs and not be required to use high-end ARM processors. Advancing microprocessor design has enabled many low-end 8-bit and 16-bit microprocessors to handle this task.

So you decide to go with a low-end microprocessor and an IP stack. Now what? The whole purpose of putting an Ethernet stack on the device is to connect to it via Ethernet, but how? That is where HTTP (Hyper-Text Transfer Protocol) comes in.

HTTP can easily give your device the remote status, configuration, and control of your application that you desire. You can access your device from anything with a web browser, whether it is a PC, laptop, or phone, and you can access your device from anywhere in the world, check alarm status or up-time, or modify configuration settings. All of this may be easier than you thought to implement on low-end microprocessors.

How HTTP Works

In its simplest form, the HTTP 1.0 protocol is a request and response protocol between a client and server for data – usually web pages. The client sends HTTP request headers in ASCII form to the server, and the server responds with an HTTP response consisting of headers and possible data. Let’s take a look at an example:

An embedded Ethernet device is connected to your network and has completed the DHCP process to obtain an IP address: 192.168.1.50. You, the client, open up a web browser (Internet Explorer, Chrome, Firefox, etc.) and in the URL navigator type "http://192.168.1.50". Your browser automatically performs the TCP connection and sends an HTTP request to your embedded device for "/", the root default file. This is what that request may look like:

The server receives this request, searches for the requested file, and returns HTTP request response headers to the client. If the file is found, the contents of the file are also returned after the headers. This is what the response from the server may look like:

Your browser processes this data and displays the HTML. The headers are not displayed, although they can be viewed via many third-party browser add-ons, plug-ins, or developer tools. The TCP connection is then closed by the server.

This is a very simple description of how HTTP works. Many details have been left out. Most modern browsers today use HTTP 1.1, which introduces the use of options requests, advanced cacheing, pipe-lining and persistent connections, to name a few, but for a simple embedded server, none of this is needed, and HTTP 1.0 can be used.

Additionally, even with HTTP 1.0, clients will often send a “Keep-alive” header to tell the server to keep its connection open. For embedded designs, this header is best ignored and the “Connection: close” header returned. In this way, the embedded server – which has limited TCP connections available – can better handle connections from multiple clients.

Requirements of an Embedded HTTP Server

As mentioned, advancements in 8- and 16-bit microprocessors have brought the possibility of running an HTTP server on an embedded device to the surface of many new designs. Picking out a microprocessor for any application can be a tedious process, so the following will attempt to break down the minimum requirements needed for various applications.

TCP/IP Stack

Since HTTP usually uses TCP as its transport protocol, the TCP/IP stack is the single most important requirement of an embedded server. Two notable open-source options are lwIP and uIP, but there are numerous others available.

Internal File System

Since the server is required to serve up files to the client, it must have a repository of files somewhere. For most basic applications, the files can be compiled and saved directly in Flash.

External File System

Even large microprocessors have limited memory, and HTML can be an extremely bloated mark-up at times. Couple that with style sheets and JavaScript libraries and a single page can easily require 100kb+ of memory. The need for external memory can become more important, depending on the needs of the device. A micro SD card is a cheap implementation that can easily provide this extra file system storage space, and the open-source FatFs driver library ports easily to many popular microcontrollers.

Static File Processing Logic

Application logic must exist on the server to accept incoming connections, process the received HTTP request headers, and return the contents of the requested file. The most basic processing logic must handle HTTP “GET” requests to serve up static (non-changing) content.

Dynamic File Processing Logic for SSI and CGI

To provide dynamic status and configuration of the embedded device, support for SSI (server-side includes) and CGI (common gateway interface) becomes necessary. To summarize, SSI provides a way to insert dynamically changing data (i.e., application variable values) into an HTML page, and CGI allows a client to request the server to execute a specific parameterized function.

Other Options

The optional requirements of an embedded HTTP server are endless and can be extended as far as required. For a better user experience, Comet could be implemented to provide a more “real-time” feel. If security is a concern, SSL or TLS can be implemented to ensure that your data transfer is private. The options are there; only the microprocessor limits the implementation.

Requirements by Application

Determining which HTTP server features you need is a process that’s specific to the application. The following attempts to detail three common applications for an embedded HTTP server and their requirements.