Аппаратные интерфейсы ПК. Энциклопедия - Михаил Гук
Шрифт:
Интервал:
Закладка:
♦ Identification Reply — ответ на запрос идентификационной строки. Тело (длина 29) содержит код E1h, за которым следует 28-байтная строка идентификации.
♦ Capabilities Reply — ответ на запрос фрагмента описания возможностей. Тело (длина 3-35) начинается с кода E3h, за которым следует 16-битное смещение (см. запрос) и собственно данные (0-32 байт). Хост собирает фрагменты, используя смещение.
Также в спецификации определены дополнительные протокольные сообщения, используемые для управления потреблением, распределением ресурсов и иных целей (у этих сообщений также флаг P=1).
♦ Resource Request — запрос ресурса (от устройства к хосту). За кодом E5h следует байт-описатель ресурса и необходимые данные. Команда позволяет запросить адрес в личное пользование и освободить его; запросить сообщение о текущем времени; запросить хост о сохранении блока данных, а также о воз вращении его обратно; запросить хост о сохранении питания на шине (для окончания внутренних операций); запросить дополнительную полосу шины.
♦ Resource Grant — выделение ресурса, ответ хоста на запрос. За кодом F4h следует описатель ресурса и необходимые данные.
♦ Application Hardware Signal — запрос устройства на генерацию высокоприоритетного аппаратного сигнала хост-компьютеру. За кодом A0h следует байт со следующим кодом сигнала:
• 1 — Reset — попытка аппаратного сброса компьютера;
• 2 — Halt — вызов отладчика;
• 3 — Attention — генерация сигнала внимания (аппаратное прерывание).
♦ Application Test — команда от хоста на выполнение устройством прикладного теста (код B1h).
♦ Application Test Reply — сообщение устройством о результатах выполнения теста. За кодом A1h следует код результата (0 — успешное выполнение, иначе — ошибка) и 0-30 байт дополнительных данных.
♦ Application Status Message — сообщение устройством об изменении своего состояния (в прикладном плане). За кодом A2h следует нулевой байт, за ним байт состояния и 2 байта специфических данных. Байт состояния:
• 00 — готово;
• 01 — не готово;
• 02 — изменились свойства;
• 03 — потеряно внутреннее состояние;
• 04 — потеряны прикладные данные (может, и от переполнения).
♦ Device Power Management Command — команда управления потреблением устройства. За кодом F6 следует байт кода операции:
• 00 — режим Run;
• 01 — режим Standby;
• 02 — режим Suspend;
• 03 — режим Shutdown;
• 04 — совет отключить питание;
• 05 — рестарт;
• 06 — сообщить режим потребления.
Остальные коды протокольных сообщений задаются разработчиком в соответствии со спецификой устройств. Напомним, что прикладные данные передаются с флагом P=0.
Строка идентификации устройства ACCESS.bus длиной 28 байт состоит из ряда символьных полей — байта ревизии протокола (protocol revision), 7-байтного поля ревизии модуля (module revision), 8-байтных имен производителя (vendor name) и модуля (module name), за которым следует 32-битный уникальный номер устройства (device number). Этот номер может быть либо фиксированным (уникальность обеспечивает производитель, что недешево), либо случайным числом, генерируемым по включению (на весь сеанс работы). Системное ПО, распознавая устройство для подключения драйверов, не должно руководствоваться этой строкой — возможности устройства (Capabilities) описываются (и сообщаются) в специальной структуре данных. Эта структура зависит от типа устройства.
На уникальности идентификатора и основан механизм автоконфигурирования: на запрос идентификатора по «дежурному» адресу отвечают все устройства, еще не имеющие личных адресов. Однако в ходе арбитража до конца сообщения доходит только одно из этих устройств, после чего хост ему назначает личный адрес. В следующем общем опросе идентификаторов «победит» уже другое устройство и так далее, пока всем устройствам не будут назначены личные адреса (об этом хост узнает по отсутствию ответа на общий опрос). Устройство-«новичок» на шине заявит о своем появлении сообщением Attention, в ответ на которое хост выполнит вышеописанную процедуру идентификации и назначения адреса.
Спецификация ACCESS.bus определяет структуру программного обеспечения на хост-компьютере. Центральным элементом ПО является менеджер шины — ACCESS.bus Manager — программный драйвер, управляющий всеми операциями с устройствами, подключенными к шине. Этот драйвер, с одной стороны, связывается с аппаратными средствами хост-контроллера через драйвер минипорта MPD; с другой стороны, к нему обращаются драйверы устройств. Прикладное ПО обращается либо к драйверам нужных устройств, либо к менеджеру шины (но никак не напрямую к хост-контроллеру). Менеджер шины инициализирует шину и управляет ею, определяя вновь подключенные и отключенные устройства. Он связывает драйверы устройств (или прикладное ПО) с самими устройствами, проверяет входящие сообщения и работает как двунаправленный коммутатор данных, переформатирующий и буферизующий входящие и исходящие сообщения. Драйвер мини-порта MPD (Mini Port Driver) служит для изоляции менеджера шины от аппаратных особенностей хост-контроллера. Драйверы устройств являются двусторонними интерфейсами между прикладными программами и специфическими устройствами. В спецификации ACCESS.bus описываются программные интерфейсы драйверов (Device Driver, Mini Port Driver), а также протоколы для клавиатур, указателей (Locator), мониторов, батарей и текстовых устройств.
11.1.3. Шина SMBus
Шина SMBus (System Management Bus — шина системного управления) — двухпроводной интерфейс для обмена данными между микросхемами различных системных компонентов компьютера, а также связи их с самим компьютером. Основное назначение интерфейса — управление подсистемой питания и сопутствующими подсистемами. Первоначально шина разрабатывалась для интеллектуальных батарей и зарядных устройств, и первые версии спецификации SMBus шли под заголовком «Smart Battery System Specifications» (спецификации системы «умных» батарей). Система с «умными», или «ловкими», батареями (Smart Battery System) состоит из собственно батарей (аккумуляторов) и зарядных устройств, способных обмениваться управляющей информацией между собой и с хост-системой, которую она питает. Этот обмен позволяет батареям сообщать свои параметры (текущие значения, ожидаемые величины), подключаться в режим работы (питания хост-системы) или зарядки. Часть управляющих функций выполняется при участии хоста, а часть — автономно. Первая версия спецификации SMBus вышла в 1995 г., версия 1.1 — в 1998 г. Версия 2.0 вышла в 2000 г., она уже не имеет «батарейного» заголовка. Данное описание основано на документе «System Management Bus (SMBus) Specification Version 2.0», выпущенном форумом разработчиков систем с интеллектуальными батареями (SBS, www.sbs-forum.org), в который входит большое число производителей источников питания, а также фирма Intel. Спецификация покрывает три нижних уровня модели взаимодействия открытых систем (OSI), от физического до сетевого.
Шина SMBus основана на интерфейсе I²C, и к ней применимо все сказанное в п. 11.1.1. В шину введена возможность динамического реконфигурирования (подключения и отключения абонентов шины в процессе работы) и автоматического назначения адресов устройств. По сравнению с I²C в шине несколько изменены граничные требования к уровням сигналов и временным диаграммам (см. п. 11.1.4), но в основном они совпадают. Шина позволяет реализовать все режимы обменов, разрешенные для I²C, но имеет нюансы в правилах генерации подтверждений. Для шины SMBus в BIOS имеется стандартизованная поддержка. Особенностью шины SMBus, связанной с ее ролью в управлении системой питания, является способность автономной работы — соединяемые ею устройства могут обмениваться информацией, даже когда питание на центральном процессоре (и других подсистемах) отсутствует. Конечно, о взаимодействии с устройствами шины через BIOS в таком состоянии нет и речи, поскольку BIOS еще «спит».
На физическом уровне (1-м уровне OSI) спецификация определяет электрические и временные параметры сигналов. По уровням сигналов (и нагрузочной способности) имеются две различные спецификации. Маломощная (low power) спецификация соответствует «родному» применению SMBus в устройствах с батарейным питанием; здесь характерны малые токи. Мощная (high power) спецификация предназначена для работы абонентов SMBus в окружении источников значительных помех (например, на плате PCI). Маломощные и мощные устройства на одной шине вместе работать в общем случае не смогут, но это и не требуется. При необходимости совместного использования устройств разных классов организуются разные сегменты шины, соединенные мостом.
В спецификациях временных параметров приняты меры по ограничению времени отклика и предотвращению «зависания» шины. Частота тактового сигнала ограничена и снизу (10 кГц), и сверху (100 кГц); введены ограничения на максимальную длительность нахождения синхросигнала в высоком и низком состоянии и максимальную суммарную «растяжку» битовых интервалов на каждый байт. Предусматривается механизм тайм-аутов, по которому устройства, обнаружившие «зависание» шины, должны немедленно прекратить обмен и повторно инициализироваться. В спецификации I²C эти моменты не рассматривались.
