Абстракция аппаратного обеспечения в программном обеспечении

Введение

Наборы подпрограмм в программном обеспечении

Аппаратные абстракции — это наборы подпрограмм в программном обеспечении, которые предоставляют программам доступ к аппаратным ресурсам через программные интерфейсы. Программный интерфейс позволяет обращаться ко всем устройствам определенного класса C аппаратных устройств через идентичные интерфейсы, даже если C может включать различные подклассы устройств, каждый из которых предоставляет отличный аппаратный интерфейс. Аппаратные абстракции часто позволяют программистам разрабатывать приложения, не зависящие от конкретного устройства и обладающие высокой производительностью, предоставляя стандартные вызовы операционной системы (ОС) для работы с аппаратным обеспечением. Процесс абстрагирования аппаратных компонентов часто осуществляется с точки зрения центрального процессора (CPU). Каждый тип CPU имеет специфическую архитектуру набора инструкций, или ISA. ISA представляет собой набор примитивных операций машины, доступных для использования программистами на языке ассемблера и разработчиками компиляторов. Одной из основных функций компилятора является предоставление программисту возможности записывать алгоритм на языке высокого уровня, не заботясь об инструкциях, специфичных для CPU. Затем компилятор генерирует исполняемый файл, специфичный для CPU. Аналогичная абстракция применяется и в операционных системах, но API ОС теперь представляют собой примитивные операции машины, а не ISA. Это позволяет программисту использовать операции уровня ОС (например, создание/удаление задач) в своих программах, сохраняя при этом переносимость между различными платформами.

Обзор

Многие ранние компьютерные системы не имели никакой формы аппаратной абстракции. Это означало, что любой программист, разрабатывающий программу для такой системы, должен был знать, как каждое аппаратное устройство взаимодействует с остальной системой. Это было серьезной проблемой для разработчиков программного обеспечения, поскольку им приходилось разбираться в работе каждого аппаратного устройства в системе, чтобы обеспечить совместимость программного обеспечения. При аппаратной абстракции программа не взаимодействует с аппаратным устройством напрямую, а сообщает операционной системе, что необходимо сделать, после чего операционная система генерирует аппаратно-зависимую инструкцию для этого устройства. Это избавляло программистов от необходимости знать, как работают конкретные устройства, и делало их программы совместимыми с любым устройством. Примером может служить абстракция "джойстика". Устройство джойстика, имеющее множество физических реализаций, считывается и записывается через API, который может использоваться многими устройствами, подобными джойстику. Большинство устройств джойстиков могут сообщать о направлениях движения. Многие джойстики могут иметь настройки чувствительности, которые можно конфигурировать из внешнего приложения. Абстракция джойстика скрывает детали аппаратного обеспечения (например, формат регистра, I2C-адрес), чтобы программисту, использующему абстрагированный API, не нужно было понимать детали физического интерфейса устройства. Это также позволяет повторно использовать код, поскольку один и тот же код может обрабатывать стандартизированные сообщения от любой реализации, предоставляющей абстракцию "джойстика". "Толчок вперед" может быть реализован с помощью потенциометра или емкостного сенсора, распознающего жесты "свайп", при условии, что оба они предоставляют сигнал, связанный с "движением". Поскольку физические ограничения (например, разрешение датчика, частота обновления) могут варьироваться в зависимости от оборудования, API мало что может сделать, чтобы скрыть это, кроме как использовать модель "наименьшего общего знаменателя". Таким образом, определенные глубокие архитектурные решения, принятые при реализации, могут стать важными для пользователей конкретной инстанции абстракции. Хорошей метафорой является абстракция транспорта. И езда на велосипеде, и вождение автомобиля – это транспорт. У них есть общие черты (например, необходимо рулить) и физические различия (например, использование ног). Можно всегда указать абстракцию "доехать до" и позволить реализатору решить, лучше ли ехать на велосипеде или водить машину. Функция "колесный наземный транспорт" абстрагирована, а детали "как управлять" инкапсулированы. Примеры "абстракций" на ПК включают видеоввод, принтеры, аудиоввод и аудиовывод, блочные устройства (например, жесткие диски или USB-флеш-накопители) и т. д. В некоторых областях компьютерных наук, таких как операционные системы или встраиваемые системы, абстракции могут выглядеть немного по-разному (например, операционные системы обычно имеют более стандартизированные интерфейсы), но концепция абстракции и инкапсуляции сложности является общей и глубокой. Аппаратный уровень абстракции находится ниже интерфейса прикладного программирования (API) в программном стеке, в то время как прикладной уровень (часто написанный на языке высокого уровня) находится над API и взаимодействует с аппаратным обеспечением, вызывая функции в API.

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

В операционных системах

Аппаратный слой абстракции (HAL) — это слой абстракции, реализованный в программном обеспечении, между физическим оборудованием компьютера и программным обеспечением, работающим на этом компьютере. Его функция заключается в сокрытии различий в аппаратном обеспечении от большей части ядра операционной системы, чтобы большая часть кода, выполняемого в режиме ядра, не требовала изменений для работы на системах с различным оборудованием. В Microsoft Windows HAL можно рассматривать как драйвер для материнской платы, обеспечивающий взаимодействие инструкций с языков программирования высокого уровня с компонентами низкого уровня, но предотвращающий прямой доступ к аппаратному обеспечению. CP/M (CP/M BIOS), DOS (DOS BIOS), Solaris, Linux, BSD, macOS и некоторые другие переносимые операционные системы также имеют HAL, даже если он явно так не называется. Некоторые операционные системы, такие как Linux, позволяют подключать HAL во время работы, например, Adeos. Операционная система NetBSD широко известна своим чистым аппаратным слоем абстракции, обеспечивающим высокую переносимость. Начиная с Windows Vista и Windows Server 2008, используемый HAL определяется автоматически при загрузке. До проекта Treble Android использовал различные устаревшие, не стандартизированные HAL. Halium — это HAL на базе Android, используемый несколькими мобильными операционными системами, такими как Ubuntu Touch и LuneOS, для работы на смартфонах с предустановленной Android.