Editing Hardware abstraction (section)

==Overview==
Many early computer systems did not have any form of hardware abstraction. This meant that anyone writing a program for such a system would have to know how each hardware device communicated with the rest of the system. This was a significant challenge to software developers since they then had to know how every hardware device in a system worked to ensure the software's [[computer compatibility|compatibility]]. With hardware abstraction, rather than the program communicating directly with the hardware device, it communicates to the operating system what the device should do, which then generates a hardware-dependent instruction to the device. This meant programmers didn't need to know how specific devices worked, making their programs compatible with any device.

An example of this might be a [[joystick]] abstraction. The [[joystick]] device, of which 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 format, [[I2C]] address) of the hardware so that a programmer using the abstracted API, does not need to understand the details of the device's physical interface. This also allows [[code reuse]] since the same code can process standardized 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 (data storage)|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, operating systems tend to have more standardized interfaces), but the concept of abstraction and encapsulation of complexity are common, and deep.

The hardware abstraction layer resides below the [[application programming interface]] (API) in a software stack, whereas the application layer (often written in a high level language) resides above the API and communicates with the hardware by calling functions in the API.