Три ловушки в I2C, которых все хотели бы избежать

Самое приятное в I2C то, что это шина, которая доступна практически где угодно и охватывает обширную экосистему устройств, предлагающих ее в качестве аппаратно-определяемого интерфейса, но при этом достаточно несложную, чтобы ее также можно было реализовать чисто программно на простом GPIO. булавки. Несмотря на такую ​​популярность, I2C является одним из тех известных неформальных стандартов, которые имеют несколько популярных реализаций, оставляя при этом многие детали, такие как точное время, емкость шины и другие утомительные детали, беднякам, занимающимся разработкой продукта. Таким образом, в конечном итоге мы получаем такие статьи, как недавняя статья в блоге о выкручивании языка [пара парных груш], освещающие проблемы, обнаруженные при реализации подчиненного устройства I2C.

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

Ситуация становится еще более захватывающей, как правило, в форме того, что логические анализаторы любят травматично называть «ложным условием запуска/остановки». Это относится к поведению SDA и SCL: SDA становится низким перед тем, как SCL указывает на ошибку. Это может произойти из-за слишком малого времени удержания, в результате чего другие устройства на шине пропускают переход. Здесь SMBus определяет время перехода 300 нс, тогда как вызов I2C составляет 0 секунд, но теперь предлагается отложить вызов условия запуска/остановки до тех пор, пока не пройдет задержка в 300 нс. По сути, может показаться, что введение времени удержания — это путь вперед, пока не появятся доказательства обратного.

Третья ловушка относится к более высокоскоростным режимам I2C, включая Fast-Mode (FM) и Fast-Mode Plus (FM+). Обратная совместимость с этими более высокоскоростными версиями отсутствует. Хотя FM+ (представленный NXP в 2007 году) должен быть обратно совместим с более медленными скоростями, фактически различия в требованиях к синхронизации между стандартами FM+ и FM слишком велики, чтобы их можно было компенсировать. По крайней мере, в текущих версиях стандартов, но одна из радостей I2C заключается в том, что всегда есть еще один новый набор изменений, которых стоит ожидать.