caxapa.ru :: При тестировании обнаружил новый вид зависания. Если во время работы коротить линии SDA и SCL между собой - оно виснет но не так как описано в еррате. Выяснилось что в SR1 выставляется флаг STOPF. Поскольку этот флаг относится к slave mode а у меня чисто мастер он никак не обрабатывался в обработчике прерывания и получалось бесконечное прерывание. Вот размышляю допилить обработку этого флага или ну его нафиг и надежнее сразу переделать на программный i2c ?

3m (15.05.2025 10:02, просмотров: 32) ответил POV на Я два месяца как-то убил на ихний i2c. Завелось в итоег как надо.. если не считать периодического зависания фильтров. Плюнул, с тех пор мастер только софверный...

При тестировании обнаружил новый вид зависания. Если во время работы коротить линии SDA и SCL между собой - оно виснет но не так как описано в еррате. Выяснилось что в SR1 выставляется флаг STOPF. Поскольку этот флаг относится к slave mode а у меня чисто мастер он никак не обрабатывался в обработчике прерывания и получалось бесконечное прерывание. Вот размышляю допилить обработку этого флага или ну его нафиг и надежнее сразу переделать на программный i2c ?

Ответить

- Если обмен не особо напряжный, то сделать sw i2c - дальновидное решение, которое можно будет достаточно просто портировать на другие камни. Я когда-то сделал для себя вывод, что аппаратный i2c без багов никто не осилил и проще даже не рассчитывать. - LightElf(15.05.2025 16:04)
  - мне показалось, что в EFM32 master сделан годно. slave не был нужен. но в общем - не спорю - Vit(15.05.2025 20:37)
  - Странный вывод. Вот, скажем, на телескопе с 2018 года трудятся шесть контроллеров, каждый обслуживает 16 датчиков, сидящих на I2C. Ни разу не было проблем по причине I2c. Eddy_Em(262 знак., 15.05.2025 17:31)
    - "И ты прав.." - LightElf(15.05.2025 17:51)

Средства и методы разработки