А зачем их замыкать? Вы своё ПО пишете с таким расчётом, что кто-то вскроет корпус и замкнёт дорожки?


Что значит "бесконечно"? Вы же сами пишете: "выставится в регистре бит статуса". Вот тогда ожидание и закончится.
И судя по битам статуса (насколько помню), там не может быть такой ситуации чтобы никакой бит не выставился (манипуляции с пинцетом конечно исключаем), а следовательно - бесконечного ожидания не может быть.


"при какой-либо помехе" в регистре статуса появится "какой-либо бит" и сгенерится прерывание.

Ага. В случае неприятности у изделия нет права продолжать работать как ни в чем не бывало - нужно нештатную ситуацию разрулить.

Не знаю как у кого, а у меня на I2C максимум дисплей висит. Поскольку скорости большие не нужны, а интерфейс синхроннее некуда -
делаешь тупой ногодрыг в районе mainloop'а и не паришься за прерывания, while(condition), таймауты и т.п.
После любых случайных пинцетов изделие рано или поздно прокашляется без лишних арбитров, журналов, алгоритмов сброса.

PS. Не пора ли часть сообщений вынести в отдельную ветку по I2C, ибо к данной теме I2C мало относится?

Как же изделию разрулить такую ситуацию, когда некто влазит в него и начинает тыкать разными металлическими штуками куда ни попадя?


Да ладно Вам - тут каждая первая вторая тема такая: пара постов по теме, а потом - кто в лес кто по дрова....

В плане I2C я предлагаю ногодрыг - простейшее решение, которое не завесит шину в принципе.
Я бы не встревал, если бы лет 10 назад не столкнулся однократно с ситуацией ACK от слейва и START от мастера.
Долго ломал голову и убеждал себя, что это в нормальной жизни не повториться, но редчайшее событие, напрочь завешивающее обмен не давало покоя.
Кста, тогда это была микросхема памяти серии 24xx. С тех пор у меня настороженное отношение к I2C.

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

USB cdc.
До меня не доходит из-за чего вылазит ошибка Error setting parameters from DCB при подключение к COM port tolkit ?

Видимо это нанесло психологическую травму, которая не заживает уже 10 лет
Шутка.
Вас очень трудно понять, так как Вы не придерживаетесь стандартной терминологии I2C. О чём тут уже говорили.
Как именно может "завесить обмен" обычный СТАРТ или ACK - я думаю тут не только я, но никто не понял....

Если slave в ACK, а master хочет сгенерировать START, то как он это может сделать?
Как система оказалась в этом состоянии - совершенно другой вопрос (кто-то проворный тыкал пинцетом).

ACK или не-ACK - это состояние на шине i2c. Именно состояние шины, а не состояние линии SDA.
А состояния i2c определяются не только по состоянию линий SDA/SCL, а и по фазе работы мастера.
Т.е. - если мастер выдаёт СТАРТ, то на шине в принципе не может быть АСК, просто по определению.
Если при выполнении мастером СТАРТ на SDA держится "0", удерживаемый слэйвом, то это не АСК, это коллизия на шине, которая трактуется как одновременный доступ двух i2c-мастеров к шине. Для отслеживания этого есть соответствующий бит в регистре статуса i2c. И никакие ногодрыги или таймауты для обнаружения этой ситуации в F429 не нужны - всё нормально работает и обнаруживается. Надо внимательно читать доки.
А если уже ваше ПО трактует "0" на шине во время СТАРТ как АСК, то тут проблема только в Вашем ПО.

И что мастер может сделать в случае такой "коллизии"?

Если она вызвана помехой или внезапным перезапуском МК мастера (машина состояния I2C слэйва осталась в режиме вывода бита АСК или бита данных), то я ещё в сообщении https://electronix.ru/forum/index.php?showt...t&p=1555322 писал что я делаю. С поправкой: я выполняю 15 раз условие СТОП. СТАРТ не надо.
Такая операция на I2C при старте ПО у меня делается всегда, а не только при SDA=='0', ведь в слэйве машина состояний может из-за помехи оказаться в ошибочном состоянии вывода например очередного бита данных =='1' и вроде на SDA всё ок, но когда пойдут SCLK будет капец.
А если коллизия из-за наличия другого мастера на I2C, то тут поможет только паяльник.

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

Ребята я очень рад что вы так активно обсуждаете I2C.
Но я прошу помочь с USB. У меня с ним проблема.

В кубе сделан проект USB CDC.

При запуске мк. и открытие порта программой COM port tolkit.

Вылетает ошибка Error setting parameters from DCB.

В CDC передается пакет с настройками при открытии порта (bRequest == SET_LINE_CODING).
Он к вам приходит?

Или так.

Я такую ошибку видел только когда случайно установил скорость работы СОМ порта, которую не поддерживал сам СОМ порт. Нужно найти compt.ini в директории установки Тулкита и в ручную подправить скорость на правильную.


А я прекрасно понимаю потому что на разных МК модули I2C настолько разные, и частенько, настолько кривые, что применять их просто не хочется. На старых ПИКах мастера I2C вообще не было, все в ручную. На АВР-ке я даже один раз сварганил мастера и слейва на прерываниях встроенного модуля, но ПО для этого выглядело настолько чудовищно нечитабельно, что никакого удовлетворения не доставило. На МСП430 были потуги применить аппаратный I2C на прерываниях, даже пару дней убил на это, пока не обнаружил, что они прое*** забыли сделать прерывание на одно состояние. Типа почти все на прерываниях, а вот тут нужно "поллингом" Плюнул, вернул ногодрыг, который по коду коротенький, компактный и понятный. Благо что I2C синхронная, её везде можно приостановить что на 10 мс, что на 1 сек.
На STM32 пока до I2C не добрался, но тоже предстоит...

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

А по поводу пинцета - даже без него бывают глюки - например еще не подано питание на slave или обращение к нему произошло до того, как завершился его startup. Нормальный I2C должен дать ошибку и возможность привести автомат в нормальное состояние, а не впадать в клиническую смерть.