20.1.1 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.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.

Figure 20.2 The Microchip MCP2122 infrared encoder/decoder

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.

20.3.1 Bluetooth

A major player in the field of radio data communication is Bluetooth, which faces the challenges of data communication by radio in an interesting way. The development of Bluetooth is controlled by a group of electronics manufacturers, the Bluetooth Special Interest Group [Ref. 20.6]. It operates between 2.402 and 2.480 GHz, a band originally reserved by international agreement for industrial, scientific and medical (ISM) applications, but now also widely used for local wireless data networks.

Bluetooth provides data links between such devices as cell phones, computers, digital cameras and headphones. It has these characteristics:

• • A low-power radio link – power is around 1mW whereas that of a mobile phone is 3 W.

• • A typical range of 10 m.

• • A data rate originally of 1 Mbps and currently (Bluetooth 2.0) of 3 Mbps.

• • Up to eight devices can be linked simultaneously.

• • Spread-spectrum frequency hopping is applied, with the transmitter changing frequency in a pseudo-random manner 1600 times per second.

When Bluetooth devices detect one another, they determine automatically whether they need to interact with each other, for example through data exchange. This is without any user interaction. Each device has an address, and it is by the address that it determines whether another device that it has detected is of interest to it. Bluetooth systems in contact with each other in this way then form a piconet. Once communication is established, members of the piconet synchronise their frequency hopping, so they remain in contact. A single room could contain several piconets, each containing devices which relate to each other. Each piconet is switching together. For the occasions of momentary clash, there is software that can detect and reject the corrupted data.

There is considerable cleverness in Bluetooth, in the way it can autonomously configure a network and maintain high data rates. This does, however, make it costly and complex for the small or simple system. Therefore, we turn to look at an alternative, Zigbee. This carries some of the Bluetooth attributes, but is far simpler.

20.3.2 Zigbee

Zigbee is a recent standard, managed by members of the Zigbee Alliance [Ref. 20.7]. It gains its inspiration from Bluetooth, but aims to be simpler and cheaper, with a smaller software overhead requirement. It applies the IEEE 802.15.4 Low-Rate Wireless Personal Area Network standard. Like Bluetooth it operates in the ISM bands of the radio spectrum.

Zigbee is particularly appropriate for home automation, and other measurement and control systems, with the ability to use small, cheap microcontrollers. Data rates are low and power consumption minimal.

There are two Zigbee device types, the Full Function Device (FFD) and the Reduced Function Device (RFD). An FFD can pass data from other devices, so can take on a routing role. Each network must have a coordinator, and only an FFD can take on this role. An RFD has minimal memory and functionality, and can communicate with an FFD but not pass data on. The minimal power requirement of a Zigbee network is possible because an RFD node can spend most of its time in Sleep mode. They wakes up briefly, just to confirm they are still part of the network.

20.3.3 Zigbee and the PIC microcontroller

Zigbee is an interesting standard to engage with, and a natural one to apply with PIC microcontrollers. A possible physical implementation of a Zigbee node is illustrated in Figure 20.3.

Figure 20.3 Possible PIC-based Zigbee implementation

The link is through a single-chip radio transceiver, such as the Chipcon (now acquired by Texas Instruments) CC2420 [Ref. 20.8]. A microcontroller interfaces to this through an SPI link and certain control lines. Microchip has produced extensive firmware which can be adapted to apply the protocol. An example, described in Ref. 20.9, allows a Zigbee Coordinator or RFD to be implemented. Figure 20.4 shows a Derbot implementation of the Zigbee protocol, making use of a Microchip demo card.

Figure 20.4 A Derbot implemented as a Zigbee coordinator using a Microchip demo card

20.4.1 The Controller Area Network

The concept of the Controller Area Network (CAN) was developed as the demand was growing for data communication in the motor vehicle environment. With its high level of electromagnetic interference and wide temperature and humidity range, this is a hostile environment for any signal and indeed for any electronic device. Moreover, very high reliability is essential. The serial standards developed for the benign environment of home or office were completely inappropriate and a new standard was therefore needed. Initially, CAN was developed by the German company Bosch. They published Version 2.0 of the standard in 1991, and in 1993 it was adopted by the ISO as an international standard, ISO 11898. At the time of writing, CAN specification Version 2.0B can be downloaded from the Bosch website [Ref. 20.10].

The CAN standard addresses only the lower two levels of the ISO/OSI model of Figure 20.1, but takes some fairly revolutionary approaches in so doing. With its very high level of data security, it is inevitably complex and just the briefest overview is given here. The main features are listed below:

• • Communication is asynchronous, half duplex, with (for a given system) a fixed bit rate. The maximum for this is 1 Mbit/s.

• • The configuration is ‘peer to peer’, i.e. all nodes are viewed as equals. There is, however, a mechanism for prioritisation. Master and slave designation is not used.

• • Logic values on the bus are defined as ‘dominant’ or ‘recessive’, where dominant overrides recessive. Physical interconnect is not otherwise defined.

• • The bus access is flexible. With all nodes being peers, any can start a message. An ingenious arbitration process is applied in the case of simultaneous access, which does not lead to loss of time or data. The arbitration process recognises prioritisation.

• • There are an unlimited number of nodes.

• • Bus nodes do not have addresses, but apply ‘message filtering’ to determine whether data on the bus is relevant to them.

• • Data is transferred in frames, which have a complex format. This starts with identifier bits, during which arbitration can take place. Eight data bytes are allowed per frame.

• • There is an exceptionally high level of data security, with exhaustive error checking. A node that recognises that it is faulty can disconnect itself from the bus.

CAN is now very widely applied in the motor vehicle environment. Figure 20.5 shows the block diagram of just part of a hypothetical car network. Each of the blocks represents a small embedded system – the radio, door, seat and so on. One of these, the door, we met right at the very beginning of the book, in Figure 1.2. All subsystems are networked together by the CAN bus. Another network, not shown, also connects to the Central Control module. It controls the vehicle locomotion – for example, engine, brakes and transmission

Figure 20.5 Part of car body control network

20.4.2 Controller Area Network and the PIC microcontroller

Just as we have seen PIC microcontrollers with I²C or SPI ports, so there are others with on-chip CAN modules. The current version of the Microchip CAN module is called the ECAN – the Enhanced CAN module, which distinguishes it from earlier Microchip CAN modules. An example is the PIC 18F2480. Its data sheet [Ref. 20.11] contains details of the ECAN module.

The ECAN module is complex, containing features to buffer data, to format it in the required way and to check for errors. It has numerous control registers. It would be extremely time-consuming to write code for it from scratch. Therefore, Microchip supplies a set of C routines, described in Ref. 20.12, which can immediately be used to build up a program.

Whichever microcontroller is used, it must still be interfaced to the physical bus, meeting the electrical needs of the connection. This is usually done with a special interface IC, of which the Microchip MCP2551 is an example. Its pin connection diagram is shown in Figure 20.6 and data in Ref. 20.13. The CAN bus implementation used is differential, and connects to the CANH and CANL pins. An external resistor connected at Rs controls the slew rate of the data signal, with a slower rate minimising electromagnetic interference. The microcontroller connects from its ECAN module to the RXD and TXD pins.

Figure 20.6 The MCP2551 Controller Area Network transceiver

20.4.3 The Local Interconnect Network

While CAN has proved itself as the provider of very high-reliability data communication, it is also complex and costly. Not all links in the motor vehicle environment actually require the full capability of CAN. Therefore, the Local Interconnect Network (LIN) was developed to work alongside CAN. The standard, first released in 1999, is managed by the LIN consortium [Ref. 20.14].

The LIN bus is intended to be small and slow, communicating mainly with intelligent sensors and actuators. The network topology is fixed. There is a single master and all other nodes are slaves. The master consequently has greater processing power. The slaves need only have very limited processing power or can just be dedicated hardware. This makes them potentially very low-cost. An interesting way that cost is minimised is that slaves can use simple RC oscillators, continuously resynchronising themselves as data is exchanged. The maximum data rate is a very modest 20 Kbit/s. The master initiates all data transfers and only one slave may respond. There is no mechanism to cope with multiple access to the bus. The data link is single wire, with the concept shown in Figure 20.7. Like the CAN bus, logic states are recessive (logic high) and dominant (logic low).

Figure 20.7 The Local Interconnect Network physical interface

A LIN data frame consists of ‘header’ and ‘response’. The header is always from the master and data response from a single slave. The speed can be chosen from 1 to 20 Kbit/s. The header consists of:

• • A ‘Break’ field, which alerts the slaves to an incoming message.

• • A ‘Sync’ byte at the intended data rate, containing the value 55_H, against which slaves calibrate their own clock period.

• • an ‘Identifier’, which identifies a slave or slaves and specifies an action to be undertaken.

The response is a message of up to eight bytes, placed on the bus by just one slave. This is followed by a ‘Checksum’. In earlier versions of the bus only data bytes were checked; in the most recent the Identifier value is included in the checking process.

There are two bus states, ‘Sleep’ and ‘Active’. Nodes enter Sleep after a time-out period and can be reactivated by the ‘Wakeup’ frame.

Interestingly, the LIN standard also includes software elements. The LIN API (Application Programmers Interface) provides a set of standard C function calls, which between them implement all LIN functionality. This makes it easy to develop the software and then to test it.

In many environments, a LIN bus system may be designed to interface with a CAN bus system. A possible LIN/CAN system is shown in Figure 20.8. Central to this is a microcontroller, such as the 18F2480, which has both CAN and USART capability. The microcontroller shown acts both as the LIN master for the LIN network and as a peer node on the CAN bus.

Figure 20.8 A communication system using Controller Area Network and Local Interconnect Network buses

20.4.4 The Local Interconnect Network and the PIC microcontroller

To implement a LIN master or slave in hardware, all that is needed is a microcontroller with USART capability and a bus interface IC. An example is the Microchip MCP201, shown in Figure 20.9. This implements the buffering seen in Figure 20.7. Connection is made between the host microcontroller's USART and the RXD and TXD pins of the MCP201. Power is supplied to the ’201 via the VBAT pin. There is an internal voltage regulator on board and the interface chip is able to supply power from its VREG pin to the host microcontroller. The pin is used both to flag a fault, in which case it acts as output, and to set the data slope. The LIN line connects to the LIN bus. Full data on this device can be found in Ref. 20.15.

Figure 20.9 Example interface chip, the MCP201

As with most other standards discussed, Microchip has published example firmware as a starting point for developing code. Reference 20.16 provides code for both master and slave, in the 2.0 version of the bus.

20.5.1 Using PIC microcontrollers with USB

A number of PIC microcontrollers have USB ports as peripherals. An example is the 18F2450, whose USB peripheral is shown in Figure 20.10. This versatile little port can link to a host, offering full- and low-speed connection. Some of the key control signals, establishing different operating conditions, appear in the diagram. An internal transceiver can be used for simple applications. However, connections to an external transceiver are available, for example if electrical isolation from the microcontroller is required. Similarly, an internal voltage regulator can be enabled to power the bus. Internal and external pull-up resistors are connected as needed, to meet the different operating requirements.

Figure 20.10 The 18F2450/4450 USB Peripheral, with configuration options

20.5.2 USB On-the-Go

The whole concept of USB depends on a host device, normally a PC, with other devices connected to it at will. However, as its popularity and technology developed, the need arose to connect portable devices directly, to each other, without the need for a host. This is the basis for USB On-the-Go, which is defined as a supplement to USB 2.0. The On-the-Go standard allows the addition of limited host capability to devices which have traditionally been peripheral only. Devices can act as either host or peripheral, or switch between roles. The standard also makes special consideration for low-power requirements. All of these are of course of particular interest in the embedded world.

20.6.1 Connecting to the Internet with the PIC microcontroller

The Internet is the most complex of the protocols reviewed in this chapter. Microchip, however, provides good support, in terms of Application Notes, demonstration hardware (the PICDEM.net board) and, importantly, a modular TCP/IP stack. This is implemented in C with a version available for 18 Series microcontrollers. It can be downloaded from the Microchip website and is described in Ref. 20.20. The great benefit of this is that the user does not need to get involved in the fine detail of the protocol. The stack forms a set of utilities that service the needs of the TCP/IP protocol, forming an equivalent to Figure 20.11. It is responsive to both the user's program and to events on the external connection. The stack occupies around 20 Kbytes of code.

To gain familiarity with networking PIC microcontrollers to the Internet, use of the PICDEM.net board and/or its accompanying documentation is recommended.