ARM, RISC-V контроллеры

Классика жанра. Я для себя уяснил, в своё время, потрахавшись хорошенько с SAM7 в связке с ATMEGA (надо сказать сразу, в PIC18 и PIC24 гораздо менее глючный I2C), что в работе с I2C всегда возможны сбои. От ЭМИ прилетающего от рядом работающих двигателей например. Протокол должен предусматривать возможность обрыва передачи и повтора. Передаваемый пакет с середины может кончится на FFFFFF... потому, что мастер или слейв "заклинит". И заклинить может в нуле SCL -- поэтому всегда нужен таймаут передачи пакета (и у мастера, и у слейва тоже -- чтоб SCL отпустил, иначе всё без толку). И тут нужен сброс шины, как в даташитах пишут. Причём нужен не только для слейва, но и для самого мастера (как показал случай с PIC24, иначе он видит коллизию бесконечно) -- путём манипуляции SCL и SDA вручную, известным способом (старт, 9 клоков, стоп), а то и более заковыристым (ATMEGA в слейве стоп видела только на конце байта). А кроме сброса шины нужно контроллер сбросить изнутри через SFR (с SAM7 намучался...) Мой опыт показывает, у всех контроллеров с I2C какие-то трудности. И чем жирнее контроллер, тем заковыристее у него I2C. Так что не удивительно. На I2C всегда ругаются, когда дело идёт чуть дальше, чем I2C EEPROM, когда длинные провода, а не на одной плате, да с мощной нагрузкой (драйвер двигателя, например). И не факт, что библиотека вообще хорошо написана и тестировалась. Видя какой индусский код в примерах в это не верится (может на демо-плате с одной EEPROM она работает хорошо, а как до дела дойдёт -- увы). И в даташитах тонкости обычно не пишутся, или пишутся весьма вскользь. Общие правила указанные выше -- обычно ключ к решению. Таймауты. Сброс и через SFR. Завершение обмена ручным манипулированием SCL/SDA. Ещё обычно резисторы подтяжки от балды выбирают, не глядя в осциллограф, на что оно становится похоже. А напрашивается активная подтяжка или буфер (ибо у больших контроллеров токи GPIO обычно смешные).