Куча девайсов на I2C. Иногда у какого-либо девайса происходит затык и он притягивает к земле или дату или клок. В итоге раком встаёт ВСЁ!
Как схемотехнически избежать подобных ситуаций?

Предусмотреть сброс всех/только глючных устройств шины по питанию.

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

А как узнать кто из них глючный?

Статистически, во время разработки. У меня, например, так делал барометр BMP280, а акселерометр MPU-6050 не глючил ни разу. Но, по факту, лучше перезагружать по питанию всё, что есть на шине.

Ещё стоит попробовать снизить номинал подтягивающих резисторов. Часто устройства на шине заглючивают не просто так.

Там железяка с кучей слотов, в который на ходу вставляют и выдёргивают блоки. У каждой свой прогер(даже из других регионов). И каждому нужно доказывать, что это его металлолом гонит. А так, адреса протестил, его глючный - в ауте. Вот и пусть сам колупается пока не очухается.
Я тут думал через транзистор коммутировать, на базу которого через кондёр сигнал заводить. Типа, импульсы проходят, а постоянка хрен. Типа вотчдог на конденсаторе...

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

Если на шине только слейвы, то почти всегда помогает поставить SDA в high и подать 9 SCL импульсов. Если устройство не ломаное совсем, то перестает держать шину.

А как Вы подаете на SCL импульсы если он, как раз таки, удерживается в нуле?

Если виснет так, то только ресет или питание.

И каким образом это поможет?
Например устройство - EEPROM, которая на операции записи пропустила (из-за помех) один клок. Соответственно - держит ACK. Ну подадите Вы ещё 9 клоков - она будет ACK для след. байта держать. Как это поможет?
Или любое устройство, принимающее блок байт, подтверждающее каждый байт ACK-ом. И если после такого ACK-а получает СТОП-условие - завершающее транзакцию, а если не получает - запускает счётчик на ещё 9 клоков.
Тогда уж, чтобы точно освободить шину, надо 9 раз сформировать СТОП-условие на шине. Или даже ещё больше раз.

Ставить на каждый слот отдельный контроллер I2C. По другому никак.

Че-то не понял, если устройство - слейв, как оно вообще что-то на клок выставляет?? В топку такие "умные" девайсы

А почему нет? Это называется Clock Stretching - когда микросхема EEPROM не успевает записать данные, она придерживает SCL внизу, и мастер понимает, что устройство занято и не надо его грузить новыми данными.

А если вешается система то при чем тут слейв!? Значит алгоритм мастера не правильно продуман.

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

Это тогда надо тащить ресет на все слейвы. Кстати говоря. I2C изначально задумывался как внутри модульный, а не меж блочный интерфейс, да еще и с hotswap.

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

есть I2C свичи. И там даже если какой то канал выгорел, можно перестать к нему обращаться. Смотрите у техаса например

Можно попробовать вот такую схему (в прикрепленном файле), копеечные 595 регистры и транзисторы BSS138 навряд ли сильно увеличат себестоимость устройства, правда понадобиться дополнительный интерфейс SPI для управления 595-ми, при необходимости схему можно переделать под другое управление. Соответственно при 5 вольтах на затворе шина I2C открыта для двухсторонней передачи информации между ведущим и ведомым, при 0 вольт на затворе - ведомый может получать от ведущего посылки, но передавать что-либо ведущему не может, то есть при проблемах, когда ведомый все время притягивает шину к земле - просто устанавливаем 0 на соответствующих затворах и отключаем глючное ведомое, при этом все остальные ведомые продолжают взаимодействовать с ведущим.
А вообще нужно разбираться почему ведомое зависает, может есть смысл подключить дополнительно конденсатор 0.1-1 микрофарад по питанию рядом с каждым ведомым, чтобы предотвратить зависание от помех по питанию.

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