Embedded Networking

There are a few main types of embedded net processors to consider:

• low-level ethernet controllers
• serial-to-ethernet converters
• semi-autonomous (but limited) net processors
• single board computers

At the lowest level are ethernet controllers themselves. An ethernet controller is just a microprocessor that's specialized to receive incoming ethernet data packets and deliver them to another microcontroller for interpretation. The EE-100 from embeddedether.net, the embeddedethernet board, and EDTP's packetWhacker are all examples of this. They all take in ethernet packets and deliver them, unprocessed, to a microcontroller. In order to use them, you need to have a thorough understanding of the ethernet protocol and any higher level protocols that rely on it, such as TCP/IP, HTTP, and so forth. These controllers aren't much good for the beginner, but if you're looking to see every byte that goes across an ethernet network, and have a lot of time to learn to interpret it, they can be useful.

Serial-to-ethernet controllers are lightweight devices designed to be used with a separate standalone processor. They have an ethernet connection and one or more serial connections, and act as a bridge between them. Like the ethernet controllers, they're not programmable, but they are configurable. Typically, each serial port can be assigned a TCP or UDP port number so that other network devices can connect to them. They can't process data themselves, other than to extract the data from within an ethernet packet. The baud rates and other parameters of the serial ports are also configurable. Lantronix makes a number of these devices. We'll be using their Cobox Micro in the Networked Objects class.

Semi-autonomous controllers are slightly more advanced than serial-to-ethernet controllers, in that they can serve as independent processors for specific applications. NetMedia's Siteplayer is a typical example. It's a web server on a chip, with a limited I/O port and a serial port, and a little bit of RAM. It can serve a small amount of data via HTTP, and can pass data to and from its serial port and its RAM using UDP. It's still mostly a coprocessor, though, and needs to be attached to a microcontroller if you want to initiate any action from the physical world.

Finally, there are standalone net processors and single-board computers. These are more similar to desktop and server machines than microcontrollers. They have operating systems, sometimes even disk drives and other peripherals that you expect from general purpose computers. Many of them run stripped-down versions of linux, or Windows CE. They are the most expensive of the embedded computers, but the most versatile. Currently, they are beyond the scope of the Networked Objects class, but if you want to pursue them, you'll be working independently of the class lessons, for the first half of the semester.

The advantage to the lightweight approach is that you can concentrate your work on a microprocessor and/or on the back end of a web server, where you may be more familiar with the environment. The advantage of the kitchen sink approach is that you may be able to do everything on one platform.

A few examples of networked coprocessors:

Siteplayer is a web server coprocessor by NetMedia, the same folks who make the BX-24. Initially, it was not intended as a standalone processor, so it's not good at complex tasks. Further revisions of the siteplayer will make it capable of more complex tasks. It works well in conjunction with more complex processor like the BX-24. It has a TTL serial port to communicate with such a processor, an ethernet I/O port to communicate via ethernet, and eight I/O pins for connecting sensors, driving motors, etc. The Siteplayer is essentially a passive device. It responds to request for web pages, and it responds to requests from a processor attached to the serial port, but it can't initiate any action itself. It is very useful as a tool to send short messages between a microprocessor and a network server, or as a tool for peer-to-peer networks between microprocessors, because of its ability to send and receive UDP messages relatively easily. In addition, the web interface of the siteplayer makes an excellent diagnostic and calibration tool for networked objects.

The CoBox Micro from Lantronix is another embedded network processor. It's designed primarily as a serial-to-ethernet converter. It's more limited than the TINI or the Siteplayer in many ways, but it's useful as a network co-processor for a microprocessor, and it's simple to set up.

Unlike the Siteplayer, the CoBox Micro has no configurable web interface, so users can't access it directly from the web. However, you can write an interface on a remote server, in whatever environment you want (HTML & CGI) to access it via a browser. If your application doesn't need browser access, you can skip that and establish TCP/IP socket connections to it directly.

The CoBox Micro is not programmable. It's just a connector, essentially, between some serial device (say, a microprocessor) and a remote internet application. This means that either the micro or the remote application have to do all the work. It also means that getting the two of them talking to each other through the CoBox is relatively transparent.

The Cobox's advantage over the siteplayer is its ability to accept and initiate TCP socket connections. This is useful when there needs to be a long or complex exchange of data between a microprocessor and another networked device. For applications where many devices are frequently talking to each other, however, this can be inconvenient, as it means having to start and stop a socket for each message.

With many embedded networking ideas, the principle can be illustrated by combining a non-networked microcontroller such a the BX-24 and a normal desktop computer set up to act as a server. By breaking the interaction design into pieces, it's usually fairly simple to determine an effective method of prototyping the idea, even if you don't have a tiny server.

Start by breaking the problem into pieces:

What is the intended transaction?

Who or what initiates the action (i.e. what is the input)? Data in a database? Ambient conditions in a remote area? Specific actions by a distant user or users? A combination of all of these?

How best to collect that input and convert it into digital data?

What is the output? What is the best tool to realize that output?

What processing has to happen between input and output?

Does the initiating actor need to see the output? If not, who does? What feedback loop is there between the input and output? How much time can pass between input and output (i.e. how tight does the feedback loop have to be)?

What tools are available to connect the input and output and do the processing in between?

Can the network chosen support the requirements of the feedback between input and output?

In some cases, the feedback loop may be so tight that networking introduces too much delay. If so, consider ways to have that feedback loop happen without the network, using data from elsewhere as a catalyst to the loop rather than a link. For example, perhaps the sensor and actuator are all in the same place, but the action sensed by the sensor is merely amplified or attenuated by changes from a remote location.

Once you have a plan of what has to happen, you can decide where to begin prototyping. If you're using a desktop server or client as the network interface, you need to consider how the application that talks to the viewer and the program that talks to the network talk to each other. Usually the client has to use the serial port or some other external port. The server needs to get data from the client and send it over the network. This task is often less processor-intensive, and you can get away with something that sits in the background moving bits around, like a server program.

If the data is published infrequently, in batches to the network, a simple server program such as is built into the Mac and Windows operating systems will do. Just have your interface program read or write a file every once in awhile in a directory where the server can serve it. In this case, the input side of the project can be relatively static, just gathering data and publishing it to a file to be served to a server.

Consider having a small application that grabs data from the network on a regular basis. This would be a Common Gateway interface, or CGI. For example, a simple Applescript, Director, Perl, Processing, or Flash application could be written to grab data from a simple device (like a Cobox Micro or a Siteplayer) and pass that data out the serial port to a microprocessor.

If the data has to be sent constantly, you're probably going to need an application that can open a dedicated socket to another computer. Java, Processing, Director (using the Multi-user server) and Flash can handle this. All of these except Flash can also talk to the serial port, which is useful if you're using a microcontroller for final input or output.

If your interaction plan is modular, the applications you write on a desktop machine to prototype it will generally be very simple programs, and easy to replace on an embedded processor when you decide to make that move. Make a point of simplifying the data sent at any given time, so that no part of the system is doing more work than it has to. Ultimately, a simpler system is a more transparent system.