Digital interfaces

Digital interface development has been fast in the last ten years. The standard PC interfaces have been redesigned since the mid 1990s. The focus was first on the cable based interfaces and has then shifted to wireless interfaces. Instead of developing new cable based interfaces, the trend in this decade has been to push up the data rates of existing standards. Similar trends can also be seen in wireless interfaces, but in these the radio band limitations often limit the maximum performance and new technologies for higher radio bands are proposed and developed to obtain faster data rates. In general, the current development of digital interfaces has focused on application specific high speed media interfaces, driven by the digital video applications.

The popularity of the RS-232 in the embedded systems shows that there is still demand for simpler interfaces, and that end user API of USB was too complex in the beginning. Embedded systems often require lightweight point-to-point connections, and this was something that the standard USB versions did not support. Instead, the standard USB always requires a host, as all communication is between the host and the device. The implementation of a host is often seen too complex for small embedded devices. The USB OTG standard [USB06] makes way for USB’s use in these devices. Similar trends can be seen also in wireless interfaces. The industry still lacks a commonly accepted low-power low data rate solution. Bluetooth tried to satisfy too many needs and became overly complex for simple systems. In the 2.4 GHz band the IEEE 802.15.4 standard has received much support, and is a base for many implementations requiring light-weight wireless interface. It could emerge as a widely adopted radio platform. However, it will face competition from the Bluetooth Low-energy standard, especially if the users of IEEE 802.15.4 remain divided into multiple competing top-layer standards.

Implementation architectures

There are some basic implementation architectures for digital interface implementation, as have been shown in this Thesis. For an embedded system designer, the interface API depends heavily on the interface implementation. The basic architecture may be the same, but components (ICs) from different manufacturers can provide very different APIs. Functionally similar components from different manufacturers usually have different chip pinouts and physical packages. Thirdly, the components may provide support code for a certain commercial tool (programming envi-ronment) and microcontroller/processor type or family. The microcontroller type or series has a major effect on the total system performance. The microcontroller peripherals, like timers and A/D converters, and lack/inadequacy of them define how many additional components are required for the system. So, not only should the interface itself be chosen carefully to match the applications requirements, but also the implementation architecture should be carefully evalu-ated before making final component choices, as changing the primary components of the interface later will lead to major redesign of the whole system.

As has been noted in this Thesis, the modern digital interfaces, wired and wireless, can basically be considered as single data-path systems in which the complexity is in the processing of data frames. In a sense, the interfaces are or could be implemented mainly in software. This opens possibilities towards software defined multi-purpose interfaces, such as software defined radios (SDRs) [H¨am08].

Designing digital interfaces for interoperability of systems and components Interoperability of systems would benefit from having less diverse field of digital interface stan-dards and proprietary solutions. This is easier to achieve in the wired world, where the cable can supply the power, and there are more possibilities to use the same interface with both very high data rate devices and low-power devices. This is especially true in PC based systems, where the PC can be used to supply power to the low-power device connected to it. Direct communication between two low-power devices is a challenge in this respect. The situation with wireless interfaces is more complex. High data rate, low latency, security, quality of service, transfer distance, power consumption, regulatory limitations of the used radio spectrum and other parameters all affect each other and an interface is always a compromise between them.

This is why so many diverse wireless interfaces exist and will remain, at least on the physical or transport level. There is, however, some hope, as recent trends have been to use an existing standard as an umbrella under which multiple transport methods are included. This is familiar from the IP world, where the IP protocol has for long time been used in both wired and wire-less networks. Indeed, multiple WLAN technologies exist, which are not interoperable at the physical level. More recently, Bluetooth has started to take similar steps, adding support for multiple data link-level technologies. At the same time, Bluetooth itself has been selected to be

7.2 General discussion 105

used as a transport of the ISO/IEEE 11073 standard. It also has support for the IP protocol.

The trend presented will likely continue. Protocols are complex, their development takes time, and the specifications are refined based on practical experience, resolving operational and security related issues. It is more practical to utilize existing standards when applicable. The OSI 7-layer model gives an example of how the interface could be separated into seven distinct components. It can be argued, that this level of separation is too fine. The physical and data-link layer together provide a basic point-to-point interface. Together they define the most basic properties of the interface and its maximum performance limits. Currently, it is common for an interface IC to include at least a part of the data-link layer functionally. Network and transport layer build on these data-links, by providing a virtual data path or “pipe”. These layers can be used to fine tune the performance of the interface within the limits given by the lower layers.

These two layers are closely related to the physical and data-link layer, i.e., for performance reasons they are often implemented close to the interface IC. The three higher layers form a third distinct entity, focusing on the data representation, models, and interface to the users application. They can generate large memory structures and hence their implementation often resides on the same processing platform as the main application.

This kind of low, middle and high superlayer protocol component structuring matches the way the practical protocol implementation is often separated onto a HW interface IC, an em-bedded co-processor running protocol SW and the main processor. If the system is implemented with fewer components, then two (or even all) superlayers can be implemented on the same component. This three superlayer structure can also co-exist with the OSI 7-layer model, i.e., the superlayers can preserve the OSI layers internally if so desired.

Whenever an application uses a digital interface a HW/SW interface must reside somewhere.

Having multiple processing units in the digital interface implementation increases the number of HW/SW interfaces, and presents problems for maintaining the strict layered protocol structure.

One way to tackle the HW/SW problem, while maintaining layer interfaces, would be placing the HW/SW interface within a layer. This way, a software component offers the standard layer interface upwards, and performs the communication with the hardware using an API provided by it. While preserving the other layers, the internal structure of the layer containing the HW/SW interface would become complex, divided and nonstandard. An alternative approach is presented in Figure 7.2. Using separate interface layers; it preserves the original layered structure by providing a standard interface for upper and lower layer. The actual interface layer implementation is platform dependent/system specific but the communication layers can be made more generic. At its simplest, when both layers connected to the interface layer are residing on the same processor & memory space, it only passes data between functions. When the layer implementation is divided onto two different processing units, the interface layer seamlessly connects these two layers via a HW interface (PCB bus or other digital interface). The interface layer can use the standard protocol interfaces of the upper and lower layers it connects. In this

Figure 7.2: An example of using separate interface-layers to distribute communication protocol to separate processing units. In the example, the low-level (LL) interface layer connects the lower and middle layer components via SPI bus, and the high-level (HL) interface layer uses the RS-232 to connect the middle and higher layers.

case no new protocol interfaces need to be specified, the interface layer emulates the operation of the layer it replaces. However, as cross-layer design techniques are applied increasingly more, it can make sense to implement a separate and more versatile interface layer API which can provide support for these features.

The OSI 7-layer model has served well for wired networks, but it has become evident that in wireless networks cross-layer design can provide significant benefits. Cross-layer design is defined by Srivastava and Motani as “protocol design done by actively exploiting the dependences between protocol layers to obtain performance gains” [Sri05]. Most performance benefits focus on the four lowest layers and their interactions. Especially the networking layer can benefit from cross-layer design with the data-link layer [Sri05, and references therein]. As has been learned in this research, the HW/SW boundary often exists below the networking layer. So, even if using the three superlayer structure discussed earlier, the interface between the lower and middle layer should be more than the mere data-pipe traditionally used between the layers.

7.2 General discussion 107

As so, challenges still remain in defining the common interfaces to these layers, so that these layers could be designed as interchangeable components.

The second major challenge on interfaces is to design and agree on how interfaces should be partitioned, i.e., where to draw the lines for the possible HW/SW interface and to place possible interface layers, and to specify these interfaces also in HW level. Again, the challenge in specifying these layer interfaces would be in predicting the needs of the future, so that these interfaces would not become the bottleneck in performance or limitation in expandability while still keeping them practical in the implementation sense. Were all this achieved, we could truly build interfaces from blocks, selecting the blocks required to match the performance or features needed, while still operating under a more common higher layer standard providing application level interoperability with other systems.