Hardware-dependent Software

A Classical Approach

Thomas Lehmann

• Publisher: Books on Demand
• Year: 2017
• Print ISBN: 9783741239410
• eBook ISBN: 9783743129764
• Edition: 1
• Topic: Computer Science
• Subtopic: Information Technology
• Index: Computer Science

Software is in many cases interacting with hardware, the peripheral devices, to interact with is physical environment. Those hardware-dependent software parts, in the context of an operating system better known as device driver, are crucial for system performance and stability.In order to design hardware-dependent software, the principles and foundations of the interaction between hardware and software needs to be understood on lowest level as well as on abstract level. The reader can follow the ideas and principles from foundations in computer architecture over low-level communication up to software design and development methods. Describing the interaction with UML gives the software engineer direct hints on how to design the software based on model driven techniques and show the limits its expressiveness in this area. The textbook avoids programming language or operating system dependencies to reveal the underlying, often hidden principles. Nevertheless, as software development is complex in this area, one focus point in the development cycle is on debugging techniques for hardware-dependent software.

1. Introduction

What is Hardware-dependent Software (HdS) in comparison to ”normal software”? What is the difference? What is specific to a device driver or a Hardware Abstraction Layer (HAL)? First of all, the term ”normal software” is already hard to define which makes the comparison more difficult. Within this book, Hardware-dependent Software (HdS) is seen as a Software System which operates in close relationship with digital hardware, often called peripheral device or simply device. HdS interacts with the device, controls it, steers it. Furthermore, it extends the hardware functionality, restricts it, and hides away or encapsulates problems of the hardware/software interaction.

Functionality in software components and on the opposite in hardware operate in their own execution domains. HdS interacts with those execution domains in hardware. The execution domains need to be connected and synchronised, which is in the responsibility of HdS. This synchronisation is a mayor topic, so this book will focus on it.

HdS is more than a Hardware Abstraction Layer (HAL) that just provides a first common interface of the underlying hardware platform. A common interface as a low-level abstraction focusing on portability on lowest level or closest level to the hardware.

Figure 1.1.: HdS as part of the system, without HAL or as dominating part

Within the microcontroller domain, a whole application can be interpreted as HdS, as in most cases the software just coordinates the interaction of the peripheral devices. Or the control logic of the application is a fraction in comparison to the part that can be interpreted as HdS. Within that domain, HdS can additionally be seen as a library for the development of embedded applications. So the HdS is here the basement for higher-level applications. It provides, as a component, services similar to a software library but including hardware interaction (see Figure 1.2).

Regarding the functionality provided, HdS and so called device driver are closely related. To distinguish HdS from device driver, a device driver is here a hardware-dependent software component that is integrated or operates in the context of an operating system (OS). This needs extra considerations on the design, as the OS on the one hand restricts interfaces and communication channels, respectively determines parts of the architecture. On the other hand, the OS provides common services, that ease the design of device drivers. So software, that is typically denoted as device driver, is here HdS in the environment of an operating system.

Figure 1.2.: Hardware-Dependent Software in comparison to libraries

Figure 1.3.: HdS as low-level component of a library/OS

Peripheral devices often interact with other (hardware) components, or to be more precise, an outside world. As software contains a model of the domain it is designed for, the behaviour of the outside world and the interaction needs consideration during the design of the HdS. But the focus stays on the interaction with peripheral devices. So the control of a robot, factory, UAV, etc. falls into the application domain is off topic here.

Nevertheless it is a smooth transition. HdS ranges from a tiny HAL, via more complex modules, device drivers, up to nearly full applications. All are closely related or interact with hardware devices. This interaction leads to typical structures and makes the software design often look tricky. On the other hand, the exploding demand of embedded systems with realtime, reliability, security and safety constraints make the design of HdS a crucial domain. Within this book, interaction means are analysed and designs approaches discussed.

So the whole book is organised in a bottom-up approach. All topics are discussed as general as possible, to emphasis on principles and methodology, and not on ”and in case of the controller x454B92A, you have to create a function that toggles bit 5 ...”. The later can be found in various books on microcontroller programming, but without looking at the underlying principles and methodologies.

This book starts with a short discussion on the intention of HdS. After that, a brief review on computer architecture principles follows to have a common understanding on the underlying hardware architecture.

HdS and hardware devices are parallel executing elements. In parallel systems, the communication and synchronisation means are essential. Hardware devices and software execute according to different paradigms. Both sides need consideration to design software components which aim to reach higher levels of abstraction.

HdS can be designed with usual software engineering methods for parallel systems based on the found communication and interaction model. A software design is driven by different views on the system. The design of HdS from different perspectives is discussed based on the design and modelling with description languages like the Unified Modelling Language (UML).

Specific issues on device management, device drivers, and software development in this special area are later on discussed in separate chapters.

2. Objectives of Hardware-dependent Software

Hardware-dependent Software is software that provides services in cooperation with hardware, the device. Main objective is to make hardware-services available to other higher-level software components. Furthermore the Hardware-dependent Software may emulate missing functionality or restricts the access to hardware functionality. So the hardware and the environment it interacts with is protected against illegal operation requests. Another objective is the management of multiple devices as hot-plugging techniques and power-management let the devices disappear during runtime. This chapter briefly introduces the objectives in order to give an overview were the other analysis and design steps of the following chapters are aiming for.

For now lets focus on the nature of Hardware-dependent Software (HdS) for a moment. We will return to the hardware part in the section on computer architecture again. In this section, the various objectives of a HdS shall be introduced to give a first inside into the complexity of HdS-design within this domain.

Hardware-dependent Software is often denoted as low¹-level software. This is true, as it operates close to the hardware of the execution platform and its peripheral components, simply denoted as devices. In embedded systems, the focus of the system is on the interaction with a physical environment via those peripheral components/devices. Hence, the majority of software components are related to hardware. Furthermore, operating systems can be seen as a collection of device drivers which are in terms of this book Hardware-dependent Software components within an operating system environment.

Figure 2.1.: Overwiew of the interaction

First of all, HdS makes the hardware functionality available to higher level software. At the beginning with the initialisation and configuration of the device for the expected operations, later with interaction functions. The availability of device functionality is often crucial for the commercial success of the device vendor. If the functionality isn’t available with the required performance and quality by the driver (HdS), the device cannot demonstrate its full potential. One key competence is to reveal this potential and grand interoperation with it.

The design of the HdS determines which part of the hardware is available via the interface towards higher software functionality, here denoted as Application. Which level of abstraction is reached at the application interface? Furthermore, as the hardware may interact with other hardware components or the outside world, does the HdS provide appropriate access to them? These questions must be determined by the intended use and influence the design. For one kind of applications, a very low-level channel to parts of the hardware is required, for other applications, a very high-level view is needed.

Figure 2.2.: HdS as adaptor layer between application and hardware

So in some cases, the HdS allows transparent access to parts of the device and at the same time a transparent access to devices beyond the own device with a high level of abstraction. However, HdS is the adaptor between the needs of an application and the provided capabilities of the peripheral device and the associated end point(s) inside the device core.

Figure 2.3.: HdS accesses different endpoints in device core

Software on CPU and hardware devices execute in parallel, whereas the digital circuit in the device is a massive parallel system itself. The functionality of the software side and on the hardware side needs to synchronise at specific points. Devices provide a wide range of synchronisation means which must be understood and the counterpart in software needs to be realised.

Hardware devices and HdS in combination provide a service as a whole. So functionality can be either implemented in hardware or in software (compare the HW/SW-Co-Design approach). Thus HdS not only makes hardware functions available, it can extend them with additional functionality (compare a in Figure 2.4). The functionality is emulated in software by using resources of the target platform, like the main CPU and main memory. In extreme cases, the HdS provides the service just with the later ones and without any real existing device. A good example is the RAM-disk. It behaves like a hard-disk but is emulated with the CPU and the main memory by the RAM-disk driver. Another mid-level approach is to emulate a behaviour at the application interface with the support of hardware of different kind (compare Figure 2.4 b)). For example, a CD-ROM is emulated with a hard-disk. Read access to the disk image is supported, but write is not allowed (or just only for initialisation) in order to fulfil the semantic of a write-only device.

The partial emulation of devices implies another approach, that not all functionality of a device is accessible and usable via the HdS (compare additional hardware-ports in Figure 2.4 c)). The non-availability restricts the usage of the device. This is often the case, where hardware devices are designed for a superset of possible use-cases. For marketing or production reasons, the combination of specific HdS, mostly in the sense of device driver, and the common device determine as a whole the set of available services. The variation of the software determines the functionality variant. In summary, HdS provides a restricted access, enables the full potential of a device, or extends it by emulation of additional functionality.

Figure 2.4.: HdS in a extends functionality, b emulates functionality, or c restricts accesses to device core

Some devices are very similar, especially if they are from the same vendor. Hence, in many cases HdS must handle a set of similar devices. The software part is common to the devices and the whole functionality variant is here determined by the device variant. In all cases, to adapt to the given hardware, it is essential to clearly identify the hardware device in type and revision. And t...

Table of contents

• Table of Contents
• 1. Introduction
• 2. Objectives of Hardware-dependent Software
• 3. Computer Architecture Foundations
• 4. Communication and Synchronisation
• 5. Design
• 6. Device Driver
• 7. Development
• A. Appendix
• Bibliography
• Index
• Copyright