Организация стабильной работы шины I2C Опции

[Arlleex]

Добрый вечер!
Имеется микроконтроллер, имеется некоторое периферийное устройство, подключенное к первому по шине I2C. Однажды, при отладке их взаимодействия, я столкнулся с особенностью, на первый взгляд интересной, но в то же время привносящей плачевные последствия. Дело в том, что, в отличие от синхронных интерфейсов, имеющих отдельную физическую линию разрешения (CS, EN, и т.д.), например, SPI, шина I2C таковой не является: только две линии - SDA и SCL. Усугубляется это обстоятельство еще и идеологией сигналов: в зависимости от состояний логических уровней на этих линиях различают старт-бит, повторный старт, стоп бит.
При включении питания микроконтроллер начинает инициализировать свою внутреннюю периферию, в том числе линии портов ввода/вывода, к которым подключена шина I2C. И заранее никто не защищен от переходных процессов на шине в этот момент - там может и всплеск быть короткий, и что угодно. Пагубное влияние таких всплесков налицо - они случайно могут служить условиями старта для I2C. Когда-то так получалось и у меня, пока я не посмотрел осциллограммы сигналов на интерфейсных линиях. Действительно, там был кратковременный всплеск, и I2C-ведомые думали, что микроконтроллер сформировал условие старта. А МК, ничего об этом не подозревая, шлет реальный старт-бит, вводя ведомое устройство в ступор (ну железно зашитый в нем конечный автомат, чего поделать). Далее все просто - ведомый не отправляет бит подтверждения, а в некоторых случаях может сам подтянуть линию SCL к низкому логическому уровню. А что в этот момент делает микроконтроллер? Он опрашивает различные флаги (произошло на линии условие старта или нет, передался ли адрес, принялся ли бит подтверждения и т.д.). И, к сожалению, если делать это так:

while(!(STATUS_I2C_REG & (1 << 5))); // ожидание установки флага

и в этот момент на шине ничего не произойдет для установки этого флага, микроконтроллер тут и повиснет.
Можно сделать на прерывании, но сути не изменится - аппаратная ошибка на шине, которую можно обнаружить в регистрах I2C-интерфейса микроконтроллера, и соответственно отреагировать, но ведомому-то до этого какое дело? Вот произошла ошибка в момент передачи данных, ведомый притянул линию SCL к земле - вот и ничего не поделаешь уже, МК не сможет даже условие стопа сформировать, чтобы потом снова попытаться обратиться к этому ведомому. Я думаю вы поняли к чему я веду: случайная наводка на интерфейсной шине может сформировать определенный сигнал на шине, причем микроконтроллер еще сможет это обнаружить, но ведомый - нет. Он все так же будет ждать следующим битом, например, стоп-бит, а микроконтроллер еще только отправляет последний бит данных... Тут возникает жестокий ступор, и как вывести ведомого из него - как раз мой вопрос.
Ведь по идее делать так:

while(!(STATUS_I2C_REG & (1 << 5))); // ожидание установки флага

нельзя нигде. Мало ли почему флаг не установится, программа зациклится и что-нибудь взорвется
Насколько я знаю, для таких целей предусматривают таймауты, по истечению которых обрабатывается произошедший казус. Но на I2C как обработать ошибку? У меня вариант только один - сделать управляемым питание ведомого устройства. Через полевой транзистор, например. Чуть что - перезапустили и дальше работаем.
Благодарю за внимание!

[Arlleex]

Про правильное включение I2C я знаю. Про то, что она для связи микросхем - тоже. Подключаю экранированным двужильным кабелем (марку не помню, к сожалению). Резисторы по 4,7к.
Я проводил эксперименты, где микроконтроллер несколько раз в секунду взаимодействовал с ведомым на низкой скорости. Результаты на самом деле хорошие - произошло 250 000 обращений и связь нарушилась. Я оставлял плату на день и уходил по своим делам, фиксируя все на дисплее.
Следовательно, результаты не плохие, но, нужно уметь избавляться от любых проблем на шине, ведь перезапустив устройства, можно спокойно совершить столько же обращений (ну как повезет - может меньше, а может больше).