Hardware Abstraction - Overview

Overview

Many early computer systems do not have any form of hardware abstraction. This means that anyone writing a program for such a system must know how each hardware device communicates. This becomes a significant challenge to software developers, who must know how every device available works to ensure it's compatible. With hardware abstraction, the program instead tells the operating system what the device should do, and the operating system gives the instruction. This means that programmers don't need to know how individual devices work, and their programs are compatible with any device.

An Example of this might be a "Joystick" abstraction. The joystick device, there are many physical implementations, is readable / writable through an API which many joystick-like devices might share. Most joystick-devices might report movement directions. Many joystick-devices might have sensitivity-settings that can be configured by an outside application. A Joystick abstraction hides details (e.g., register formats, I2C address) of the hardware so that a programmer using the abstracted API needn't understand the details of the device physical interface. This also allows code reuse since the same code can process standardised messages from any kind of implementation which supplies the "joystick" abstraction. A "nudge forward" can be from a potentiometer or from a capacitive touch sensor that recognises "swipe" gestures, as long as they both provide a signal related to "movement".

As physical limitations (e.g. resolution of sensor, temporal update frequency) may vary with hardware, an API can do little to hide that, other than by assuming a "least common denominator" model. Thus, certain deep architectural decisions from the implementation may become relevant to users of a particular instantiation of an abstraction.

A good metaphor is the abstraction of transportation. Both bicycling and driving a car are transportation. They both have commonalities (e.g., you must steer) and physical differences (e.g., use of feet). One can always specify the abstraction "drive to" and let the implementor decide whether bicycling or driving a car is best. The "wheeled terrestrial transport" function is abstracted and the details of "how to drive" are encapsulated.

Examples of "abstractions" on a PC include video input, printers, audio input and output, block devices (e.g. hard disk drives or USB flash drive), etc.

In certain computer science domains, such as Operating Systems or Embedded Systems, the abstractions have slightly different appearances (for instance, OSes tend to have more standardized interfaces), but the concept of abstraction and encapsulation of complexity are common, and deep.

Hardware abstraction layers are of an even lower level in computer languages than application programming interfaces (API) because they interact directly with hardware instead of a system kernel, therefore HALs require less processing time than APIs. Higher level languages often use HALs and APIs to communicate with lower level components.