Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Шина ACCESS.Bus






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

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


428__________ Глава 11. Вспомогательные последовательные интерфейсы и шины

самый простой способ, при котором в каждой транзакции отсутствует смена на­правления передачи. Из этого следует, что для двустороннего обмена информацией все устройства должны поддерживать функции ведущего устройства (передатчи­ка) и ведомого устройства (приемника). Для совместимости с SMBus разрешена возможность чтения данных ведущим устройством и комбинированные переда­чи через условие 5г.

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

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

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

1 GND Черный

2 SDA Зеленый

3 +5 В (питание устройств) Красный

4 SCL Белый

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

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

 

Контакт Назначение
  GND
  Ключ
  SDA
  +5 В (питание устройств)
  SCL


11.1. Последовательные шины на базе I2C_______________________________ 429

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

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

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

Каждому устройству назначается свой адрес, на который оно должно отзываться битами подтверждения при приеме сообщения. Адрес выражают однобайтным числом, причем всегда четным, поскольку в PC 7-битный адрес дополняется младшим битом RW, нулевым в ACCESS.bus. Адрес 50h всегда назначается хост-компьютеру, адрес 10h зарезервирован для хоста SM-устройств. Адрес 6Eh является



Глава 11. Вспомогательные последовательные интерфейсы и шины


«дежурным» адресом, на который отзываются лишь устройства с неназначенным личным адресом. Для личных адресов устройств остаются диапазоны 02-4ЕН; 52-GCh; 70-FEh — 125 адресов с некоторыми исключениями, зарезервированными для фиксированных адресов SM-устройств и мониторов.

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

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

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

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

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

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

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

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

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


11.1. Последовательные шины на базе! 2С_______________________________ 431

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

♦ Attenti on —запрос на конфигурирование (устройство включилось и заверши­ло автоинициализацию). Тело состоит из однобайтного кода EOh.

♦ Identification Reply — ответ на запрос идентификационной строки. Тело
(длина 29) содержит код Elh, за которым следует 28-байтная строка иденти­
фикации.

♦ Capabilities Reply — ответ на запрос фрагмента описания возможностей.
Тело (длина 3-35) начинается с кода E3h, за которым следует 16-битное сме­щение (см. запрос) и собственно данные (0-32 байт). Хост собирает фрагмен­ты, используя смещение.

Также в спецификации определены дополнительные протокольные сообщения, используемые для управления потреблением, распределением ресурсов и иных целей (у этих сообщений также флаг Р-1).

♦ Resource Requeset — запрос ресурса (от устройства к хосту). За кодом E5h
следует байт-описатель ресурса и необходимые данные. Команда позволяет
запросить адрес в личное пользование и освободить его; запросить сообщение
о текущем времени; запросить хост о сохранении блока данных, а также о воз­
вращении его ббратно; запросить хост о сохранении питания на шине (для
окончания внутренних операций); запросить дополнительную полосу шины.

♦ Resource Grant — выделение ресурса, ответ хоста на запрос. За кодом F4h
следует описатель ресурса и необходимые данные.

♦ Application Hardware Signal—запрос устройства на генерацию высокопри­
оритетного аппаратного сигнала хост-компьютеру. За кодом AOh следует байт со следующим кодом сигнала:

 

• 1 — Reset — попытка аппаратного сброса компьютера;

• 2 — Halt — вызов отладчика;

• 3 — Attention — генерация сигнала внимания (аппаратное прерывание).

 

♦ Application Test — команда от хоста на выполнение устройством приклад­
ного теста (код Blh).

♦ Application Test Reply — сообщение устройством о результатах выполне­
ния теста. За кодом Alh следует код результата (0 — успешное выполнение, иначе — ошибка) и 0-30 байт дополнительных данных.

♦ Application Status Message — сообщение устройством об изменении сво­
его состояния (в прикладном плане). За кодом A2h следует нулевой байт, за ним байт состояния и 2 байта специфических данных. Байт состояния:

 

• 00 — готово;

• 01 — не готово;

• 02 — изменились свойства;

• 03 — потеряно внутреннее состояние;

• 04 — потеряны прикладные данные (может, и от переполнения).


432__________ Глава 11. Вспомогательные последовательные интерфейсы и шины

♦ Device Power Management Command — команда управления потреблением устройства. За кодом F6 следует байт кода операции:

• 00 — режим Run;

• 01 — режим Standby;

• 02 — режим Suspend;

• 03 — режим Shutdown;

• 04 — совет отключить питание;

• 05 — рестарт;

• 06 — сообщить режим потребления.

Остальные коды протокольных сообщений задаются разработчиком в соответ­ствии со спецификой устройств. Напомним, что прикладные данные передаются с флагом Р=0.

Строка идентификации устройства ACCESS.bus длиной 28 байт состоит из ряда символьных полей — байта ревизии протокола (protocol revision), 7-байтного поля ревизии модуля (module revision), 8-байтных имен производителя (vendor name) и модуля (module name), за которым следует 32-битный уникальный номер устройства (device number). Этот номер может быть либо фиксированным (уни­кальность обеспечивает производитель, что недешево), либо случайным числом, генерируемым по включению (на весь сеанс работы). Системное ПО, распознавая устройство для подключения драйверов, не должно руководствоваться этой стро­кой — возможности устройства (Capabilities) описываются (и сообщаются) в спе­циальной структуре данных. Эта структура зависит от типа устройства.

На уникальности идентификатора и основан механизм автоконфигурирования: на запрос идентификатора по «дежурному» адресу отвечают все устройства, еще не имеющие личных адресов. Однако в ходе арбитража до конца сообщения дохо­дит только одно из этих устройств, после чего хост ему назначает личный адрес. В следующем общем опросе идентификаторов «победит» уже другое устройство и так далее, пока всем устройствам не будут назначены личные адреса (об этом хост узнает по отсутствию ответа на общий опрос). Устройство-«новичок» на шине заявит о своем появлении сообщением Attenti on, в ответ на которое хост выпол­нит вышеописанную процедуру идентификации и назначения адреса.

Спецификация ACCESS.bus определяет структуру программного обеспечения на хост-компьютере. Центральным элементом ПО является менеджер шины — ACCESS.bus Manager — программный драйвер, управляющий всеми операциями с устройствами, подключенными к шине. Этот драйвер, с одной стороны, связыва­ется с аппаратными средствами хост-контроллера через драйвер минипорта MPD; с другой стороны, к нему обращаются драйверы устройств. Прикладное ПО обра­щается либо к драйверам нужных устройств, либо к менеджеру шины (но никак не напрямую к хост-контроллеру). Менеджер шины инициализирует шину и управляет ею, определяя вновь подключенные и отключенные устройства. Он свя­зывает драйверы устройств (или прикладное ПО) с самими устройствами, прове­ряет входящие сообщения и работает как двунаправленный коммутатор данных,


11.1. Последовательные шины на базе I2C_______________________________ 433

переформатирующий и буферирующий входящие и исходящие сообщения. Драй­вер мини-порта MPD (Mini Port Driver) служит для изоляции менеджера шины от аппаратных особенностей хост-контроллера. Драйверы устройств являются двусторонними интерфейсами между прикладными программами и специфиче­скими устройствами. В спецификации ACCESS.bus описываются программные интерфейсы драйверов (Device Driver, Mini Port Driver), а также протоколы для клавиатур, указателей (Locator), мониторов, батарей и текстовых устройств.






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.