A word on protocols
With large networked systems, protocols can become incredibly complex, defining every aspect of the communication link. Some of these aspects are obvious and others less so.
To aid in the complex process of defining a protocol, the International Organisation for Standardisation (ISO) devised a ‘protocol for protocols’, called the ‘Open Systems Interconnect’ (OSI) model. This is shown in Figure 20.1. The OSI model sweeps up from the mundane and physical (defining what type of connectors we use or what voltages are recognised), to the more abstract (defining, for example, how data is encrypted and how error correction can be achieved).
Figure 20.1: The ISO Open Systems Interconnect model
Each layer of the OSI model provides a defined set of services to the layer above, and each therefore depends on the services of the layer below. The lowest three layers depend on the network itself and are sometimes called the ‘media layers’. The physical layer defines the physical and electrical link, specifying, for example, what sort of connector is used and how the data is represented electrically. The link layer is meant to provide reliable data flow, and includes activities such as error checking and correcting. The network layer places the data within the context of the network and includes activities such as node addressing.
The upper layers of the OSI model are all implemented in software. This takes place on the host computer, and the layers are sometimes called the ‘host layers’. The software implementation is often called a ‘protocol stack’. For a given protocol and hardware environment, it can be supplied as a standard software package. A designer adopting a protocol stack may need to interface with it at the bottom end, providing physical interconnection, and at the top end, providing a software interface with the application.
This model forms a framework against which new protocols can be defined and a useful point of reference when studying the various protocols already available. Further information on the ISO OSI model may be found in Ref. 20.1. In practice, any one protocol is unlikely to prescribe for every layer of the OSI model, or it may only follow it in an approximate way.
A number of network protocols and means of connection are outlined in the sections that follow. To implement any of these, a physical and a software system will, of course, be required. We will look at a number of options for these, focusing on available hardware subsystems and available software drivers.
20.2 Infrared connectivity
Infrared (IR) data communication has been with us for many years, becoming widely seen first in applications like TV remote controls. Infrared signals are easy to generate and detect, using low-cost semiconductor devices. Being out of the visible spectrum, it is comparatively easy to apply optical filters which exclude visible light, and hence to avoid interference.
The characteristics of all IR links are that data is communicated by a modulated beam of light. The link must therefore be line of sight. It is generally short range and communication is on a one-to-one basis. In this simple characterisation lie a number of interesting advantages and disadvantages. Because it is directional and local, the risk of interference is little and security is good. Because it must be line of sight, however, the ability to engage in wider networks is restricted. Infrared communication can be very low cost and enjoys the advantage of not being regulated by law.
While the early applications were mainly in control, like the TV remote, it was equally evident that IR was good for data communication. This has become a huge growth area for the technology, particularly in situations where a single cable can be replaced, for example in transfers of data from a hand-held device (like a personal organiser or digital camera) to a computer, or between computer and printer.
The Infrared Data Association (IrDA) [Ref. 20.2] is a group of manufacturers who have defined a series of standards for IR links, ranging from simple control to intensive data transfer.
20.2.1 The Infrared Data Association and the PIC microcontroller
Infrared communication is a natural area of activity for the small embedded system. Microchip offers several IR encoder/decoder ICs. An example is the MCP2122 [Ref. 20.3], whose pin connections are shown in Figure 20.2. This is intended to interface between a microcontroller on one side, and an infrared source and receiver on the other. Thus, the TXIR pin can directly drive an IR LED, while the RXIR can connect to a sensor.
Four interconnections are required with the host microcontroller: TX, RX, Reset and 16x Clock. The TX and RX lines connect to the USART of the host microcontroller, just as described in Section 10.10 of Chapter 10. A clock source, running at 16 times the intended baud rate, is also required. This is connected to the 16x Clock line. It can be generated through the microcontroller CCP module, as described in Ref. 20.4. A Reset input allows the host microcontroller to return the IC to its reset condition.
The previous paragraph demonstrates that the physical connection of an infrared port to a PIC microcontroller is simple, and from this stage informal links can be explored between two such nodes. The usual application is to implement data communication under an IrDA standard.
The detail of this is beyond the scope of this book, but can be found in a number of Microchip application notes, for example Ref. 20.5.
Figure 20.2: The Microchip MCP2122 infrared encoder/decoder