Интерфейс последовательной шины I²C, введенной фирмой Philips как простое и дешевое средство сопряжения микросхем бытовой электроники, стал фактическим промышленным стандартом для устройств различного назначения. Он очень удобен для обмена небольшими объемами данных, например, для конфигурации различных устройств. Спецификация шины I²C определяет протокол двусторонней передачи данных по двум сигнальным линиям. Приложения этого протокола могут быть самыми разнообразными, информационная «начинка» зависит от конкретных применений. На основе интерфейса I²C построены шины ACCESS.bus и SMBus, рассмотренные ниже (о работе интерфейса I²C с микросхемами памяти см. п. 7.3.3).

 

11.1.1. Шина I²C

Шина Inter IC Bus (шина соединения микросхем), или, кратко, I²C, — синхронная последовательная шина, обеспечивающая двустороннюю передачу данных между подключенными устройствами. Шина ориентирована на 8-битные передачи. Передача данных может быть как одноадресной, к выбранному устройству, так и широковещательной. Уровни сигналов — стандартные, совместимые с широко распространенной логикой ТТЛ, КМОП, N-МОП, как с традиционным питанием +5 В, так и с низковольтным (3,3 В и ниже). Микросхемы с интерфейсом I²C, как правило, имеют аппаратную поддержку протокольных функций. Протокол позволяет взаимодействовать на одной шине устройствам с различным быстродействием интерфейса. Требования к временным параметрам сигналов весьма свободные, так что на компьютерах и микроконтроллерах, не имеющих аппаратной поддержки шины I²C, ее протокол может быть реализован даже чисто программно.

Шина I²C используется уже давно, ее официальная версия 1.0 вышла в 1992 г. По сравнению с предшествующими (черновыми) версиями, здесь отсутствует (как запутанная и неиспользуемая) возможность программного задания адреса ведомого устройства. Также отсутствует низкоскоростной режим (Low speed), являющийся частным случаем стандартного режима — Standard Mode (S) — со скоростью 0-100 Кбит/с. В версии 1.0 появились определение быстрого режима — Fast Mode (F) — со скоростью 0-400 Кбит/с и связанные с ним изменения требований к форме сигнала и фильтрации помех. Также здесь веден режим 10-битной адресации устройств. Версия 2.0 вышла в 1998 г., когда интерфейс I²C стал фактически промышленным стандартом, использующимся в большом числе различных ИС. Здесь появился новый высокоскоростной режим — High speed (Hs), — в котором скорость передачи может достигать 3,4 Мбит/с. Прежние режимы F и S логически работают одинаково, и для них используют обобщенное обозначение F/S. В этой версии пересмотрены требования к уровням и форме сигналов с учетом высоких скоростей и возможности подключения низковольтных устройств с питанием 2 В и ниже. В версии 2.1 (2000 г.) уточнены некоторые моменты, касающиеся временных диаграмм в режиме Hs. Приведенная здесь информация основана на спецификации шины I²C версии 2.1, доступной на сайте www.philips.com. Параметры интерфейсных сигналов приводятся в п. 11.1.4, где они сопоставляются с требованиями SMBus и ACCESS.Bus.

Интерфейс I²C использует две сигнальные линии: данных SDA (Serial Data) и синхронизации SCL (Serial Clock). В обменах участвуют два устройства — ведущее (master) и ведомое (slave). Ведущее и ведомое устройства могут выступать в роли и передатчика, и приемника данных. Протокол допускает наличие на шине нескольких ведущих устройств и имеет простой механизм арбитража (разрешения коллизий).

Протокол обмена для обычных устройств F/S иллюстрирует рис. 11.1. Обе сигнальные линии имеют нагрузочные резисторы, «подтягивающие» их уровень к напряжению питания. На устройстве к каждой линии подключен приемник и передатчик типа «открытый коллектор» («открытый сток»), у ведомого устройства передатчик на линии SCL не обязателен. Все одноименные передатчики соединяются по схеме «Монтажное И»: уровень в линии будет высоким, если все передатчики пассивны, и низким, если хоть у одного передатчика выходной транзистор открыт. В покое (Idle, исходное состояние шины) все передатчики пассивны. Синхронизацию задает ведущее устройство, но ведомое, если оно не имеет достаточного быстродействия, может замедлять обмен данными.

Рис. 11.1. Протокол передачи данных I²C

Начало любой передачи — условие Start — инициируется ведущим устройством, убедившимся в том, что шина свободна (высокий уровень сигналов SCL и SDA). Условие Start (на диаграммах обозначается как S) — перевод сигнала SDA из высокого в низкий при высоком уровне SCL. Завершается операция переводом сигнала SDA из низкого уровня в высокий при высоком уровне SCL — условие Stop (обозначается как P), также вводящееся ведущим устройством. При передаче данных состояние линии SDA может изменяться только при низком уровне SCL, биты данных считаются действительными во время высокого уровня SCL Ведущее устройство может начать очередную передачу вслед за текущей, не вводя условие Stop, — это называется repeated Start (повторный старт, обозначающийся Sr). В протоколе условия S и Sr почти равнозначны. Каждая посылка данных состоит из 8 бит данных, формируемых передатчиком (старший бит — MSB — передается первым), после чего передатчик на один такт освобождает линию данных для получения подтверждения. Приемник во время девятого такта формирует бит подтверждения Ack, по которому передатчик убеждается, что его «услышали». После передачи бита подтверждения ведомое устройство может задержать следующую посылку, удерживая линию SCL на низком уровне. Ведомое устройство в режимах F/S может замедлить передачу по шине и на уровне приема каждого бита, удерживая SCL на низком уровне после его спада, сформированного передатчиком. Поэтому ведущее устройство должно генерировать сигнал SCL не «вслепую», а анализируя состояние линии SCL: сняв этот сигнал, новый импульс (открытие ключа передатчика) оно имеет право вводить, лишь убедившись, что сигнал SCL вернулся в пассивное состояние (высокий уровень). В противном случае синхронизация будет потеряна. Сигнал SCL может быть растянут и другим устройством, пытающимся захватить шину в это же время. Тактовый сигнал SCL не обязательно будет равномерным: время его нахождения на низком уровне будет определяться максимальным временем, в котором его захочет удержать самое медленное из устройств, участвующих в данном обмене (даже и конфликтующих); время нахождение на высоком уровне будет определяться самым быстрым из конфликтующих ведущих устройств.

Коллизия (конфликт) на шине может возникнуть, когда два (или более) устройства, убедившись в покое шины, одновременно (или почти одновременно) инициируют обмен данными. Все они управляют линиями SCL и SDA и наблюдают за ними. Если устройство, передающее единицу (высокий уровень), в данном такте на линии SDA видит ноль (низкий уровень), оно должно признать свой проигрыш в конфликте и освободить линии SCL и SDA (при этом ему позволительно управлять линией SCL до конца передачи текущего байта). Выигравшее устройство даже и не заметит проигравших конкурентов и продолжит работу. Арбитраж может закончиться в любом месте посылки, формируемой ведущим устройством. Искажения информации, передаваемой выигравшим устройством, не происходит (приятное отличие от коллизий в сетях Ethernet). Если ведущее устройство, проигравшее в конфликте, имеет и функции ведомого устройства, по признанию проигрыша оно должно перейти в режим ведомого, поскольку конфликт мог быть вызван и попыткой обращения к нему победившего ведущего устройства.

Бит подтверждения ACK, вводящийся в конце каждого байта устройством- приемником, выполняет несколько функций. Когда передатчиком является ведущее устройство, приемник (ведомый) должен вводить нулевой бит ACK, свидетельствующий о нормальном получении очередного байта. Единичный бит ACK (нет подтверждения) в ответ на посылку адреса свидетельствует об отсутствии адресованного ведомого устройства на шине или его занятости внутренними процессами. Отсутствие подтверждения байта данных свидетельствует о занятости устройства. Не получив бита подтверждения, ведущее устройство должно сформировать условие Stop, чтобы освободить шину. Когда ведущее устройство является приемником, оно должно формировать нулевой бит ACK после каждого принятого байта, кроме последнего. Единичный бит ACK в этом случае является указанием ведомому устройству на окончание передачи — оно теперь должно освободить линии SDA и SCL, чтобы ведущее устройство смогло сформировать условие P или Sr.

На вышеописанной физической основе строится протокол обмена данными по I²C. Каждое ведомое устройство имеет свой адрес, уникальный на шине. В начале любой передачи ведущее устройство после условия S или Sr посылает адрес ведомого устройства или специальный адрес (табл. 11.1). Ведомое устройство, опознавшее свой адрес после условия Start, становится выбранным; оно обязано ответить подтверждением на адрес и последующие сигналы со стороны ведущего устройства, до получения условия P или Sr. В первоначальном варианте интерфейса разрядность адреса устройства составляла 7 бит, впоследствии был введен и режим 10-битной адресации, совместимый с 7-битной. На одной шине могут присутствовать устройства и с 7-битной, и 10-битной адресацией.

Таблица 11.1. Специальные адреса I²C

При 7-битной адресации в первом байте после S (Sr) ведущее устройство передает 7 бит адреса (А[6:0] в битах [7:1]) и признак операции RW (в бите 0 RW=1 — чтение, RW=0 — запись). Адреса ведомых устройств не должны попадать в области, указанные в таблице. Диапазоны адресов устройств различных типов централизованно выдаются изготовителям микросхем фирмой Philips. Для микросхем памяти, например, 7-битный адрес содержит две части: старшие 4 бита А[6:3] несут информацию о типе устройства (EEPROM — 1010), а младшие 3 бита А[0:2] определяют номер устройства данного типа на шине. Микросхемы с интерфейсом I²C имеют три адресных входа, коммутацией которых на логические уровни 1 и 0 задается номер устройства, на который оно «отзовется», а тип устройства «зашит» в нем самом его изготовителем.

Когда ведущее устройство является передатчиком данных, оно в первом байте передает адрес ведомого устройства, при этом RW=0. Выбранное ведомое устройство отзывается подтверждением (ACK=0), после чего ведущее устройство посылает один или несколько байт данных, на каждый из которых ведомое устройство должно отвечать подтверждением.

Когда ведущее устройство является приемником данных, оно в первом байте передает адрес ведомого устройства с RW=1. Выбранное ведомое устройство также отзывается подтверждением (ACK=0), после чего происходит смена направления передачи и данные уже передает ведомое устройство. Ведущее устройство подтверждает каждый принятый байт, кроме последнего.

Эти передачи могут завершаться условием P, вводимым ведущим устройством, после которого шину может захватить любое ведущее устройство. Возможны и комбинированные передачи, когда ведущее устройство после окончания очередного обмена не отдает шину, а формирует повторный старт (Sr), после чего обращается к тому же или иному устройству.

Отметим, что спецификация I²C не оговаривает правил модификации внутреннего (для микросхемы) адреса данных при последовательных обращениях — их определяет разработчик устройства в соответствии с его функциями. Для памяти естественен автоинкремент адреса, упрощающий последовательные обращения. Для регистроориентированных устройств автоинкремент обычно не нужен.

Специальные коды, приведенные в табл. 11.1, трактуются следующим образом.

♦ Общий вызов является широковещательным, на него должны отвечать лишь устройства, поддерживающие соответствующие функции (см. ниже).

♦ Байт Start предназначен для облегчения программной реализации протокола I²C (для функций ведомых устройств, не имеющих полной аппаратной реализации протокола). На байт Start не должно отвечать ни одно устройство. Формируемый сигнал SDA (рис. 11.2) может быть использован как запрос аппаратного прерывания, по которому процессор «вплотную» займется обработкой сигналов I²C. До получения этого байта процессор (микроконтроллер) может не отвлекаться на слежение за сигналами интерфейса.

♦ На адреса шины CBUS (трехпроводный «родственник» шины I²C) и иных шин устройства I²C отвечать не должны.

♦ При использовании 10-битной адресации биты [2:1] содержат старшую часть адреса, форматы 10-адресных посылок рассмотрены ниже.

Рис. 11.2. Временна́я диаграмма байта Start

Посылка общего вызова используется для одной из двух целей, определяемых вторым байтом, младший бит которого называется В. При В=0 устройства, принявшие общий вызов, должны считать программируемую часть своего аппаратного адреса, выполнив (второй байт 00000110b) или не выполнив (000000100b) внутреннюю процедуру сброса. Другие значения байта устройства должны игнорировать. Каким образом программируется адрес, зависит от устройства (указывается в его описании). При В=1 общий вызов используется для широковещательной передачи данных. В этом случае ведущее устройство в старших 7 битах второго байта сообщает свой адрес (тот же, на который оно отзывается в роли ведомого), а далее посылает требуемое количество байт данных, которые оно желает донести до неизвестного ему приемника. Приемник (как правило, это интеллектуальное устройство) должен отвечать подтверждением на каждый принятый байт начиная с первого (общий вызов), затем на адрес ведущего устройства и последующие байты данных.

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

Введение 10-битной адресации стало решением проблемы дефицита адресов: при 7-битной адресации с учетом зарезервированных комбинаций остается только 112 адресов, при 10-битной доступны еще 1024 адреса. Передача данных ведущим устройством с 10-битной адресацией выглядит просто: в первом байте после S (Sr) биты 2:1 несут старшие биты адреса, бит 0 — признак RW=0; второй байт несет младшие 8 бит адреса, а последующие байты — передаваемые данные. Приемник дает подтверждения обычным способом. Прием данных ведущим устройством несколько сложнее, поскольку признак RW является явным указателем на смену направления передачи и младшую часть адреса ведущее устройство передать уже не может. Прием по 10-битному адресу ведущее устройство начинает как фиктивную передачу: в первом байте посылает признак 10-битной записи и 2 бита адреса, во втором байте — остаток адреса. Далее ведущее устройство выполняет условие Sr и посылает признак 10-битного чтения (RW=1) с двумя старшими битами того же адреса. Ведомый передатчик, получив те же 2 старшие бита адреса, что и до Sr, отвечает подтверждением и начинает передавать данные ведущему устройству. Этот процесс продолжается и завершается так же, как и с 7-битной адресацией. Возможны и комбинированные обмены: реальная передача ведущего устройства 10-битному устройству, за которой после Sr следует чтение того же устройства. Также возможно комбинирование (через Sr) 7- и 10-битных обращений к разным устройствам. Широковещание с 10-битной адресацией выглядит так же, как и с 7-битной, но адрес ведущего устройства передается уже двумя байтами (младшие 8 бит адреса передаются на месте первого байта данных).

Высокоскоростной режим (Hs) позволяет обмениваться данными со скоростью до 3,4 Мбит/с, причем обеспечивается обратная совместимость устройств Hs с быстрыми и стандартными (F/S). Для обеспечения возможности обмена на столь высокой скорости выходные и входные буферы микросхем должны переключаться в специальный режим работы, отличающийся параметрами формируемых и принимаемых импульсов. Сигналы высокоскоростных устройств обозначаются как SDAH и SCLH; в смешанных системах для работы в Hs они должны отделяться от линий SDA и SCL обычных устройств специальными мостами (поведение устройств F/S на таких частотах непредсказуемо). В режиме Hs уже нет речи о разрешении конфликтов — арбитраж выполняется на скоростях F/S; также здесь нет возможности синхронизации по каждому биту (замедления передачи ведомым устройством), а ведущим устройством устанавливаются жесткие соотношения длительности низкого и высокого уровней сигнала SCLH (2:1). Ведомое устройство может притормаживать обмен только после выдачи бит подтверждений. Для перехода в режим Hs ведущее устройство в первом байте (после S) использует зарезервированное значение 00001ххх, в котором xxx несет код ведущего устройства. Во время передачи этого байта (на скорости F/S) выполняется арбитраж — если обмен одновременно пытаются начать несколько устройств, продолжать его может только выигравшее ведущее устройство. Код ведущего устройства в режиме Hs назначается при конфигурировании, а все ведущие устройства на шине в режиме Hs должны иметь различные коды (код 000 зарезервирован), чем и обеспечивается завершение арбитража за время передачи первого байта. Ведущее устройство может переключиться в режим Hs, только если оно выиграло арбитраж и получило единичный бит подтверждения. В этом случае он перестраивает свои выходные и входные буферы на параметры Hs и формирует повторный старт (Sr). Далее обмен логически выполняется точно так же, как и в режиме F/S, но уже на высокой скорости. Режим Hs может распространяться на несколько последующих передач, разделенных условиями Sr, и завершится работа в режиме Hs по условию P, по которому буферные схемы снова вернутся к параметрам F/S.

 

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

 

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 эти моменты не рассматривались.

На шине SMBus могут использоваться дополнительные аппаратные сигналы.

♦ Сигнал SMBSUS# указывает на приостанов шины и устройств. Этот сигнал вырабатывается устройством управления питанием; во время его активности (низкий уровень) сигналы SDA и SCL штатным образом (как в I²C) не воспринимаются (они могут использоваться для уточнения режима приостанова).

♦ Сигнал SMBALERT# служит для оповещения ведущего устройства о необходимости обмена с ведомым устройством, не имеющем возможности выступить в роли ведущего устройства. Этот сигнал собирается по схеме «Монтажное И» от всех устройств. Получив его, хост должен дать команду чтения байта по адресу 0001 100, на которое просигналившее устройство должно ответить байтом со своим адресом (возможен вариант и с дополнительным байтом PEC).

На уровне связи (2-м уровне OSI) определяются те же правила передачи данных, что и в I²C: условия S, P, Sr; биты подтверждения; 7-битная адресация и признак RW в первом байте, следующем за условием S (Sr). Как и в I²C, ведущее устройство может выполнять и запись, и чтение данных ведомого устройства; используются и комбинированные транзакции (через условие Sr). В генерации подтверждений на SMBus есть особенности. На собственный адрес устройство всегда должно отвечать битом подтверждения ACK, даже если оно занято внутренними операциями. Это правило обеспечивает работу механизма определения присутствия данного устройства на шине. Ведомое устройство может вводить бит NACK в ответ на любой неадресный байт, если оно занято или запрашиваемые командой данные недоступны. В этом случае у него есть и альтернатива поведения — задержать синхросигнал на низком уровне (в разрешенных пределах). Ведомое устройство должно вводить бит NACK в ответ на недопустимые коды команд или данных. Ответ NACK вынуждает ведущее устройство прекратить транзакцию (ввести P). Ведущее устройство, будучи приемником, ответом NACK информирует передатчик о приеме последнего ожидаемого байта.

Сетевой уровень (3-й уровне OSI) определяет «лицо» шины SMBus и заслуживает более детального рассмотрения.

Сетевой уровень SMBus

В шине SMBus введено понятия «хоста» (host) — абонента шины, выполняющего координирующие и конфигурирующие функции. Хост является ведущим устройством шины, при этом должен выполнять ряд функций ведомого устройства и отрабатывать сообщения уведомления.

Каждое ведомое устройство имеет свой уникальный адрес; в диапазоне 7-битных значений адреса выделяются специальные значения (табл. 11.4), которых несколько больше, чем в I²C. 10-битная адресация в текущей версии не рассматривается. Адреса устройств разделяются по типам. Для устройств однозначно понятного назначения SMBus WG выделяет специальные адреса (Purpose-assigned addresses). Например, батареи Smart Battery имеют адрес 0001 011, их зарядные устройства — 0001 001. Устройства с этими адресами обязаны соответствовать требованиям SMBus, предъявляемым к устройствам данного класса. Ряд систем с SMBus определяют и используют эти устройства, основываясь на их адресе. Другие системы могут и не доверять одному только адресу, а определять типы присутствующих устройств иным образом. Для устройств разнообразного назначения, а также устройств, не полностью отвечающих спецификациям SMBus для своего класса, производители назначают иные адреса, с которыми можно ознакомиться на сайте www.smbus.org. Адреса устройств-прототипов задействуются исключительно в экспериментально-отладочных целях и в коммерческих изделиях использоваться не должны. В спецификации SMBus 2.0 появилась возможность автоматического динамического назначения адресов устройств, которая будет рассмотрена ниже.

Таблица 11.4. Специальные адреса SMBus

Типичное устройство SMBus поддерживает определенный набор команд, с помощью которых выполняется обмен данными. Команда кодируется одним байтом, передаваемым в транзакции вслед за адресным байтом. Команды могут использовать один из 11 протоколов, определенных в SMBus.

В версии 1.1 спецификации SMBus введена возможность контроля ошибок пакета PEC (Packet error checking). Механизм PEC основан на добавлении в конец каждого передаваемого пакета байта CRC-кода, вычисляемого по всем предыдущим байтам пакета, начиная с адресного. Почти все протоколы могут иметь два варианта — без PEC и с PEC; на одной шине могут присутствовать устройства и с поддержкой PEC, и без. На байт PEC приемник отвечает подтверждением, но трактовка ответа неоднозначна. Если передатчик в ответ на PEC получил ответ NACK, это означает, что приемник не подтвердил корректный прием пакета. Однако ответ ACK не является подтверждением достоверности приема: приемник может «не понимать» PEC и отвечать на него как на обычный байт данных; приемник может и не выполнять контроль в реальном времени приема потока данных. Более «достоверный контроль достоверности» могут обеспечить лишь протоколы высших уровней. Так, например, для контроля достоверности записи в устройство можно использовать последующее чтение тех же данных с PEC, и по анализу всего принятого пакета ведущее устройство сделает вывод об успешности или ошибке операции записи.

Шинные протоколы SMBus основаны на транзакциях I²C с 7-битной адресацией.

♦ Quick Command, короткая команда, — посылка адресного байта; действие команды определяется битом RW адресного байта.

♦ Send Byte, посылка байта, — передача ведущим устройством вслед за адресным байтом (RW=0) одного байта данных. В варианте с PEC передаются два байта, последний — PEC.

♦ Receive Byte, прием байта, — прием ведущим устройством вслед за адресным байтом (RW=1) одного байта данных. В варианте с PEC принимаются два байта, последний — PEC.

♦ Write Byte, Write Word, запись байта/слова, — передача ведущим устройством вслед за адресным байтом (RW=0) одного байта команды, за которым следует 1 или 2 байта (младший, а затем старший) данных. В варианте с PEC в конец добавляется контрольный байт.

♦ Read Byte, Read Word, чтение байта/слова, — комбинированные транзакции: сначала посылается адресный байт (RW=0), за которым передается код команды. Далее, через условие 5 посылается адресный байт с тем же адресом устройства, но RW=1, после которого принимается 1 или 2 байта данных. В варианте с PEC в конце ожидается прием дополнительного (контрольного) байта.

♦ Block Write, запись блока, — передача ведущим устройством вслед за адресным байтом (RW=0) одного байта команды, за которым следует байт-указатель длины (количество последующих байт) и собственно байты данных. В варианте с PEC в конец добавляется контрольный байт. Указатель длины не учитывает байт PEC; он не может быть нулевым; одной блочной командой можно пересылать до 32 байт данных.

♦ Block Read, чтение блока, — комбинированная транзакция: сначала посылается адресный байт (RW=0), за которым передается код команды. Далее, через условие S посылается адресный байт с тем же адресом устройства, но RW=1, после которого принимается байт-указатель длины, а за ним и собственно байты данных. В варианте с PEC в конце ожидается прием дополнительного (контрольного) байта. Указатель длины — аналогично блочной записи.

♦ Process Call, вызов процесса, — комбинация команды Write Word с приемом слова (двух байт) от устройства с тем же адресом. Команда называется вызовом процесса, поскольку ожидает данных, зависящих от посланного кода команды и слова данных. В варианте с PEC контрольный байт ожидается только в самом конце, вслед за последним байтом принятых данных.

♦ Block Write-Block Read Process Call — комбинация записи блока с последующим чтением блока по тому же адресу устройства. В варианте с PEC контрольный байт ожидается только в самом конце, вслед за последним байтом принятых данных.

В случае, когда ведущим устройством шины собирается выступать рядовое устройство (не хост), оно должно использовать протокол уведомления хоста (SMBus host notify protocol): устройство на адрес хоста с RW=0 (он известен) посылает байт с собственным адресом, за которым следует слово (два байта) собственно уведомления. Хост обязан понимать эти уведомления; дополнительно может использоваться и необязательный сигнал внимания SMBALERT# (см. ниже).

Автоматическое назначение адресов

Динамическое реконфигурирование шины SMBus — возможность «горячего» подключения/отключения основано на базовых принципах протокола I²C. Автоматическое назначение адресов, появившееся в версии 2.0, использует еще и контрольные байты пакетов (PEC). Задача динамического реконфигурирования включает распознавание фактов подключения/отключения устройств и обеспечение бесконфликтного распределения их адресов. Подключение новых устройств может распознаваться двумя способами. Устройство, которое может работать ведущим устройством, при подключении (после своей инициализации по включению питания) может послать хосту уведомление, содержащее его адрес. Другой вариант обнаружения — периодический опрос устройств ведущим устройством, ведающим «переучетом» всех устройств на шине.

Для динамического бесконфликтного назначения личных адресов устройств используется протокол ARP (Address Resolution Protocol). Назначение адресов основано на стандартном механизме арбитража (разрешения конфликтов) шины SMBus (и I²C). Назначенный адрес запоминается устройством на все время, пока подано питание. Возможны и устройства PSA (Persistent Slave Address), «вспоминающие» ранее назначенный адрес после повторного включения питания. После назначения адреса обмен с устройством выполняется точно так же, как и с устройством с фиксированным адресом. Назначение адресов может выполнять любое ведущее устройство шины SMBus.

Для динамического назначения адреса требуется изоляция устройств — возможность диалога ведущего устройства-нумератора с каждым устройством без помех со стороны других устройств (типичная задача настройки системы PnP). Изоляция основана на уникальном идентификаторе устройства UDID (Unique Device Identifier) — 128-битной структуре, содержащей описание возможностей, версию, идентификаторы производителя, устройства, подсистемы и специфическую информацию. Идентификатор начинается с байта возможностей (Device Capabilities), в котором два старших бита характеризуют способности динамической адресации, а младший бит — поддержку PEC. Чтение идентификатора выполняется ведущим устройством ARP по протоколу блочного чтения по «дежурному» адресу SMBus. На это чтение отзываются все устройства с еще не назначенными адресами, и на арбитраже этой операции работает изоляция устройств. Первый считанный байт (указатель длины) у всех устройств одинаков, по нему конфликтов нет. Далее устройства передают идентификаторы, и в арбитраже будут иметь приоритет те устройства, у которых нулевое значение бит данных встретится раньше. С учетом этого принята следующая кодировка классов устройств в старших битах первого байта идентификатора:

♦ 00 — устройства с фиксированными адресами, идентифицируются в первую очередь;

♦ 01 — динамические устойчивые (persistent) адреса устройств PSA;

♦ 10 — динамические изменчивые (volatile) адреса;

♦ 11 — устройства со случайными номерами, идентифицируются в последнюю очередь.

Младший бит этого байта указывает на поддержку PEC и всех возможностей, основанных на идентификаторе. При нулевом значении этого бита о поддержке PEC ничего определенного сказать нельзя.

Последний элемент UDID — 32-битный идентификатор устройства, играющий важную роль в распознавании похожих устройств. Это может быть либо число, назначаемое изготовителем (отвечающим за его неповторимость), либо случайное число, генерируемое (и запоминаемое) устройством каждый раз при включении или выполнении команды сброса.

Устройство, поддерживающее ARP, должно иметь специальные флаги:

♦ AR (Address Resolved) — данному устройству процедурой ARP назначен адрес;

♦ AV (Address Valid) — устройство имеет действительный личный адрес, на который оно отзывается в обычных транзакциях (при AV=0 устройство должно игнорировать все адреса, кроме «дежурного»).

При AV=AR=0 устройство не имеет личного адреса и должно участвовать в процессе ARP (отвечать на общий опрос идентификатора). При AV=1 и AR=0 устройство имеет личный адрес, но должно участвовать в ARP. При AV=AR=1 устройство имеет личный адрес, но не должно отвечать на общий запрос идентификатора. При этом оно должно отрабатывать адресованную ему команду назначения адреса (и впоследствии пользоваться новым назначенным адресом). Комбинация AV=0 и AR=1 недопустима.

Для протокола ARP введены специальные команды.

♦ Get UDID (general) — общий запрос идентификатора — команда чтения блока данных с адресом 1100 001 и кодом команды 3. На нее устройства, поддерживающие ARP, отвечают посылкой блока с длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — адрес устройства (с единицей в младшем бите). Если у устройства флаг AV=0, оно вместо адреса передает код «1111 111». Команда не влияет на флаги AV и AR.

♦ Assign address — назначить адрес — команда записи блока данных с адресом 1100 001 и кодом команды 4 и длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — назначаемый адрес устройства (младший бит игнорируется). По этой команде устройство, обнаружившее полное совпадение UDID со своим собственным, устанавливает флаги AV=AR=1.

♦ Get UDID (directed) — направленный запрос идентификатора — команда чтения блока данных с адресом 1100 001, в поле кода команды находится адрес интересующего устройства с единицей в младшем бите. На нее отвечает только устройство, опознавшее свой адрес в поле команды, и отвечает посылкой блока с длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — адрес устройства (с единицей в младшем бите). Команда не влияет на флаги AV и AR.

♦ Reset device (general) — общий сброс устройства — посылка по адресу 1100 001 байта команды с кодом 2, сопровождаемого байтом PEC. По этой команде все устройства инициализируются и обнуляют флаги AR и AV (PSA-устройства флага AV не изменяют).

♦ Reset device ARP (dirеcted) — направленный сброс устройства — посылка по адресу 1100 001 байта с адресом целевого устройства (с нулем в младшем бите), сопровождаемого байтом PEC. По этой команде выбранное устройство инициализируется и обнуляет флаги AR и AV (PSA-устройства флага AV не изменяют).

♦ Notify ARP master — уведомление ведущего устройства ARP — посылка на адрес 0001 000 байта с «дежурным» адресом 1100 0010, за которым следуют два байта нулей. Устройство может посылать это уведомление о необходимости выполнения ARP при включении питания, а также при обнаружении коллизии в процессе выполнении чтения данных по индивидуальному адресу устройства.

На каждый байт команд ARP-устройства, поддерживающие этот протокол, отвечают подтверждением ACK. Отсутствие подтверждений трактуется ведущим ARP-устройством как отсутствие ARP-устройств на шине.

«Переучет» и назначение адресов вкратце выглядит следующим образом: ведущее ARP-устройство выполняет команду общего запроса идентификатора и по ней получает UDID и, возможно, адрес первого «победителя» в арбитраже. Далее этому победителю назначается личный адрес — тот же или по усмотрению ведущего ARP-устройства, после чего он уже не участвует в арбитраже по общему запросу. Сведения об устройстве и его адрес ведущим ARP-устройством заносятся в таблицу устройств. После этого общий запрос и назначение адреса повторяются снова и снова, пока все ARP-устройства не будут удовлетворены. Признаком «общего удовлетворения» для ведущего ARP-устройства будет отсутствие подтверждений приема команд общего запроса.

Поддержка SMBus в BIOS и ACPI

Шина SMBus, в отличие от ACCESS.bus, сразу получила спецификацию ее поддержки на уровне BIOS. Позже появились спецификации, позволяющие интегрировать устройства SMBus в систему ACPI.

В 1995 г. была опубликована спецификация интерфейса SMBus BIOS — System Management Bus BIOS Interface Specification, основные идеи которой вкратце изложены ниже. Интерфейс позволяет верхним уровням ПО абстрагироваться от аппаратной реализации хост-контроллера. Поддержка BIOS обеспечивается для трех типов режимов работы процессора: реального (и V86), защищенного 16-разрядного и защищенного 32-разрядного. Вызов функций может выполняться либо через BIOS Int 15h (в реальном режиме и в V86), либо через точку входа, полученную при подключении в соответствующем режиме. Для подключения (и отключения) также используется сервис BIOS Int 15h; после подключения доступ через Int 15h блокируется (до отключения). В защищенном режиме вызов интерфейсных функций возможен только через точку входа, полученную при подключении. Поддержка точки входа для реального режима необязательна.

Спецификация SMBus BIOS обеспечивает хост-центрическое обращение к абонентам шины: по инициативе вызывающей программы хост-контроллер посылает устройству команду, которая может предполагать и немедленный ответ устройства. Однако устройства могут посылать хосту сообщения по собственной инициативе, при этом они обязаны использовать протокол Write Word. Хост способен помещать принятые сообщения в небольшую очередь, из которой они могут программно извлекаться путем вызова функции 7 (программа должна периодически выполнять этот вызов для проверки наличия сообщений в очереди). В очереди каждое сообщение представлено байтом адреса источника и парой байт тела сообщения.

Шина SMBus тесно связана с оборудованием, управляющим питанием и участвующим в генерации запросов системного прерывания SMI (System Management Interrupt — особое аппаратное прерывание процессора) и их обработки. Из-за этого в BIOS введен специальный механизм, позволяющий обнаружить обработку SMI во время выполнения транзакций и в иное время. Это необходимо, поскольку обработчик SMI, работающий в режиме SMM, совершенно невидим прикладной программе, а результаты его работы могут существенно влиять на работу программы, вызывающей BIOS SMBus.

Функции общих обращений к SMBus:

♦ SMBus Installation Check (01h) — проверка наличия функций;

♦ SMBus Real Mode Connect (02h) — подключение в реальном режиме;

♦ SMBus 16-Bit Connect (03h) — подключение в 16-битном защищенном режиме;

♦ SMBus 32-Bit Connect (04h) — подключение в 32-битном защищенном режиме;

♦ SMBus Disconnect (05h) — отключение от сервиса;

♦ SMBus Deviсе Address (06h) — получение списка адресов устройств SMBus;

♦ SMBus Critical Messages (07h) — чтение сообщений устройств, переданных хосту.

Для взаимодействия с конкретными устройствами SMBus предназначен набор функций, позволяющих генерировать запросы протокольных команд SMBus и получать результаты их выполнения. Функции запросов и получения ответов разделены, что позволяет на время выполнения (и передачи) довольно длительных команд не занимать время центрального процессора. Большинство протокольных команд вводится за один вызов BIOS; исключение составляет команда записи блока, данные для которой передаются за один или более последующих запросов продолжения. Результаты большинства команд также принимаются за один вызов; результат чтения блока получается за несколько вызовов продолжения.

Вызовы протокольных команд устройств SMBus:

♦ SMBus Request (10h) — запрос команды устройству;

♦ SMBus Request Continuation (11h) — продолжение запроса для записи блока;

♦ SMBus Request Abort (12h) — отказ от выполнения ранее посланного запроса;

♦ SMBus Request Data and Status (13h) — запрос данных и состояния.

Шина SMBus является одним из главных коммуникационных средств в ACPI. Интерфейс SMBus для ACPI определен в спецификации SMBus CMI — документе System Management Bus (SMBus) Control Method Interface Specification Version 1.0, опубликованном в конце 1999 г. Этот интерфейс позволяет легко использовать все возможности SMBus независимо от происхождения или особенностей реализации оборудования. Ниже перечислены основные цели спецификации.

♦ Обеспечить эффективный и надежный интерфейс ACPI для аппаратных средств хост-контроллера независимо от его реализации (со встроенным микроконтроллером или без него).

♦ Обеспечить системную синхронизацию доступа ко всем ресурсам SMBus.

♦ Гарантировать соответствие интерфейса версиям 1.0 и 1.1 спецификации SMBus и возможности его расширения для поддержки новых свойств в будущих версиях.

Для успешного функционирования системы требуется поддержка соответствующими драйверами операционной системы. Для управления питанием форум разработчиков «интеллектуальных» батарей — Smart Battery System Implementers Forum (SBS-IF) — разработал спецификацию драйверов для ОС Windows 9x/2000, с которой можно ознакомиться на сайте http://www.sbs-forum.org/smbus/.

Рассмотрение программного интерфейса CMI выходит за рамки данной книги. Отметим лишь, что коды протоколов SMBus, используемые в CMI, отличаются от кодов, используемых в SMBus BIOS. Те же протоколы, но с байтом PEC, кодируются с единицей в старшем бите (значение увеличено на 80h).

 

11.1.4. Сравнение шин I²C, ACCESS.bus и SMBus

Как видно из вышеприведенных описаний, все эти три шины являются «близкими родственниками»; однако они имеют ряд электрических, конструктивных и протокольных отличий.

Электрический интерфейс шин (табл. 11.5) достаточно близок, и при обычном (5 В) питании схем проблем совместимости не возникает (Vdd — напряжение питания).

Таблица 11.5. Электрические параметры шин I²C, ACCESS.bus и SMBus

¹ Вместо емкости задаются допустимые длительности фронтов и спадов.

Конструктивно выделяется шина ACCESS.Bus (внешняя), в которой определены разъемы и кабели, а также питание (5 В) устройств от шины; в других — нет.

Протокольные различия более существенны, из них отметим лишь следующие.

♦ В шине ACCESS.Bus определены лишь передачи данных ведущим устройством, в остальных шинах ведущее устройство может и принимать данные.

♦ В шинах ACCESS.Bus и SMBus ведущее устройство не имеет права повторного захвата шины ранее, чем через 50 мкс после начала передачи. Сигнал SCL в этой шине может удерживаться на низком уровне не дольше 2 мс. В I²C таких ограничений нет.

♦ В шине SMBus ведущее устройство ожидает от ведомого устройства немедленного ответа, в шине ACCESS.Bus ответ приходит независимо, но ожидается не позже чем через 40 мс. В шине SMBus и ведущее устройство, и ведомое устройство могут притормаживать обмен на уровне приема битов, что позволяет им вписываться в свои временные диаграммы (успевать «просыпаться», обрабатывать прерывания).