Pmbus что это

Источники питания на пути к цифровым технологиям

Цифровое управление расположенным на плате источником питания повышает его КПД, снижает совокупную стоимость и расширяет возможности системы контроля. Приведенные ниже сведения, взятые из Белой книги, опубликованной компанией Ericsson, являются очень актуальными для Цифрового Питания.

Цифровые технологии в преобразовании энергии

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

Цифровое питание определяется и реализуется различными поставщиками по-разному, более того, до сих пор не существует сколько-нибудь успешных крупномасштабных проектов, использующих цифровые подходы. В результате вокруг цифрового питания возникла атмосфера неопределенности и некоторой путаницы. Эффективна ли она по стоимости? Каковы ее характеристики в сравнении с обычными аналоговыми подходами? Надежна ли она? Не усложняет ли она процессы проектирования и внедрения? Требуются ли разработчики со специальными навыками? Насколько она «стандартизирована» и не возникнут ли проблемы со вторыми поставщиками?

Необходимо более комплексное определение процесса, обеспечивающего цифровую реализацию блоков и систем на основе цифрового питания. Самое главное, ответить на перечисленные вопросы так, чтобы конечный пользователь – системный интегратор или OEM-производитель – смог уверенно работать с цифровым питанием.

Почему преобразование энергии все еще находится, главным образом, в аналоговой области? Основная причина заключается в том, что первостепенное значение для большинства систем питания имеет эффективность. Независимо от того, сколько «свистков и колокольчиков» может добавить цифровая реализация, ее привлекательность будет ограниченной, если она снижает КПД. Увеличивающиеся «накладные расходы» в виде мощности, рассеиваемой дополнительными схемами цифрового управления, до самого последнего времени делали этот подход весьма непривлекательным.

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

Цифровое регулирование и управление

«Цифровое питание» – широкое понятие, включающее в себя несколько концепций и субдисциплин, предоставляющее конечному пользователю несколько различных уровней извлечения выгоды. Одной из основных особенностей цифрового питания является то, что для любого конкретного приложения конечный пользователь обычно выбирает лишь некоторое подмножество из всех доступных цифровых решений. Этот выбор будет основываться на факторах стоимости, сложности и доступности системы, а также на требованиях к техническому обслуживанию.

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

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

Регулирование источника питания

Классическая схема регулирования аналогового источника питания показана на Рисунке 1. В качестве основного элемента управления используется интегральная схема широтно-импульсного модулятора (ШИМ). Выходное напряжение источника питания измеряется на резистивном делителе напряжения и сравнивается усилителем ошибки с постоянным опорным напряжением.

Рисунок 1.

Блок-схемы аналоговых и цифровых систем управления изображены вместе с некоторыми частями силовых цепей.

Выходной сигнал усилителя ошибки используется схемой ШИМ для управления временем включения силового ключа.

Необходимая для достижения баланса между динамическим откликом и устойчивостью частотная компенсация петли ОС обычно реализуется внешней по отношению к микросхеме ШИМ цепью, состоящей из постоянного резистора и конденсатора.

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

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

На Рисунке 1 показана структура типичной системы цифрового управления электропитанием.

Выходное напряжение измеряется так же, как и в аналоговых конструкциях. Однако напряжение с токоизмерительного резистора подается не на усилитель ошибки, а преобразуется в двоичный цифровой код с помощью АЦП. C выхода АЦП сигналы поступают на микроконтроллер, который производит их обработку. Для хранения алгоритмов управления микроконтроллера используется внутриплатное ПЗУ программ.

Эти алгоритмы позволяют микроконтроллеру выполнять ряд вычислений над сигналами цифровых выходов АЦП. Результатами этих вычислений являются такие величины, как сигнал ошибки, требуемые значения ширины импульсов для драйверов, оптимизированные величины задержки на различных выходах драйверов, а также параметры частотной компенсации петли регулирования. Внешние компоненты частотной компенсации, используемые в аналоговой системе, больше не нужны.

Все значения таких параметров, как выходное напряжение, выходной ток и температура либо записываются в EEPROM при изготовлении устройства, либо передаются по коммуникационной шине. При включении питания содержимое EEPROM выгружается в ОЗУ, которое затем микроконтроллер использует для операций чтения и записи.

Цифровое управление значительно гибче аналогового в своей способности адаптироваться к изменениям входного напряжения и тока нагрузки. Оно позволяет изменять параметры управления в зависимости от условий работы источника питания. Это иллюстрируется следующими примерами.

В синхронном понижающем источнике питания верхний и нижний MOSFET управляются таким образом, чтобы они никогда не оказывались одновременно в проводящем состоянии. Это гарантируется введением «мертвого времени» – временнóго интервала между выключением одного транзистора и включением другого. При цифровом управлении мертвое время не обязательно должно быть постоянным; для оптимизации КПД источника питания его можно менять в зависимости от условий работы с помощью цифрового контура управления. Как видно из Рисунка 2, эта технология особенно эффективна при малой нагрузке.

Рисунок 2.

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

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

Примеры такого адаптивного поведения показаны на Рисунке 3. Помимо улучшенной динамической реакции этот подход дает системе питания и другие преимущества. Для поддержания заданного уровня пульсаций требуются выходные конденсаторы меньшей емкости, что позволяет сэкономить и на стоимости компонентов, и на площади печатной платы. Нелинейное управление также может использоваться для обеспечения работы источника в режиме прерывистой проводимости без присущих этому режиму плохих динамических характеристик.

Рисунок 3.

Нелинейные или адаптивные контуры управления могут сочетать преимущества устойчивости и хорошей динамики.

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

Система управления питанием

Цифровое управление предоставляет ряд преимуществ и возможностей и может использоваться на нескольких различных этапах жизненного цикла источника питания и системы питания. Ключевым словом здесь является гибкость; разработчик системы питания может выбирать только те функции и возможности, которые важны для конкретного приложения:

• В процессе изготовления источника питания для подстройки напряжений и порогов срабатывания защиты, а также для загрузки кодов даты и индивидуальных номеров, может использоваться автоматизированное тестовое оборудование (ATE).
• При оптимизации конструкции системы питания цифровой интерфейс можно использовать для измерения температуры, напряжения и выходных токов, а также для установки порогов срабатывания цепей защиты от аварийных режимов.
• Цифровой интерфейс системы управления питанием может использоваться ATE во время сборки и тестирования платы и системы.
• Хост-устройство системы управления питанием может обеспечивать заданную последовательность запуска и выключения. Можно контролировать рабочие температуры для управления вентиляторами системы охлаждения и обнаружения неисправностей, а процедуры управления могут быть разработаны так, чтобы учитывать условия в других частях системы.

Базовая архитектура цифровой системы управления питанием состоит из блоков питания, взаимодействующих с централизованной хост-системой управления через цифровую шину связи, как это показано на Рисунке 4.

Рисунок 4.	Цифровая система управления питанием, состоящая из источников питания (ведомых), подключенных к контроллеру (ведущему) через коммуникационную шину, изображенную желтыми линиями.

Источниками питания являются DC/DC преобразователи или регуляторы в точке подключения нагрузки (POL). Устройство управления может иметь различные формы, в том числе:

• Специализированная микросхема управления системой питания;
• Микроконтроллер общего назначения:
• Портативный компьютер с графическим интерфейсом пользователя;
• ATE в процессе тестирования блока питания или системы.

Объект регулирования хост-устройства состоит из одной системной платы, а в некоторых более крупных конструкциях этот хост, в свою очередь, взаимодействует с контроллерами верхнего уровня.

Система управления питанием усложняется по мере увеличения числа уровней напряжения на плате. Прежде всего, это значительно усложняет управление последовательностью подачи и снятия напряжений.

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

Рисунок 5.

Цифровое управление позволяет задавать последовательность запуска и выключения нескольких источников питания.

Еще одним примером использования цифрового управления питанием может служить контроль работоспособности источника на границах допустимых отклонений выходного напряжения. Он проводится на завершающей стадии производства для проверки устойчивости устройства. Для этого напряжения изменяются в различных комбинациях, например, на ±5% (Рисунок 6). Используя цифровую шину связи, выполнить такую проверку можно менее чем за секунду без каких-либо дополнительных аппаратных средств или подключений.

Рисунок 6.

Цифровое управление питанием может использоваться для проверки работоспособности источника на границах допустимых отклонений выходного напряжения («серединный тест»).

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

• Может быть установлена тепловая защита с цифровым программированием реакции на перегрев: либо с автоматическим перезапуском, либо с блокировкой.
• Может быть установлена защита от перегрузки по току с программируемым выбором между режимами блокировки и автоматического восстановления.
• Легко программируется порог срабатывания защиты от перенапряжения для конкретной настройки выходного напряжения – как для режима блокировки, так и для режима автоматического восстановления.

Список контрольных функций включает измерение таких параметров, как входные и выходные напряжения и токи, рабочая частота и температура внутри источников питания. Большинство конечных производителей найдет эту возможность самой востребованной на этапах разработки и оценки новой системы.

Цифровой контроль позволяет проделать все эти измерения с помощью портативного компьютера и графического интерфейса пользователя, без термопар, паяльников и замены компонентов. Сбор параметрической информации на данном этапе позволяет оптимизировать систему питания и выбрать наиболее экономически эффективные источники питания.

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

• Возможность контроля КПД и обнаружения его деградации еще до фактического отказа, благодаря чему замена может быть осуществлена без ущерба для готовности системы.
• Можно управлять скоростью вращения вентилятора системы в соответствии с фактической температурой внутри источников питания.
• Возможность опроса всех устройств в системе для поиска местонахождения источников питания с определенными серийными номерами в целях замены подозрительной партии еще до появления сбоев.

Большинству пользователей такая степень сложности в их конструкциях не нужна. Промежуточный подход основан на использовании прерываний.

Рисунок 7.

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

При этом контроллер хоста не выполняет рутинного мониторинга параметрических данных, а лишь получает уведомления от источника питания в тех случаях, когда в нем возникают проблемы (Рисунок 7). Затем, в зависимости от характера неисправности, хост может принять требуемые меры.

PMBus

Шина управления питанием (Power Management Bus – PMBus) – это существующий протокол, принятый и поддержанный несколькими производителями источников питания. Протокол принадлежит Форуму интерфейса управления системой (System Management Interface Forum – SMIF).

Членство в SMIF открыто для всех заинтересованных сторон, а спецификация PMBus общедоступна и распространяется бесплатно.

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

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

В своей исходной форме PMBus – это двухпроводная последовательная шина, основанная на шине SMBus (System Management Bus), которая, в свою очередь, является производной от популярной шины Inter-IC (I 2 C), но усовершенствованной для большей функциональности в приложениях управления питанием.

Физическая реализация стандартом PMBus не определяется. Поэтому производители блоков питания и промышленные организации, такие как Distributed-power Open Standard Alliance (DOSA) и Point of Load Alliance (POLA), сотрудничают друг с другом, чтобы договориться о стандартных конфигурациях конструктивных параметров, внешних контактов и механических интерфейсов для межсоединений устройств и их программирования.

Заключение

Цифровые технологии питания предлагались на протяжении ряда лет, но успешно конкурировать с аналоговыми решениями до последнего времени они не могли. Благодаря увеличению плотности ИС, упорной работе изготовителей полупроводниковых компонентов, развитию и повышению надежности технологии КМОП, сегодня цифровой обработка данных для приложений преобразования энергии стала весьма привлекательной. Самое главное, что использование цифровых технологий предоставляет возможность расширения функциональности и улучшения технических характеристик как отдельных источников питания, так и системы в целом, что аналоговыми методами реализовать невозможно.

Хотя основной фокус публичных обсуждений сосредоточен на проблемах, связанных с системами управления питанием, наиболее важным вопросом и, в конечном итоге, движущей силой внедрения цифровых методов, будут преимущества, которые они принесут самому источнику питания. И современные технологии делают эти преимущества реальными, измеримыми и доступными:

Более высокий КПД;

• Надежность, улучшенная за счет более высокой интеграции схем цифрового управления;
• Стоимость системы, сниженная благодаря сокращению количества развязывающих конденсаторов вследствие улучшения переходных характеристик при адаптивном цифровом управлении;
• Плотность мощности источника питания, увеличенная за счет меньших размеров цифровых схем управления;
• Более жесткие допуски на отклонения выходного напряжения благодаря повышению точности первоначальной настройки;
• Сокращение общих эксплуатационных затрат за счет перечисленных выше улучшений.

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

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

Механизм пользовательских настроек позволяет один и тот же тип источника использовать для нескольких целей, тем самым, уменьшая объемы складских запасов, сокращая номенклатуру покупных изделий и снижая затраты времени на поиск поставщиков источников питания.

Интерфейсы I2C, SMBus и PMBus

I 2 C (Inter-Integrated Circuit) – широко используемый последовательный протокол связи между микросхемами. Специалисты компании Analog Devices рассматривают его основные функции и описывают протоколы SMBus (System Management Bus) и PMBus (Power Management Bus), основанные на шине I 2 C, а также приводят различия данных протоколов и раскрывают специфику их использования.

Шина I 2 C разработана компанией Philips для организации простой связи между компонентами на одной печатной плате. I 2 C использует всего две двунаправленные линии для передачи и приема информации и является последовательным синхронным интерфейсом, то есть два или более устройств при обмене данными используют общую тактовую линию.

I 2 C широко применяется для подключения низкоскоростной периферии (светодиодных дисплеев, датчиков и т.д.) к микропроцессорам и микроконтроллерам. В этом интерфейсе есть поддержка подключения нескольких ведомых к одному ведущему и нескольких ведущих к нескольким ведомым. Такая функция полезна для оптимизации работы системы, например, для того, чтобы один микроконтроллер записывал данные на карту памяти и выводил текстовые сообщения на ЖК-дисплей, используя одну и ту же шину.

Кроме популярного стандартного интерфейса I 2 C, существуют два дополнительных протокола, использующих ту же шину: SMBus и PMBus. Эти протоколы ориентированы на управление системами и устройствами питания и позволяют существенно ускорить процесс разработки.

Описание шины I 2 C

За счет использования последовательной линии данных, линии тактовой частоты и общей земли для всех устройств количество соединений в I 2 C минимально. Каждое устройство, поддерживающее подключение по I 2 C, должно иметь два вывода (рисунок 1):

1) SDA – для приема и передачи данных от ведущего к ведомому и наоборот.

2) SCL – для передачи тактового сигнала. Тактовый сигнал всегда генерируется ведущим.

Рис. 1. Подключение микросхем по интерфейсу I 2 C

Важной частью аппаратной реализации I 2 C являются подтягивающие резисторы на линиях SDA и SCL (рисунок 2). При отсутствии передачи данных линии шины находятся в высоком состоянии. Устройства с поддержкой I 2 C подключаются к шине выводами с открытым коллектором и при передаче данных меняют уровни напряжений на шине: с высокого состояния в низкое и наоборот. Биты данных тактируются по спаду тактового импульса.

Рис. 2. Подключение подтягивающих резисторов на шине I 2 C

Для установки высокого уровня напряжения выводы с открытым коллектором должны быть внешне подтянуты к напряжению питания (V_DD). При питании 5 В наиболее часто используются подтягивающие резисторы номиналом 4700 Ом.

I 2 C является синхронным интерфейсом: передача бит синхронизируется с приемом с помощью тактового сигнала, совместно используемого ведущим и ведомым. Тактовый сигнал всегда исходит от ведущего. Максимальное количество устройств на шине I 2 C может достигать 2 7 или 2 10 , однако 16 адресов зарезервированы (таблица 1).

Таблица 1. Зарезервированные адреса I 2 C

7-битный адрес узла	Значение бита записи/чтения	Назначение
0000 000	0	Общий адрес
0000 000	1	Стартовый байт
0000 001	X	Адрес CBUS
0000 010	X	Зарезервировано для другого формата передачи
0000 011	X	Для будущих задач
0000 1XX	X	Код ведущего в высокоскоростном режиме
1111 1XX	X	Для будущих задач
1111 0XX	X	10-битный адрес ведомого

Максимальная длина шины зависит от емкости кабеля и скорости передачи. Например, экранированная витая пара AWG имеет емкость от 100 до 240 пФ/м. При ее использовании максимальная длина шины I 2 C может составлять до 1 м при скорости 100 кбит/с или 10 м при скорости 10 кбит/с. Неэкранированный кабель обычно имеет гораздо меньшую емкость, но его следует использовать только в экранированном корпусе.

В таблице 2 приведены основные характеристики I 2 C.

Таблица 2. Основные характеристики I 2 C

Данные для передачи по шине I 2 C разбиваются на кадры и передаются в формате сообщений, показанном на рисунке 3. Сообщение I 2 C содержит также адресный кадр с двоичным адресом устройства, бит чтения или записи, а также биты подтверждения после каждого кадра.

Рис. 3. Сообщение I 2 C

Микросхемы с поддержкой I 2 C должны соответствовать временным характеристикам шины, перечисленным в таблице 3. Для каждой скорости передачи данных определены значения временных параметров, которые должны соблюдаться ведущим и ведомым для корректной передачи данных.

Таблица 3. Временные параметры I 2 C

Обозначение	Параметр	Единицы измерения
fSCL	Тактовая частота	кГц
tHD(STA)	Время удержания сигналов при начале или повторе передачи	мкс
tLOW	Период низкого состояния линии SCL	мкс
tHIGH	Период высокого состояния линии SCL	мкс
tSU(STA)	Время установки сигналов при повторе передачи	мкс
tHD(DAT)	Время удержания данных	мкс
tSU(DAT)	Время установки данных	нс
tr	Время нарастания сигнала на SDA	нс
tf	Время спада сигнала на SDA	нс
tSU(STO)	Время установки сигналов для окончания передачи	мкс

Протокол передачи I 2 C

Передача по шине является операцией чтения или записи. Протокол I 2 C описывает процедуру начала и окончания передачи, повтор сообщения, порядок передачи адреса и данных, а также подтверждение получения.

Передача сообщения всегда инициируется ведущим устройством. Для того, чтобы начать передачу, ведущий переключает линию SDA в низкий уровень до спада тактового импульса на линии SCL (рисунок 4).

Рис. 4. Начало передачи сообщения

После передачи одного сообщения ведущий может снова переключить линию SDA до спада SCL и повторно передать данные. Повтор передачи (рисунок 5) используется для перенаправления данных другому ведомому, для повторной попытки передачи, синхронизации нескольких микросхем или для связи с последовательной памятью.

Рис. 5. Повторная передача

В I 2 C нет выделенных линий для выбора микросхемы, как в SPI. Для того, чтобы сообщить устройству, что данные отправляются именно ему, используется адресация. Адресный кадр всегда отправляется после процедуры начала передачи в новом сообщении и имеет размер 7 или 10 бит (рисунок 6). Ведущий отправляет адрес всем подключенным к нему устройствам. Каждое устройство сравнивает полученный адрес со своим собственным и при совпадении отправляет ведущему бит подтверждения (ACK) низкого уровня. Если адрес не совпадает, устройство ничего не делает, и линия SDA остается в высоком состоянии.

Рис. 6. Адресный кадр сообщения

В конце адресного кадра отправляется бит, который задает операцию чтения или записи. Если ведущий собирается записать данные в устройство, отправляется нулевой бит, при чтении отправляется единица (рисунок 7).

Рис. 7. Бит чтения/записи

После каждого кадра в сообщении на шине ожидается бит подтверждения ACK. Если адресный кадр или кадр данных был успешно получен, то возвращается бит подтверждения (на рисунках 4…9 этот бит обозначен белым).

После получения бита подтверждения отправляется первый кадр данных. Кадр данных всегда имеет длину 8 бит и отправляется старшим битом вперед. После каждого кадра ожидается бит подтверждения, чтобы удостовериться в успешном получении данных (рисунок 8).

Рис. 8. Кадр данных

После передачи всех кадров данных ведущий проводит процедуру окончания передачи. Для этого ведущий переводит линию SDA с низкого состояния в высокое после установки тактового сигнала в высокий уровень (рисунок 9). Линия SCL остается в высоком состоянии.

Рис. 9. Окончание передачи

Операция записи на I 2 C

На рисунке 10 представлена временная диаграмма передачи данных по I 2 C при записи.

Рис. 10. Передача по I 2 C при записи

Пошаговая последовательность действий при операции записи следующая:

1) Ведущий инициирует начало передачи для всех подключенных устройств, переключая линию SDA с высокого состояния в низкое перед спадом сигнала на SCL.

2) Ведущий отправляет всем 7- или 10-битный адрес устройства вместе с битом записи. Например, при 7-битном адресе устройства 0x2D ведущий, добавив нулевой бит записи, отправляет на шину 0x5A.

3) Каждое устройство на шине сравнивает адрес, отправленный ведущим, со своим собственным. Если адрес совпадает, устройство возвращает бит подтверждения ACK, переключая линию SDA в низкое состояние на девятом такте SCL. Если адрес не совпадает, устройство оставляет линию SDA в высоком состоянии.

4) Ведущий отправляет кадры данных: указатель адреса для записи (ADDR) и сами данные.

5) После передачи каждого кадра данных ведомое устройство возвращает ведущему нулевой бит подтверждения ACK, обозначая успешное получение кадра либо единичный бит NACK при сбое записи.

6) Для окончания передачи ведущий переключает линию SCL в высокое состояние после нарастания сигнала на линии SDA.

Операция чтения на I 2 C

На рисунке 11 показана передача данных при операции чтения по I 2 C.

Рис. 11. Передача по I 2 C при чтении

Пошаговая последовательность действий при операции чтения следующая:

1) Ведущий инициирует начало передачи для всех подключенных устройств, переключая линию SDA с высокого состояния в низкое перед спадом сигнала на SCL.

2) Ведущий отправляет всем 7- или 10-битный адрес устройства вместе с битом записи. Например, при 7-битном адресе устройства 0x2D ведущий, добавив нулевой бит записи, отправляет на шину 0x5A.

3) Каждое устройство на шине сравнивает адрес, отправленный ведущим, со своим собственным. Если адрес совпадает, устройство возвращает бит подтверждения ACK, переключая линию SDA в низкое состояние на девятом такте SCL. Если адрес не совпадает, устройство оставляет линию SDA в высоком состоянии.

4) После передачи и подтверждения указателя адреса для чтения (ADDR) ведущий повторно инициирует передачу.

5) Ведущий отправляет всем 7- или 10-битный адрес устройства вместе с битом чтения. Например, при 7-битном адресе устройства 0x2D ведущий, добавив единичный бит чтения, отправляет на шину 0x5B.

6) Каждое устройство на шине сравнивает адрес, отправленный ведущим, со своим собственным. Если адрес совпадает, устройство возвращает бит подтверждения ACK, переключая линию SDA в низкое состояние на девятом такте SCL. Если адрес не совпадает, устройство оставляет линию SDA в высоком состоянии.

7) После подтверждения ведущий считывает кадр данных от ведомого устройства.

8) После получения каждого кадра данных ведущий возвращает нулевой бит подтверждения ACK ведомому, обозначая успешное получение кадра либо единичный бит NACK при сбое считывания.

9) Для окончания передачи ведущий переключает линию SCL в высокое состояние после нарастания сигнала на линии SDA.

Арбитраж на шине I 2 C

Адресация протокола I 2 C позволяет управлять несколькими устройствами от одного ведущего. При 7-битном адресе доступно 128 (2 7 ) уникальных адресов. Использование 10-битного адреса встречается реже. Для подключения нескольких устройств к шине на линиях SDA и SCL необходимы подтягивающие резисторы 4,7 кОм. Кроме этого, к одному или нескольким устройствам можно подключить несколько ведущих. Чтобы исключить ситуацию, когда несколько ведущих одновременно используют линию SDA, каждый ведущий должен отслеживать состояние линии SDA перед передачей сообщения. Если линия SDA в низком состоянии, то шиной уже управляет другой ведущий, и необходимо дождаться окончания передачи. Для подключения нескольких ведущих используется схема, показанная на рисунке 12.

Рис. 12. Подключение нескольких ведущих к ведомым

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

Такая процедура арбитража проста и эффективна:

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

2) Теоретически проигравший может прослушивать адрес ведомого во время арбитража и корректно отвечать.

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

Задержка тактового сигнала

Тактовая частота всегда генерируется ведущим и синхронизирует обмен данными между ведущим и ведомым. Спецификация I 2 C не регламентирует каких-либо тайм-аутов на тактовый сигнал, то есть любое устройство на шине может удерживать линию SCL в низком состоянии неограниченное время. Такая процедура называется задержкой тактового сигнала и полезна в случаях, когда ведомое устройство не может сразу отправить ответные данные и снижает скорость шины, удерживая линию SCL в низком состоянии. Например, ведомому микроконтроллеру или какому-либо другому обрабатывающему устройству может потребоваться дополнительное время для обработки прерывания, приема данных и для выполнения каких-либо функций. В таком случае ведущий считывает состояние SCL и дожидается, когда ведомый вернет линию в высокое состояние. Для более простых устройств, например, EEPROM, задержка частоты не требуется, так как они не выполняют обработку данных.

Задержка тактового сигнала может значительно снизить общую пропускную способность шины. Необходимо это учитывать, чтобы сохранить надежность передачи и скорость обмена данными, особенно при подключении нескольких устройств на одну шину.

Регистры I 2 C

Техническое описание и регистры I 2 C в документации различных микросхем могут отличаться в зависимости от производителя. На рисунке 13 показан пример описания микроконтроллера с поддержкой I 2 C, а в таблице 4 приведены основные регистры интерфейса. Названия регистров и их описания могут быть другими, однако их назначение и использование – общее для всех устройств.

Рис. 13. Регистры памяти микроконтроллера

Таблица 4. Описание регистров I 2 C

Название	Описание
I2C_ADDR1	Первый байт адреса ведущего
I2C_ADDR2	Второй байт адреса ведущего
I2C_BYT	Стартовый байт
I2C_ID	Адрес ведомого
I2C_MCTL	Регистр управления ведущим
I2C_MRX	Данные, полученные ведущим
I2C_SCTL	Регистр управления ведомым
I2C_SRX	Данные, полученные ведомым
I2C_STAT	Статус FIFO ведомого или ведущего

Программная реализация I 2 C варьируется в зависимости от задачи. В таблице 5 показан пример основных составляющих API-драйвера I 2 C.

Таблица 5. Программная реализация I 2 C

На стороне ведущего	На стороне ведомого
Инициализация
Обработчик приема данных (Tx Handler)	Обработчик приема данных (Tx Handler)
Обработчик передачи данных (Rx Handler)	Обработчик передачи данных (Rx Handler)
Прерывание по событию
Прерывание по ошибке

Описание протокола SMBus

SMBus как правило используется в компьютерных материнских платах и встроенных системах и имеет расширенную спецификацию для мониторинга температуры, напряжения питания, управления вентиляторами и встроенными микросхемами. Шина SMBus аналогична I 2 C и имеет две линии: линию тактовой частоты SMBCLK и линию данных SMBDAT (рисунок 14). I 2 C и SMBus совместимы, однако имеют значительные отличия:

1) Пороги логических уровней SMBus фиксированы и не пропорциональны напряжению питания устройств, что позволяет устройствам с разным питанием работать на одной и той же шине. Например, на одной шине SMBus могут быть устройства с питанием 1,8; 3,3 и 5 В.

2) Обе шины работают со скоростью до 100 кГц, но I 2 C имеет варианты на 400 кГц и 2 МГц.

3) Для повышения надежности шины SMBus регламентирует минимальную тактовую частоту и ограничивает количество тактов, которое можно задержать при передаче одного сообщения. При нарушении этого ограничения устройства перезапускают шину, сбрасывая свои выводы. Таймаут SMBus составляет 35 мс при минимальной тактовой частоте 10 кГц.

4) В SMBus есть проверка ошибок в пакетах. Байт кода ошибки добавляется в конце каждого сообщения.

5) Также есть ряд различий, включающий типы передачи, линию оповещения, линию приостановки и включение/отключение питания.

Устройства на шине SMBus должны отправлять подтверждение каждый раз в ответ на получение своего адреса независимо от своей занятости. Это гарантирует, что ведущий сможет точно определить, какие устройства активны на шине. Все посылки на шине регламентируются различными спецификациями протокола SMBus. Опционально SMBus может иметь дополнительный сигнал SMBALERT#, который используется ведомыми для уведомления ведущего о появлении новой информации или, например, для быстрого оповещения о неисправности.

Рис. 14. Подключение на шине SMBus

Адреса в протоколе SMBus имеют длину 7 бит и обычно выражаются в бинарном формате, например, 0110 110b. К этим 7 битам добавляется один бит чтения/записи. Ведущий может отправлять искомый адрес на одно или несколько устройств (в случае широковещательной передачи).

На рисунке 15 представлен формат сообщения SMBus. Начало и окончание передачи происходит по фронтам и спадам сигналов на линиях шины, поэтому они обозначены без количества битов.

Рис. 15. Сообщение SMBus

В таблице 6 перечислены отображенные также на рисунке 16 временные параметры шины, которые регламентирует спецификация SMBus.

Таблица 6. Временные параметры SMBus

Обозначение	Параметр	Единицы измерения
fSMB	Рабочая частота SMBus	кГц
tBUF	Время между окончанием передачи и началом новой передачи	мкс
THD-STA	Время удержания сигналов при начале или повторе передачи	мкс
TSU-STA	Время установки сигналов при повторе передачи	мкс
tSU(STO)	Время установки сигналов при окончании передачи	мкс
tHD(DAT)	Время удержания данных	нс
tSU(DAT)	Время установки данных	нс
tTIMEOUT	Таймаут низкого состояния тактовой линии	мс
tLOW	Полупериод низкого состояния тактовой линии	мкс
tHIGH	Полупериод высокого состояния тактовой линии	мкс

Рис. 16. Временная диаграмма передачи данных на шине SMBus

Описание протокола PMBus

В дополнение к SMBus существует протокол PMBus. PMBus – это открытый стандарт управления питанием, который является гибким и универсальным средством для обмена данными между устройствами в цифровом или аналоговом виде. PMBus обеспечивает полную совместимость устройств, упрощая их подключение и сокращая время разработки систем.

PMBus используется для подключения источников питания с функциями управления. В этом протоколе есть поддержка команд и описаны структуры, наиболее часто используемые в задачах управления питанием. Например, протокол PMBus предоставляет команду для установки и считывания значений перенапряжений, что является одной из важнейших задач в управлении питания. Протокол работает поверх шин SMBus и I 2 C и дополняет их функциональность. То есть, I 2 C и PMBus совместимы по электрическим параметрам и семантике команд. Однако спецификация I 2 C описывает только физический уровень, синхронизацию и управление потоком данных на шине. I 2 C не описывает формат сообщений, в отличие от SMBus, и не описывает содержание сообщений, в отличие от PMBus. Другими словами, PMBus добавляет транспортный уровень сети, регламентируя передачу битов и байтов и их значение.

Реализация PMBus

Для систем с резервированием можно использовать до трех сигналов для установки адреса источника питания. В случае остальных систем для адресации используются два сигнала, а указатель адреса начинается со значения B0h. В таблице 7 представлены возможные коды адресов в PMBus.

Таблица 7. Адресация PMBus

Используемые адреса	Основная адресация, используемая для большинства источников питания с двумя адресными выводами				Дополнительные адреса для источников питания с тремя адресными выводами
Адресация в системе: Адрес2/ Адрес1/ Адрес0	0/0/0	0/0/1	0/1/0	0/1/1	1/0/0	1/0/1	1/1/0	1/1/1
Адрес устройства PMBus	B0h/B1h	B2h/B3h	B4h/B5h	B6h/B7h	B8h/B9h	BAh/BBh	BCh/BDh	BEh/BFh

Подключенные к шине источники питания должны быть совместимы со спецификацией SMBus 2.0 для высокого напряжения. Шина должна работать при напряжении питания 3,3 В.

Схему подключения к PMBus необходимо питать от отдельного выхода источника. В случае систем с резервированием питание должно подаваться от одного из нескольких параллельно подключенных источников. Внутри источников на линиях SCL или SDA могут быть подключены подтягивающие резисторы небольших номиналов. Основные подтягивающие резисторы устанавливаются внешне и подтягивают линии к напряжению 3,3 или 5 В.

Источник питания с PMBus должен поддерживать максимальную скорость SMBus 100 кбит/с и по возможности не использовать функцию задержки тактовой частоты, так как это замедляет работу шины.

Заключение

SMBus изначально разработан для облегчения разработки систем управления питанием. Этот протокол использует шину I 2 C и дополняет ее спецификациями более высокого уровня, которые позволяют заменять устройства на шине без перезагрузки всей системы. PMBus в свою очередь расширяет возможности SMBus, добавляя в протокол набор команд для управления источниками питания и предоставляя пользователю такие атрибуты устройств как напряжение, ток, температура и т.д. В общем случае, устройства поддержкой I 2 C, SMBus или PMBus могут использовать одну и ту же шину совместно без каких-либо существенных проблем.

Все три протокола широко используются и имеют следующие преимущества:

• Использование только двух проводов для подключения;
• Наличие подтверждения получения сообщений;
• Возможность подключения нескольких ведущих и нескольких ведомых на одну шину;
• Простота аппаратной реализации (проще, чем UART).

Недостатком протоколов является ограничение кадра данных 8 битами. Кроме того, эти протоколы работают при более низкой скорости передачи данных и имеют более сложный физический уровень в сравнении с интерфейсом SPI.

I 2 C, SMBus и PMBus применяются для работы с различными датчиками, EEPROM, тачскринами, для соединения микроконтроллеров и для отладки, в управлении питанием, а также в бытовой технике.

В таблице 8 представлены общие технические характеристики всех трех протоколов I 2 C, SMBus и PMBus: используемые сигналы, временные и электрические параметры.

Шина управления питанием — Power Management Bus

В Шина управления питанием (PMBus) — это вариант Системная шина управления (SMBus), предназначенный для цифрового управления Источники питания. Как и SMBus, это относительно медленный двухпроводной протокол связи на основе I²C. В отличие от любого из этих стандартов, он определяет значительное количество специфичных для предметной области команд, а не просто говорит, как взаимодействовать с помощью команд, определенных читателем.

Содержание

Обзор

Первая часть дает обзор с особым упором на SMBus, а вторая часть подробно описывает все команды, определенные для устройств PMBus. Существуют как стандартизированные команды, так и команды, специфичные для производителя. Требования соответствия для PMBus минимальны и описаны в Части I спецификации. См. Полную информацию в спецификации PMBus 1.1.

Сравнение с SMBus

На самом низком уровне PMBus следует за SMBus 1.1 с некоторыми отличиями. Эта информация представлена ​​более подробно в Части I спецификации PMBus:

• Допускается скорость шины 400 кГц (по сравнению с пределом 100 кГц для SMBus)
• В PMBus блоки могут включать до 255 байтов (по сравнению с 32-байтовым пределом SMbus).
• Как и в SMBus 2.0, используется только семибитная адресация.
• Некоторые команды используют вызовы блочного процесса SMBus 2.0.
• Для уведомления хоста о сбоях можно использовать механизм SMBALERT # или протокол уведомления хоста SMBus 2.0.
• Устройства PMBus должны поддерживать групповой протокол, согласно которому устройства откладывают выполнение команд до тех пор, пока не получат завершающий STOP. Поскольку перед этим STOP команды могут быть отправлены множеству различных устройств, это позволяет мастеру PMBus синхронизировать свои действия.
• Определен протокол «расширенных команд», использующий второй командный байт для добавления еще 256 кодов для стандартных и специфичных для производителя команд.

Команды PMBus

Командное пространство PMBus можно рассматривать как доступное для чтения и часто записываемых атрибутов устройства, таких как измеренные уровни напряжения и тока, температуры, скорости вращения вентиляторов и т. Д. На разных устройствах будут отображаться разные атрибуты. Некоторые устройства могут отображать такие атрибуты на нескольких «страницах», как, например, одна страница, управляющая каждой шиной питания (возможно, 3,3 В, 5 В, 12 В, –12 В и программируемый источник питания, поддерживающий 1,0–1,8 В). Устройство может устанавливать пределы предупреждений и ошибок, превышение которых будет предупреждать хост и, возможно, запускать восстановление после сбоя. Разные устройства будут предлагать разные возможности.

Возможность запрашивать у устройства PMBus 1.1 о его возможностях может быть особенно полезной при создании инструментов, особенно в сочетании с возможностью хранить пользовательские данные на устройствах (например, в EEPROM ). Без такой возможности запроса доступны только подверженные ошибкам внешние данные конфигурации.

Часть II спецификации PMBus охватывает все стандартные команды PMBus. В нем также описаны модели для управления выходной мощностью и током, управления неисправностями, преобразования значений в форматы, понятные для данного устройства, и из них, а также доступа к предоставленной производителем информации, такой как данные инвентаризации (модель, серийный номер и т. Д.) И рейтинги устройства. .

Реализации

По состоянию на лето 2007 года PMBus является относительно новым, поэтому не многие продукты рекламируют его поддержку. Учитывая богатство спецификации, реализации на базе микропрограмм, работающие в микроконтроллеры вероятно, проще всего обеспечить, хотя некоторые из текущих продуктов не включают микроконтроллеры. Одним из примеров на основе прошивки является Texas Instruments. UCD9112. Другой использует около 2 Кбайт кода на Atmel AVR 8-битный микроконтроллер на Контроллер платы NGW100.

Осенью 2009 года будет доступно больше товаров. NXP PIP8000 и Maxim MAX16064 — два недавно анонсированных чипа, которые имеют графический пользовательский интерфейс, предоставляемый поставщиком (непереносимый: только для MS-Windows).

По мере развертывания систем PMBus инструменты для управления этими системами должны стать важными. Некоторые из них можно использовать просто во время производства, чтобы настроить параметры системы, используемые с реконфигурируемыми подсистемами питания. Другие будут полезны для оптимизации времени выполнения, например, с фермами серверов.

Вопросы патентования

В январе 2008 года Power-One выиграла судебный процесс о нарушении патентных прав между ними и Artesyn Technologies в отношении преобразователей, поддерживающих PMBus. Power-One утверждает, что приложениям PMBus нужна их лицензия. Потенциальные пользователи PMBus должны сами изучить проблему. Смотрите внешние ссылки.

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

После установки сервера в самодельную конструкцию порой хочется подключить к нему ещё чего-нибудь: например, датчики температуры, давления, влажности, ЖК-экранчики или даже ШИМ-драйверы моторчиков. Бывают глючные внешние устройства, которые приходится удалённо и жёстко сбрасывать с помощью реле, не уровнив при этом весь сервер целиком. А может, читателю просто захотелось гребёнку GPIO с гирляндой светодиодов? Если это не одноплатник типа Raspberry Pi, а полноразмерный сервер, приходится навешивать микроконтроллер и возиться с ним: писать прошивку, тестировать, налаживать стык с хостом и т.д. Иногда это интересно само по себе, но бывает и наоборот: скорей бы скриптину написать да запустить, наконец, лишь бы работало.

Необычные разъёмы на железе всегда вызывали у автора смешанные чувства инженерно-технического зуда и вентиляторного фетишизма. Об этих занимательных разъёмах здесь и речь.

DISCLAIMER

Если вы читаете эту статью где-то за пределами портала Geektimes, рекомендую через недельку-другую заглянуть по аутентичной ссылке. Дело в том, что наиболее интересные комментарии читателей появятся там (т.е. тут) во врезках, я уже не говорю об устранении недочётов и ляпов. Бывает, что плохую статью рассерженные резиденты клуба буквально рвут на клочки, попутно отправляя автора в кармическую бездну. Другими словами, если аутентичная ссылка не открывается, то не стоит и читать дальше этого места.

Автор передаёт привет Дальнему Востоку (прямо из неба над Северной Атлантикой), а также приносит извинения вдалельцам уважаемых торговых знаков: они настолько не нуждаются в рекламе, что я придумываю им шуточные названия. Таким образом, статья применима к изделиям Супер Мирон, но автор практически не сомневается в наличии аналогичных механизмов на изделиях Харлампий-Панкрат, Иван Брал Марью, Ильтан, Долян и других: занимательные коннекторы чаще всего можно встретить на блоках питания и дисковых корзинах. Заодно попытаемся разоблачить и хвалёный Кобзарь Линк.

Уважаемые специалисты по серверным платформам, IPMI, I²C, SMBus и PMBus, поправляйте, если что не так. Обычно автор выражает признательность креативным читателям кармическими баллами, но приносит извинения тем резидентам клуба, кому благодарность уже была выписана ранее, просто НЛО не велит делать это дважды. Желаю приятного прочтения.

Из того, что было

Автор не стыдится покупать за копейки серверные материнские платы б/у и давать им вторую жизнь. Старая, шумная серверная механика (с блоками питания) отправляется в утиль и заменяется на новые изделия, хоть и потребительского класса, но качественные и тихие. Зато даже из винтажных серий Супер Мирон X8 и X9 до сих получаются просто офигенские NAS для малого бизнеса, сочетающие enterpise-функции, файловую «машину времени» против троянов-вымогателей и репликацию по сети…

Вообще, лет 20 назад для колхозинга в качестве GPIO умельцы использовали параллельный порт для принтера, но попробуйте сейчас его найти. Мир изменился, как по мне — так в лучшую сторону:)

Визуальный осмотр

У меня уже почти ископаемое, но вполне рабочее изделие X9SCM-F (Intel C204 Express), плюс на соседнем объекте уже пару лет трудится его младший брат X9SCL-F (C202). Если повернуть изделие, как в документации, 24-контактным разъёмом питания ATX к северу, то SATA-порты окажутся где-то в районе Хабаровска. Ещё восточнее, подобно Петропавловску-Камчатскому, находится пара разъёмов T-SGPIO 1 и 2, привлекающих внимание сочетанием букв «GPIO». На это сочетание автор и повёлся, но рефлексы геолога-исследователя ископаемой электроники оказались ложные. На самом деле ключевое слово здесь SGPIO, это дуплексная сигнальная шина с разделением каналов по времени, использующая кадры постоянной длины. Шина по очереди передаёт по три бита для каждого SATA-порта: на HBA — состояние корзины, а на корзину — состояние дисков (активен, отказал, локатор). Это устаревшая технология, современные корзины используют I²C. Я не копал очень глубоко, но похоже, что 6 бортовых SATA-портов разделили на группы из двух северных и четырёх южных, и каждой группе повесили свою гребёнку T-SGPIO. Громоздко, неуклюже, а для колхозинга ещё и бесполезно. Идём дальше, есть маленький разъёмчик JWF1 в районе Южно-Сахалинска, но это просто питание 5В для накопителя SATA DOM, которого у меня нет. На Дальнем Востоке больше делать нечего. Вдоль южных границ раскинулась целая гряда парных 9-контактных разъёмов USB и второй порт RS232, с ними всё понятно. На Северо-Западе от COM2 обнаружилась пара перемычек JI2C1/JI2C2, открывающих доступ к устройствам PCIe. Этот инструментарий для меня пока остался загадкой, но я почти уверен, что по факту JI2C1/JI2C2 суть живые выводы SCL и SDA, просто отделённые от питания 3.3В и «земли», которые и так есть в PCIe. Оставим пока. Коннектор JTPM больно мудрёный, это на крайний случай. А от коннектора передней панели JF1 можно отжать разве что UID LED, подключив его к оптореле. Кстати, это м.б. даже удобно: ограничительный резистор уже встроен в цепь, включил UID LED — открыл (закрыл) реле. Для удалённого сброса внешнего устройства, пожалуй, хватит. Главное, чтобы оператор, зайдя спустя год в веб-интерфейс BMC, не включил UID LED просто так, заодно сбросив и внешнее устройство. Ладно, возвращаемся на крайний сервер север, именно там, возле ATX-питания, и расположился разъём JPI2C.

Надо сказать, что документация по поводу JPI2C довольно оптимистична. Из неё следует, что это выход шины I²C для мониторинга здоровья «родного» блока питания. Физически JPI2C суть 5-контактный разъём Molex типа SL с шагом 0.1″ (2.54мм) и ключём защиты от дурака перепутанной полярности, предположительно код по каталогу 70543-0004. Ответная часть (на картинке слева внизу) — это Molex 70066-0179 под обжим кримпером (aka ). Я подозреваю, что на всех материнских платах Супер Мирон шина I²C используется для мониторинга здоровья серверного блока питания и выведена именно 5-контактным разъёмом Molex SL (). Забегая вперёд, скажу, что некоторые пользователи преуспели в реверсной инженерии и нашли способ вынимать из родных блоков питания Супер Мирон всякие полезности вроде температуры и вольт с амперами, читайте дальше.

Power Supply I²C Connector

Пустой разъём JPI2C откровенно дразнил стандартными контактами шины I²C: SCL, SDA, GND и VCC. Посередине — аварийный сигнал отказа блока питания. Забегая вперёд, рискну предположить, что этот Power Fail — единственный способ поднять тревогу по внешнему событию, не используя внешний микроконтроллер. Затем нашлась и статья FAQ ID 9492 от 30 марта 2010г, явно намекающая на возможность опрашивать шину I²C прямо из командной строки. Раз уж BMC явно участвует в мониторинге здоровья блока питания, а команда ipmitool явно способна «разговаривать» по шине I²C с блоками питания, ничто не должно мешать подключить к JPI2C ещё что-нибудь эдакое.

К чему я? К тому, что разъём JPI2C на платах Супер Мирон выглядит точно так же, как аудио-разъём на старом CD-приводе, только имеет 5 контактов вместо 4. В JPI2C вполне войдёт простой однорядный , но лучше иметь разъём с физическим ключом полярности типа , при работе с уже установленной в корпусе материнской платой ошибиться будет слишком легко. Экономьте своё время.

Начинающим для прототипирования рекомендую цветной «наборный» 40-контактный шлейф, который при необходимости можно дербанить на более узкие составляющие. Шлейф нужной ширины отрывается легко, как качественная туалетная бумага, т.е. строго по перфорациям. Поставляется с разными длинами и контактами типа M-F, M-M или F-F. Поиск на aliexpress: «dupont cable».

Работа с устройствами по I²C из командной строки

Я подключил к JPI2C купленный когда-то на aliexpress сенсор BMP180. Сперва ничего не вышло. Недоумение вызвала и адресация в целом, и аргумент bus , выбирающий одну шину непонятно из скольких. Но затем я просто сделал скрипт для перебора (сканирования) шин и сравнил результат его работы до подключения BMP180 и после. С платой X9SCM-F датчик тут же обнаружился на шине №3 по адресам 0xee и 0xef (см. комментарий ниже). Надо будет переставить JI2C1/JI2C2 в положение ENABLE и посмотреть, вдруг ещё и платы PCIe отзовутся…

Скрипт перебирает только чётные адреса и не трогает зарезервированные. В I²C самый младший бит является признаком чтения-записи: каждое устройство как бы занимает два адреса (чтение по нечётным, запись — по чётным). Статья FAQ ID 9492 меня запутала, потому что опрашивает только чётные. Но ведь в случае ipmitool чтение или запись определяются не адресом, но контекстом команды, верно? Увесистая спецификация IPMI 2.0 поставила всё на места: младший бит адреса в команде Master Read-Write ( 0x06 0x52 ) вообще зарезервирован и должен быть сброшен (равняться нулю).

Датчик BMP180, подключенный к JPI2C на плате X9SCM-F, отозвался по (bus=3) на адресе 0xee (и 0xef , хотя это то же самое). Т.е. логический адрес устройства оказался 0x77 , как и положено по datasheet (Bosch отхватил самый верхний 8-битный адрес). Моей изначальной ошибкой было искать BMP180 на «сыром» IPMI-адресе 0x77 , это неверно, для IPMI надо просто умножить логический I²C-адрес на два (сдвинуть на один бит влево). При работе с I²C это, кстати, самая распространённая ошибка.

Висящая просто так шина I²C неинтересна ни в воздухе, ни тем более в сферическом вакууме. Известная площадка по запросу «i2c sensor» предложит уважаемому читателю широкий ассортимент датчиков, уже обвязанных на мини-платах. Обычно остаётся только контактную гребёнку припаять, для этого достаточно желания и паяльника на 30Вт с припоем и флюсом, навыки не требуются. Для проверки теории я решил померить температуру датчиком BMP180, но это оказалось несколько сложнее, чем я думал: датчик является примером сложного stateful-устройства, и правильнее будет сказать «извлечь показания температуры и давления из прецизионного измерителя с учётом калибровочных коэффициентов». Но сперва всё-таки отдадим должное уважаемому вендору.

Сразу оговорюсь, что данная задача м.б. интересна, например, для профилировании фактической мощности серверов при эксплуатации центров обработки данных: если группа серверов подключена к одному распределителю, поди разберись, сколько потребляют серверы А и Б без учёта В и Г, даже при наличии навороченного ИБП, питающего стойку. Это всё и предлагается выяснить через IPMI, получая прямо по сети мгновенные значения с выбранных серверов. Для DIY кроме подбора ИБП и построения системы охлаждения с обратной связью лично мне в голову ничего не приходит.

Пользователь Andrew Grekhov разбирался с родными блоками питания вендора Супер Мирон, вынимая из них напряжения, токи и температуры. Весьма занимательно, хотя и заметно, что считываемые значения АЦП явно приходится поправлять на некие калибровочные константы. Хочу отметить, что при наличии интерфейса ядра команду ipmitool можно запускать и на самом хосте, без параметров -H, -U и -P, а вместо можно было бы написать просто , «семёрка» суть битовое поле, см. описание команды Master Read-Write в спецификации IPMI.

Отдадим должное пользователю Andrew Grekhov, смело ринувшемуся в неравный бой со сложным и недокументированным (как ему показалось) устройством. К счастью, он не забыл упомянуть PMBus, что и навело меня на официальный сайт и соотв. спецификации. Ведь PMBus суть специализированная надстройка над SMBus для управления системами питания, а сама SMBus, в свою очередь, является развитием I²C. Можно предположить, что большинство современных управляемых блоков питания используют ту или иную спецификацию PMBus. Потому как глядя на все имеющиеся навороты PMBus и готовые микросхемы, возникает простой вопрос: какой смысл изобретать велосипед? Но повторю, это моё предположение.

Итак, копнув чуть глубже, можно найти описание команд (регистров), используемых управляемыми блоками питания, например, по PMBus rev 1.1. Если ссылка не открывается, зайдите на сайт www.pmbus.org, откройте раздел со старыми спецификациями и найдите PMBus Specification Part II Rev. 1.1. Это документ с описанием команд, см. Таблицу 26 в разделе APPENDIX I. Command Summary. Обратите внимание, например, на команды-регистры 0x78 (STATUS_BYTE), 0x88 (READ_VIN), 0x89 (READ_IIN), 0x95 (READ_FREQUENCY) и другие: они в точности совпадают с результатами реверсной инженерии, опубликованных на форуме по ссылке выше. Возвращаясь в таблицу 26, справа дана разрядность регистра (Read Byte или Read Word) с количеством считываемых байт. Просто на всякий случай, а вдруг читатель забыл разницу между byte и word?

Но остаётся вопрос: можно ли вообще считать по I²C калибровочные коэффициенты командой 0x30 (COEFFICIENTS), использующей пакетную операцию стандарта SMBus? Это нужно, чтобы преобразовать сферически-вакуумные регистры в реальные вольты, амперы и т.д. Если я всё верно понял, то с точки зрения шины SMBus нужно отправить пакет с командой 0x30 и счётчиком байт 2, тело пакета суть два байта с кодом интересущего регистра (0x88 для READ_VIN) и признаком направления, который для считывания должен быть равен единице. В ответ устройство должно выдать пакет из 1 + 5 + 1 байт с параметрами m, B и R, которые используются для пересчёта в физические вольты. Первый байт — длина, последний — PEC (если используется). Т.е. интрига заключается в том, можно ли передать простой пакет SMBus по I²C, например, таким способом:

Этим самым я пытаюсь отправить пакет на устройство с адресом 0x70 , сидящее на шине №3, после чего принять с устройства 7 байт (один байт с длиной пакета, пять байт коэффициентов, один байт PEC). Адрес блока питания нужно заменить на фактический (первый может быть 0x78 , за ним — резервные блоки), а вместо 7 байт можно попробовать считать 6 (без PEC). Если у кого-нибудь есть родной блок питания Супер Мирон, попробуйте, только не в production, ибо я за последствия не ручаюсь:) Если все предположения верны, можно получать весьма подробную картину непосредственно из блока питания, параметров там просто тьма.

Сенсор BMP180 измеряет давление и температуру. Он выдаёт показания через двухбайтные регистровые пары, предварительно выбираемые записью однобайтного номера регистра по IPMI-адресу 0xee с последующим чтением пары байт оттуда же. Именно поэтому я называю BMP180 stateful-устройством, т.е. имеющим селекторы состояния (это м.б. важно с точки зрения конфликтологии). Предком BMP180 является BMP085, а потомком — BMP280, измеряющим ещё и влажность.
Как и в случае с алкотестером, измерения не происходят сами по себе, но запускаются командой. Для измерения только температуры следует записать код 0x2e в регистр 0xf4 :

Здесь 0x00 означает, что мы ничего не считываем с адреса 0xee , а только записываем по нему. Через примерно 4.5мс можно прочитать 16-битный показатель UT («нескомпенсированная температура») из регистра 0xf6 простой командой:

Она сперва выбирает номер регистра 0xf6 по адресу 0xee (т.е. логическому 0x77 , это BMP180), а затем считывает оттуда же два байта. Команда IPMI Master Write-Read специально сделана для таких stateful-устройств.

У меня из UT считалось 0x6a 0x48 , что соответствует десятичному 27208 (т.е. что-то около 27°C при «нормальном» давлении, если я правильно понимаю логику BMP180, специалисты, поправляйте). Если из UT считывается 0x8000 , это признак ошибки, сперва нужно было запустить измерение.

Для вычисления же истинной температуры осталось всего ничего: считать двухбайтные калибровочные регистры AC5, AC6, MC и MD с кодами 0xb2, 0xb4, 0xbc и 0xbe , соответственно, после чего использовать нехитрый набор действий (ура, тут редактор формул!).

Последний результат делим на 10, т.к. изначально он в десятых долях градусов Цельсия. Если уважаемый читатель не согласен с характеристикой нехитрый набор действий, рекомендую обратить внимание на измерение давления, которое вычисляется уже в 15 приёмов и с использованием всех 11 калибровочных констант. Кстати, калибровочные константы можно прочитать один раз, а затем запускать измерения снова и снова записью кода в регистр 0xf4 . Мудрёно? Да ладно, датчик как датчик:)

Стоит поблагодарить пользователя 41j за материал.

Если любопытный читатель заглянул в спойлер выше и, узрев его, закрыл поскорее обратно, есть и более простые способы скоротать время в командной строке. После BMP180 я подключил по I²C каскадом сразу два ардуиновских 8-битных расширителя GPIO на базе PCF8574AT.
Обратите внимание, микросхема PCF8574A (в отличие от PCF8574) использует адреса с базой 0x38 (у PCF8574 база 0x20 ), потенциально конфликтуя с родными блоками питания Супер Мирон. К счастью, адрес программируется, мини-плата идёт с тремя перемычками на 8 адресов, от блоков питания можно уйти на более старшие адреса. Всего на пустую шину можно повесить до 8 устройств, получив до 64 контактов GPIO. Если этого мало, см. описание коммутатора I²C в следующем спойлере.
Что делать, если надо подключить связку сенсоров типа BMP180, у которых адрес 0x77 (т.е. 0xee ) зашит жёстко? Для этого и есть такая штуковина, как коммутатор (мультиплексор), его можно собрать самому на базе TCA9548A или купить в виде мини-платы там же, где и всё остальное. Коммутировать (переключать) можно до 8 устройств одновременно, но работать с одноадресными устройствами придётся по очереди. По условиям данной статьи мы не используем микроконтроллеры, поэтому управлять самим коммутатором придётся посредством того же расширителя GPIO, от которого нужно три вывода. Обратите внимание на рисунок: мини-плата коммутирует только сигнальные линии I²C SDA и SCL, питание устройств придётся организовать отдельно. Если нужно, например, опросить более 8 датчиков типа BMP180, берём несколько коммутаторов и c помощью адресных линий A0-A2 разносим их относительно общей базы 0x70 (т.е 0xe0 в терминологии ipmitool ). В положении A0=A1=A2=1 коммутатор будет отзываться по адресу 0x77 , конфликтуя, кстати, с самим датчиком BMP180. Выходит, что используя TCA9548A, на каждую шину I²C можно подключить до 56 таких датчиков температура-давление. С учётом ограничений на максимальную длину самой шины, для объёмных измерений температуры должно хватить. Длина эта, кстати, в основном зависит от рабочей частоты шины.

Ограничения

Все эксперименты я проводил с помощью команды ipmitool(1) v1.8.15, работающей через хостовый (ядерный) интерфейс FreeBSD 10. Если использовать эту команду в скриптах, придётся парсить её вывод, причём stderr, а не stdout. Я специально избегаю парсеры в этой статье. Буду признателен, если кто-либо из читателей поделится проверенными библиотеками для работы с IPMI через хостовый интерфейс на популярных скриптовых языках (perl, Python), хотя бы в режиме raw-команд.

Хотя ipmitool(1) и может работать по сети (623/tcp), при выключенном хосте на JPI2C дежурного питания нет, шина обесточена. Запитывать сенсоры отдельно и опрашивать их через сетевой интерфейс IPMI при выключенном хосте не пробовал. Но если нужны автономные сенсоры, подключенные к сети, лучше уж задействовать одноплатник, например, тот же Малиновый Прог (простите, так я обозвал Raspberry Pi в своей статье про защиту microSD-карточек от преждевременного износа путём перехода на файловую систему read-only).

Как уже говорилось, описанный здесь способ без внешнего микроконтроллера практически исключает реакцию на прерывания по внешним событиям, кроме сигнала «отказ блока питания». Теоретически, по сигналу Power Fail можно сгенерировать SNMP-событие, но я не пробовал. И тут снова хочется сказать: если нужны прерывания от сенсоров, то нужен микроконтроллер или, на худой конец, выделенный одноплатник. Кесарю — кесарево.

Конфликтология I²C

Если «родного» блока питания на I²C-шине нет, то и слава богу, меньше проблем. Но если же в системе таки появится «родной» блок питания с I²C-интерфейсом, в теории не возбраняется подключить другие устройства параллельно, сколхозив соответствующий переходник. Что в этом случае произойдёт? Если все устройства сидят на своих адресах, ничего страшного произойти не должно до тех пор, пока хост не вздумает жёстко поуправлять блоком питания. Если не знаете, что делаете, то ограничивайтесь считыванием. Судя по FAQ ID 9492, блоки питания (одинарные, двойные, тройные) располагаются на логических адресах 0x38, 0x39, 0x3a, . (это адреса IPMI, делённые пополам).

У меня появилась теория относительно IPMI и его роли в доступе к I²C: если все команды записи только выбирают регистр для последующего чтения, то каждое взаимодействие с устройством укладывается в одну команду Master Write-Read протокола IPMI. Из весьма увесистой спецификации IPMI 2.0 я рекомендую ознакомиться с параграфом 22.11, который эту команду описывает. В моём понимании, операция по шине I²C — это либо чтение, либо запись последовательности байт по одному адресу. Но спецификация IPMI командой Master Write-Read вводит нечто большее: удобная для сенсоров пара операций «запись-чтение» напоминает полноценную транзакцию, причём IPMI оговаривает максимальные длины буферов (порядка 30 байт). Я также исхожу из того, что (а) BMC всегда является главным устройством на шине I²C и (б) BMC имеет встроенный механизм блокировок, т.е. он не попытается отобрать шину у самого себя посередине транзакции.

Если исходить из того, что команда IPMI Master Write-Read (из двух операций) действительно является неделимой транзакцией, то BMC выполняет нечто большее, чем просто отображение I²C: он является транзакционной надстройкой над I²C, причём с хостовым или сетевым интерфейсом. Другими словами, получается что-то вроде примитивного 4-уровневого стека протоколов для работы с I²C-сенсорами через интерфейс IPMI, который я и рискнул нарисовать. Если уважаемому читателю не понравилась картина, представьте, что я художник, и вижу мир именно так, возражайте по существу, пожалуйста:)

Кстати, шина SMBus, помимо дополнительных контактов, отличается от I²C именно пакетным режимом, и в ней определена операция Write/Read Block. Но это уже часть протокола самой шины SMBus, IPMI в этом случае сыграл бы роль простой операционной обёртки, а не транзакционной надстройки. Впрочем, максимальные длины блоков в спецификациях IPMI и SMBus настолько схожи, что я предполагаю между ними прямую связь, даже не погружаясь глубоко в тему.

Безопасность

BMC-контроллер, подключенный к вычислительной сети, является сервером и потенциально уязвим. Именно поэтому, например, следует усиливать меры безопасности на «локальной» консоли ОС, которая через виртуальный KVM де-факто экспонируется в сеть. Старые прошивки BMC-контроллеров Супер Мирон содержат неприятную уязвимость, поэтому эксплуатацию стоит начинать и с обновления прошивки BMC (помимо BIOS).

Климат-контроль с обратной связью

Некоторые производители доводят висящую, так сказать, в воздухе идею охлаждения с обратной связью прямо-таки до культа, изрядно припудренного маркетингом c завесой тайны:

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

Предполагаю, что контроллер Corsair Link Commander Mini представляет собой устройство USB HID, использующее для связи с сенсорами шину SMBus, поверх которой для управления «фирменным» блоком питания используется PMBus, причём не самая новая. Любопытно было бы подключить блок питания напрямую к микроконтроллеру с поддержкой SMBus, найти адрес сканированием и прочитать однобайтный регистр 0x98 (PMBUS_REVISION). Если отзовётся разумным кодом, берём соотв. спецификацию PMBus с сайта и получаем увлекательный квест на тему управления блоками питания Кобзарь в собственной системе с обратной связью. Хотя вместо Кобзаря лично я предпочитаю блоки питания Чистяк, хоть они и не столь занимательны, зато (по моему опыту) с основной задачей справляются лучше.

Возможно, лучше было бы открыть «экосистему» и нанять группу людей для поддержки community-проектов через социальные сети, со свободным обменом скриптами. У меня ощущение, что выросло бы количество чеков, т.е. продаж блоков питания. Но маркетологам, конечно, виднее.

Тем временем, community не остаёт:

Пользователь Kevin Horton предложил для FreeNAS систему с обратной связью в виде скрипта на языке Perl. Эту идею затем развил другой пользователь. Всё базируется на встроенном функционале материнских плат Супер Мирон, имеющих двухзонный климат-контроль, предположительно, серии X10 или более новых. Обратная связь при желании собирается откуда угодно, включая термодатчики жёстких дисков через SMART. Обороты вентиляторов регулируются на уровне ШИМ, нехитрыми командами контроллеру. Без ёлочных гирлянд.

Но у меня на старой однопроцессорной плате Супер Мирон X9 (socket 1155) это не работает: на моделях X9SCL/X9SCM у меня не получалось нельзя переключать режим работы климата с «лёгкого» на «полный» иначе как через BIOS с полной перезагрузкой системы (ссылка). Увы, IPMI тут бессилен.

Альтернативы IPMI I²C — преобразователи интерфейсов

А что, если замечательных разъёмов с I²C на системной плате совсем нет? Есть неплохие варианты USB-преобразователей I²C/SMBus, экспонирующие устройства как USB HID.

Пользователь x893 указал мне на пару микросхем-адаптеров: CP2112 пр-ва Silicon Labs и MCP2221A пр-ва Microchip. Последняя имеет экспортные ограничения, снимаемые отказом от буквы «A» на конце и понижением скорости с 460кБит до 115кБит. Чтобы не возиться с пайкой и рассыпухой, можно заказать изделие CP2112EK примерно за $40, либо выбрать ADM00559 на базе MCP2221 в два раза дешевле. Уверен, есть и более простые/дешёвые варианты, но их качество и работоспособность под разными системами надо проверять.

Помню, несколько лет назад я, разбирая USB стек в статье на хабре, уже рисовал перспективы USB HID как удобного способа работы с сенсорами и датчиками. Досталось мне тогда от резидентов клуба: дескать, не надо использовать HID, это вообще для клавиатуры, правильно использовать CDC, т.е. виртуальный COM-порт. Но абстракция USB HID нативно дробит сложное устройство на простые составляющие. Она позволяет в ряде случаев даже обходится без драйверов, пользуясь готовыми библиотеками, например для Python. И пока я отстаивал идею USB HID, Microchip уже выкладывала драйверы под Linux, с разницей в пару месяцев. Я тогда этого не знал, но рынок сам всё расставил по местам:)