|Microcontrollers such as the BasicX microprocessor, the Basic Stamp, and the PIC have opened up many new possibilities because they've given us the freedom of physical design that working directly with a microprocessor allows without having to learn a great deal of low-level programming and electrical engineering. Being able to think about and prototype physical interface design directly, without having to work through a full engineering process, has made the design process much more spontaneous. Any set of design tools introduces limitations, however, and the these tools are no different. Physical computing projects (based on the Basic Stamp, PIC, or BX-24) have tended to be about things that these processors do well: reading sensors, controlling simple actuators, or communicating serially to a local desktop computer to control multimedia. Up until recently, however, few microcontroller-based projects took advantage of the Internet, because there were not many higher-level prototyping tools available that made it easy to connect to the net. These notes are an attempt to address that by introducing some processors for embedded networking, and some techniques for prototyping physical interface design for networks.||Links from my 2004 E-tech talk are here.|
There are a few main types of embedded net processors to consider:
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 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. Dallas' TINI, the various boards from Mini-ITX, Soekris, and Kontron are typical examples.
|For more on the TINI, see the TINI interest group pages.|
|Prototyping embedded networking ideas on the desktop
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.