Книга: Аппаратные интерфейсы ПК. Энциклопедия

11.1.2. Шина ACCESS.Bus

11.1.2. Шина ACCESS.Bus

Последовательная шина ACCESS.Bus (Accessory Bus) разрабатывалась фирмой DEC как унифицированный недорогой интерфейс взаимодействия компьютера с внешними устройствами — клавиатурой, координатными устройствами, текстовыми устройствами (принтеры, считыватели штрих-кодов), мониторами (в плане обмена управляющей и конфигурационной информацией по каналу VESA DDC). История ACCESS.Bus начинается с 1991 г.; несколько позже в шину вели дополнительную спецификацию для взаимодействия с внутренними устройствами, например, интеллектуальными источниками питания (Smart Battery) и т. п. К внутренним относятся устройства системного управления SM (System Management), и в спецификации имеются точки соприкосновения с шиной SMBus, основанной на том же интерфейсе I?C. Формально шина позволяет обмениваться сообщениями устройствам числом до 125 (предел принятой системы адресации). Над аппаратным протоколом I?C в шине ACCESS.Bus имеется базовый программный протокол, с которым взаимодействуют протоколы конкретных подключенных устройств. Протоколы обеспечивают подключение/отключение устройств без перезагрузки ОС и автоматическое динамическое назначение адресов. Последняя доступная версия ACCESS.bus Specifications Version 3.0 опубликована ACCESS.bus Industry Group в 1995 г., дальнейшее описание сделано на ее основе.

На аппаратном уровне шина логически полностью соответствует шине I?C со стандартной скоростью (до 100 Кбит/с) и 7-битной адресацией ведомых устройств. Здесь работают те же механизмы синхронизации и арбитража. Однако из всех возможных способов передачи и приема данных в ACCESS.bus основным является передача данных ведущим устройством и их прием ведомым устройством — это самый простой способ, при котором в каждой транзакции отсутствует смена направления передачи. Из этого следует, что для двустороннего обмена информацией все устройства должны поддерживать функции ведущего устройства (передатчика) и ведомого устройства (приемника). Для совместимости с SMBus разрешена возможность чтения данных ведущим устройством и комбинированные передачи через условие Sr.

По электрическим сигналам имеются две спецификации, для внешних и внутренних устройств соответственно.

Спецификация для внешних устройств (Off-board ACCESS.bus), являющаяся основной для этой шины, определяет использование 4-контактного экранированного модульного разъема (MOLEX SEMCONN или AMP SDL), назначение контактов которого приведено в табл. 11.2. Хост-компьютер должен обеспечивать питание 5 В с током 50-1000 мА. Каждое устройство (и кабель), характеризуется потребляемым током I (мА) и вносимой емкостью сигнальных проводов С (пФ). Предельное число подключаемых устройств ограничивается суммарной вносимой емкостью (не более 1000 пФ) и током потребления. До ограничения по адресации (125 устройств) дело практически не доходит. Максимальная суммарная длина кабеля (без повторителей) не должна превышать 10 м. По сравнению с I?C в шине ток нагрузки линий SDA и SCL увеличен до 6 мА (выходной ток низкого уровня). Для улучшения формы импульсов и защиты от статического электричества устройства рекомендуется подключаться к линиям SDA и SCL через последовательные резисторы 51 Ом. Входы микросхем рекомендуется защищать диодами, соединенными с шинами GND и +5 В.

Таблица 11.2. Назначение контактов внешнего разъема ACCESS.bus

Ассоциация VESA для вывода внешней шины ACCESS.Bus на корпус мониторов предлагает иной, 5-контактный разъем ACCESS.Bus; назначение его контактов приведено в табл. 11.3.

Таблица 11.3. Разъем ACCESS.Bus (VESA)

Спецификация для внутренних устройств (On-board ACCESS.bus) рассчитана на меньшие токи нагрузки (350 мкА); здесь допускаются последовательные резисторы большего сопротивления. Вместо ограничения на вносимую емкость задаются требования к фронтам и спадам сигналов. Эта спецификация была введена только в 1995 г., она нацелена на совместимость с устройствами SMBus, и в нее введены дополнительные ограничения на максимальные длительности различных фаз, соответствующие SMBus.

Базовый протокол шины ACCESS.bus 3.0 состоит из двух наборов: протокол PA для устройств с программируемым адресом (Programmable Address) и протокол FA для устройств с фиксированным адресом. В устройстве (как внешнем, так и внутреннем) может быть реализован любой из них или оба. Предыдущая версия спецификации описывала только внешние устройства PA; внутренние устройства с FA называются SM-устройствами (System Management). Протокол FA практически соответствует шине SMBus, описанной ниже, без «архитектурных излишеств» в виде PEC и динамического назначения адресов. Устройства SM могут общаться с хостом по протоколу Write Word (см. ниже). Базовый протокол PA основан на передаче однонаправленных сообщений (см. ниже). Шина ACCESS.bus является хост-центрической: сообщения передаются от устройства к хосту и от хоста к устройству; исключением является попытка сброса устройства-двойника (см. ниже). После включения питания устройства должны отвечать только на «дежурный» адрес 0110 111; в процессе конфигурирования каждому устройству назначается личный адрес. В рабочем состоянии шина позволяет обнаруживать подключение новых устройств и их конфигурировать без перезагрузки («горячее подключение»).

Сообщения передаются в виде пакетов, формат пакета приведен на рис. 11.3. Адрес назначения DestAddr воспринимается получателем аппаратно (это адрес ведомого устройства I?C). Адрес источника SrcAddr позволяет получателю идентифицировать источник данных (и определить, куда посылать ответ). Флаг протокола P позволяет различать назначение тела пакета: P=0 — «полезные» данные устройства (Device Data Stream); P=1 — управление/состояние (control/status). Поле Length определяет длину тела пакета (в байтах); само тело (Body) размещается в последующих байтах. Контрольный байт Checksum является результатом выполнения функции XOR (Исключающее ИЛИ) над всеми предшествующими байтами пакета начиная с адреса приемника. Признаком целостности пакета является нулевой результат функции XOR от всех байтов пакета включая контрольный. Подлежат отработке только пакеты с корректным контрольным байтом. Минимальная длина всего пакета — 4, максимальная — формально 131 (127 байт тело и 4 байта обрамления). Однако максимальную длину пакета ограничивает и время, разрешенное устройству для передачи пакета.

Рис. 11.3. Формат пакета сообщения ACCESS.Bus

Каждому устройству назначается свой адрес, на который оно должно отзываться битами подтверждения при приеме сообщения. Адрес выражают однобайтным числом, причем всегда четным, поскольку в I?C 7-битный адрес дополняется младшим битом RW, нулевым в ACCESS.bus. Адрес 50h всегда назначается хост-компьютеру, адрес 10h зарезервирован для хоста SM-устройств. Адрес 6Eh является «дежурным» адресом, на который отзываются лишь устройства с неназначенным личным адресом. Для личных адресов устройств остаются диапазоны 02-4ЕН; 52-GCh; 70-FEh — 125 адресов с некоторыми исключениями, зарезервированными для фиксированных адресов SM-устройств и мониторов.

Для ACCESS.bus определено 9 протокольных сообщений (у них флаг P=1), обязательных для реализации интерфейсных функций шины (автоконфигурирования). «Полезными» прикладными сообщениями могут обмениваться только сконфигурированные устройства и только после явного разрешения этого обмена.

Ниже перечислены сообщения от хоста к устройствам.

? Reset — сброс устройства и перевод его в режим ответа на «дежурный» адрес. Тело состоит из однобайтного кода F0h. Это же сообщение может послать и устройство, обнаружившее на шине помеху в виде устройства-двойника с тем же адресом. Послав это сообщение по своему же собственному адресу, устройство заставит двойника перейти на «дежурный» адрес.

? Identification Request — запрос идентификационной строки. Тело состоит из однобайтного кода F1h.

? Assign Address — назначение устройству, имеющему совпадающую идентификационную строку, нового адреса. Тело (длина 30) начинается с кода F2h, за которым следует 28-байтный идентификатор устройства, а за ним — байт нового адреса.

? Capabilities Request — запрос фрагмента информации о возможностях устройства. В теле за кодом F3h следует 16-битный параметр — смещение требуемых данных относительно начала структуры данных возможностей. Для упрощения логики устройств параметр ограничивается значениями, обеспечивающими чтение первого фрагмента (с нулевым смещением), следующего и переспрос последнего переданного.

? Enable Application Report — разрешение передачи прикладных данных. За кодом F5h следует байт кода операции: 00h — запрет, 01 — разрешение.

? Presence Check — проверка наличия устройства по данному адресу. За кодом F7h следует нулевой байт (зарезервирован на будущее).

Далее перечислены сообщения от устройств к хосту.

? Attention —запрос на конфигурирование (устройство включилось и завершило автоинициализацию). Тело состоит из однобайтного кода E0h.

? 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), мониторов, батарей и текстовых устройств.

Оглавление книги