An increasing number of embedded systems are attached to general purpose networks. These devices, although more constrained than other computerized systems in many ways, are often expected to provide the very same network services found in many modern servers. Fortunately, Linux lends itself quite well to general purpose networks, since it is itself often used in mainstream servers.
The following discussion covers the networking hardware most commonly found in embedded systems. Linux supports a much wider range of networking hardware than I will discuss, but many of these networking interfaces are not typically used in embedded systems and are therefore omitted. Also, as many of these networking interfaces have been extensively covered elsewhere, I will limit the discussion to the topics relevant to embedded Linux systems and will refer you to other sources for further information.
Network services will be discussed further in Chapter 10.
Initially developed at Xerox's PARC research center in Palo Alto, California, Ethernet is currently the most pervasive, best documented, and least expensive type of networking available. Its speed has kept up with the competition, growing geometrically over the decades. Given Ethernet's popularity and the increasing demand for embedded systems to be network enabled, many embedded development boards and production systems have been shipping with Ethernet hardware.
Linux supports a slew of 10 and 100 Megabit Ethernet devices and chips. It also supports a few Gigabit Ethernet devices. The kernel build configuration menu is probably the best place to start to see whether your particular hardware is supported, since it contains the latest drivers list.[18] The Ethernet HOWTO, available from the LDP, also contains a list of supported hardware, and a lot of information regarding the use of Ethernet with Linux. Finally, Donald Becker, who wrote quite a few Linux Ethernet drivers, maintains a web site with information regarding Linux's network drivers at http://www.scyld.com/network/.
[18] You may also want to use this list as the basis of your hardware design, as I suggested earlier.
A number of resources discuss the use and internals of Ethernet. Charles Spurgeon's Ethernet: The Definitive Guide (O'Reilly) is a good starting point. Charles also maintains a web site containing Ethernet resources at http://wwwhost.ots.utexas.edu/ethernet/. One of these resources is the Ethernet FAQ based on postings made on the comp.dcom.lans.ethernet newsgroup. If you need to write your own Ethernet driver for your hardware, you will find the Linux Device Drivers book useful.
The Infrared Data Association (IrDA) was established in 1993 by 50 companies with the mandate to create and promote a standard for low-cost interoperable infrared data interconnections. The first IrDA specification was released in 1994 and continues to be maintained and developed by the association from which the specification takes its name. Today, IrDA hardware and software can be found in many consumer devices, including PDAs, cellular phones, printers, and digital cameras, to name a few. In comparison to other wireless schemes, such as Bluetooth, IrDA is inexpensive. This, in turn, favors its widespread adoption.
There are two main types of protocols within the IrDA specification: mandatory and optional. A device must at least implement the mandatory protocols in order to be able to interoperate properly with other IrDA devices. The mandatory protocols are the physical signaling layer (IrPHY), the link access protocol (IrLAP), and the link management protocol (IrLMP). The last protocol also includes the Information Access Service (IAS), which provides service discovery capabilities.
IrDA devices can exchange data at rates of up to 4 Mbps within a one meter range. Unlike other wireless technologies, IrDA requires directional pointing of the devices involved in a communication. An obvious advantage of such a scheme is the increased security resulting from the requirement that IrDA users keep their devices pointing in each other's direction during the whole connection time.[19]
[19] Any "intruder" would have to be in direct view of the users involved in the communication.
Linux supports all the mandatory IrDA protocols and many of the optional protocols. Figure 3-2 presents the architecture of Linux's IrDA subsystem.
IrPHY is the actual physical infrared device through which the data is transferred. It is usually located on the side of the device it is part of. In a PDA, for instance, it is often located on the top side of the device so the user can view the PDA's screen while pointing his IrDA port to that of another user's PDA or any other IrDA-enabled device.
The IrDA standard categorizes IrPHY devices according to their speed. There are currently three speed categories: serial infrared (SIR) at up to 115.2 Kbps, medium speed infrared (MIR) at up to 1.152 Mbps, and fast infrared (FIR) at 4.0 Mbps. In the future, very fast infrared (VFIR) at 16 Mbps should be part of the standard as well.
The Linux kernel includes the following drivers for SIR and FIR devices:
IrTTY provides support for 16550-UART-compatible IrDA ports. This driver uses the kernel's serial driver and provides speeds of up to 115200 bps.
IrPORT is a half-duplex serial port driver that is meant to eventually replace IrTTY.
To provide IrDA support for a system that doesn't have an IrDA port built into it, an IrDA dongle can be attached to the system's serial port. The kernel build configuration menu contains the complete list of serial dongles supported by Linux.
The kernel supports a number of chips found in on-board and bus-attached IrDA devices. The kernel build configuration menu contains the complete list of chips supported by Linux.
Like serial dongles, USB dongles provide a removable IrDA interface. Instead of SIR throughput rates, however, they provide FIR rates.
The IrDA stack operates on top of the device drivers to provide IrDA functionality in Linux. Most components of this stack are implemented as specified in the IrDA standard, but some components implemented are not part of the standard. These are the stack layers implemented in the kernel:
IrLAP is the link access protocol layer of the IrDA specification. It provides and maintains a reliable link between IrDA devices. In addition to the normal connection-oriented protocol, Linux supports connectionless exchanges using the Ultra protocol.
IrLMP is the link management protocol layer of the IrDA specification. It provides for and manages multiple connections over IrLAP.
Tiny Transport Protocol (TinyTP) implements flow control over IrLMP connections.
The Information Access Protocol (IAP) is Linux's equivalent to the IrDA's Information Access Service (IAS). As with IAS, IAP provides service discovery capabilities.
IrCOMM is an emulation layer that provides IrDA connection capabilities to legacy applications that usually communicate through common serial and parallel port devices. Since these types of functionalities are accessed through TTYs, applications use the kernel's TTY layer to access IrCOMM. Note that IrCOMM does not rely on TinyTP.
The IrDA specifies IrLAN to enable LAN-like connections between IrDA devices. IrLAN acts as a network device from the point of view of upper layer protocols. It is, for instance, possible to establish a TCP/IP network on top of an IrDA link using IrLAN.
IrNET is also meant to enable LAN-like connections between IrDA devices. Instead of implementing a full network device, as with IrLAN, IrNET acts as a very thin layer over which PPP can be used to provide a full network device. Note, however, that IrNET is not part of the official IrDA standard. Microsoft first introduced IrNET as part of their Windows 2000 IrDA stack, replacing IrCOMM and IrLAN. The Linux implementation is based on the same concepts found in Microsoft's IrNET and can interoperate with it.
The IrDA standard specifies IrOBEX as an HTTP-like service for the exchange of objects. OpenOBEX is the IrOBEX implementation for Linux. It consists of a user-space library that can be found at: http://sourceforge.net/projects/openobex/.
In conjunction with the stack layers, you will need user-space tools to operate Linux's IrDA capabilities. These tools are part of the IrDA Utils package. This package and many other IrDA-related resources are available through the Linux-IrDA Project web site at http://irda.sourceforge.net/.
For further information regarding Linux's IrDA stack and related tools and projects, you may want to take a look at the Infrared HOWTO available from the LDP. Also, Jean Tourrilhes, a major contributor to the Linux-IrDA project, maintains a number of very interesting Linux-IrDA pages at http://www.hpl.hp.com/personal/Jean_Tourrilhes/. Unlike other such standards, all the IrDA standards are readily available for download directly from the association's web site at http://www.irda.org/.
The 802.11 working group was set up by the IEEE 802 committee in 1990. The first 802.11 standard was published in 1997 and has been maintained and updated since then by the same group. The standard provides for wireless communication between computers using the 2.4 GHz (802.11b) and 5 GHz (802.11a) frequencies. Today, 802.11 is the wireless equivalent of Ethernet in terms of widespread adoption and mainstream support.
Although many traditional embedded devices were equipped with some form or another of wireless technology, recent embedded systems with 802.11 support are mostly user-oriented devices such as PDAs. Connecting such devices to an 802.11 network is akin to connecting a laptop or workstation to this type of network. Hence, you may use reference material discussing the latter and apply it to your 802.11-enabled embedded device with little effort.
Linux has extensive support for 802.11b hardware. For a complete list of all the supported 802.11 hardware and related drivers and tools, I refer you to Jean Tourrilhes' Linux Wireless LAN HOWTO found at his web site, http://www.hpl.hp.com/personal/Jean_Tourrilhes/. Support for on-board or non-PCMCIA bus-attached devices is included with the kernel and can be selected during kernel build configuration. Support for PCMCIA 802.11 cards, on the other hand, is part of David Hinds' PCMCIA package mentioned earlier in Section 3.2.3.
Since most 802.11 devices' operation is similar to that of Ethernet devices, the kernel does not need any additional subsystem to support them. Instead, most of the same tools usually used for Ethernet devices can be used for 802.11 devices once the appropriate device driver has been loaded and initialized. Nonetheless, there are tools required to address the particularities of 802.11, such as setting identification and encryption keys, and monitoring signal strength and link quality. These tools are available through the Wireless Tools for Linux section of Jean's web site.
In addition to Jean's web site, the Wireless HOWTO available from the LDP provides some background information on the use of wireless devices with Linux. If you intend to make extensive use of 802.11 devices, you may want to take a look at Matthew Gast's 802.11 Wireless Networks: The Definitive Guide (O'Reilly). It contains a thorough discussion of the technology and its use with Linux. You can also obtain copies of the actual standard from the IEEE. At the time of this writing, they were freely available for download in PDF from the IEEE's web site. Jean's web site contains the appropriate link, but you should note that the availability of these documents is subject to change, as is stated on the IEEE's web site.
Bluetooth was developed by Ericsson with help from Intel and was introduced in 1994. A Bluetooth SIG was formed by Ericsson, IBM, Intel, Nokia, and Toshiba. Today, the SIG has more than 1,900 member companies. Today, a wide range of devices such as PDAs and cell phones, are already Bluetooth-enabled with more on the way.
Bluetooth operates on the 2.4 GHz band and uses spread spectrum frequency hopping to provide wireless connectivity to devices within the same piconet.[20] Some have called it a "cable replacement" and others have called it "wireless USB." In essence, it enables seamless wireless communication between devices. Hence, Bluetooth devices do not need any configuration to become part of a piconet. Rather, devices automatically detect each other and advertise their services so that the other devices in the piconet can in turn use these services.
[20] Piconets are wireless networks comprising Bluetooth devices. Since Bluetooth devices can belong to more than one piconet, piconets can overlap.
Linux has a few Bluetooth stacks. The four main ones are: BlueZ, OpenBT, Affix, and BlueDrekar. BlueZ was originally written by Qualcomm and is now an open source project available under the terms of the GPL from the project's web site at http://bluez.sourceforge.net/. In the following, I will mainly discuss BlueZ, as it is the Bluetooth stack included in the mainstream kernel tree.
OpenBT was developed and is still maintained by Axis Communications AB. It is available for download from the project's web site at http://developer.axis.com/software/bluetooth/. OpenBT has better documentation and source code comments than BlueZ. But OpenBT is structured as a serial abstraction (i.e., it is accessible through /dev/ttyBT0, /dev/ttyBT1, etc.) whereas BlueZ is structured as a network protocol?accessible using the AF_BLUETOOTH socket type?which in many regards, is more appropriate for Bluetooth, since it is itself a protocol.
Affix was developed and continues to be maintained by Nokia. It is available from its SourceForge web site at http://affix.sourceforge.net/. Both user-space utilities and the kernel patch are available for download under the terms of the GPL. The README available from the project's web site is fairly rich and so is the packages' documentation. Like BlueZ, it is structured as a networking protocol?accessible using the AF_AFFIX socket type.
Finally, the BlueDrekar stack was developed and is distributed by IBM through the project's web site at http://www.alphaworks.ibm.com/tech/bluedrekar/. Although BlueDrekar can be freely downloaded, it is not an open source project, and I will therefore not discuss it further.
Figure 3-3 presents the architecture of the BlueZ stack. If you are familiar with Bluetooth, you will notice that BlueZ does not support Telephony Control protocol Specification Binary (TCS-bin) or OBEX.[21] Although Linux supports IrDA OBEX, the existing Linux implementation, OpenOBEX, cannot, at the time of this writing, operate with OpenBT and can only function in a preliminary way with BlueZ. This is because OpenBT doesn't implement OBEX and BlueZ's support for OBEX is in its early stages. Nevertheless, OpenOBEX can be used with Affix, since it implements OBEX.
[21] This is the same OBEX found in the IrDA standard. Instead of inventing a new protocol, the Bluetooth standard simply uses the IrDA OBEX specification for the implementation of an HTTP-like binary exchange service.
The Host Controller Interface (HCI) is the lowest layer of the Bluetooth stack and is responsible for interfacing with the actual Bluetooth hardware. BlueZ currently supports the following types of HCI adapters:
These are USB-attached Bluetooth devices. Do not confuse this with the "USB Bluetooth" support found in the USB support submenu of the kernel build configuration menu. The latter requires OpenBT, not BlueZ.
These are Bluetooth devices attached to the serial interface.
VHCI stands for Virtual HCI. Consequently, VHCI acts as a virtual Bluetooth device that can be used for testing and development.
The HCI core is immediately above the HCI hardware device drivers and enables them to interoperate with the higher levels of the protocol stack. BlueZ comprises the following stack layers:
The Logical Link Control and Adaptation Protocol (L2CAP) is responsible for link multiplexing, packet segmentation and reassembly, and quality of service.
The Bluetooth standard specifies the RFCOMM protocol to provide serial communication between Bluetooth devices. BlueZ implements RFCOMM as a daemon, RFCOMMd, which uses pseudo-TTYs for communication. PPP can then be used on top of RFCOMMd to enable TCP/IP networking between Bluetooth devices.
The Service Discovery Protocol (SDP) lets a device discover services provided by other Bluetooth-enabled devices and the advertisement of the services offered by a device. SDP is implemented as a daemon, SDPd, in BlueZ.
In addition to the protocol stack, you will need the user-space tools available from BlueZ's project web site. In addition to RFCOMMd and SDPd, these tools include l2ping for L2CAP pinging and hcidump for HCI packet analysis.
Here are some relevant resources:
Further information on the operation of the BlueZ stack can be found in the BlueZ HOWTO from the project's web site.
Information on OpenBT and its use is available on the project's SourceForge workspace at http://sourceforge.net/projects/openbt/.
Delbert Matlock maintains a list of Linux Bluetooth resources at http://delbert.matlock.com/linux-bluetooth.htm, which you may find useful if you are considering the use of Bluetooth with Linux.
Prentice Hall publishes two popular Bluetooth books?Bluetooth Revealed: The Insider's Guide to an Open Specification for Global Wireless Communications by Brent Miller and Chatschik Bisdikian and Bluetooth: Connect Without Cables by Jennifer Bray and Charles Sturman.
You may also be interested in becoming a Bluetooth SIG member. The Bluetooth SIG's web site is located at http://www.bluetooth.org/. You can obtain the official Bluetooth standard from the official Bluetooth web site at http://www.bluetooth.com/.