удивил OMAP: вообще в еррате нет упоминания I2C. Или это чудо или пациента просто еще недообследовали (ревизия документа-2011 год)
для LPC - упомянута только одна ошибка в реализации I2C, вроде бы обходится без особых танцев с бубном, так что тоже годится.
спасибо, буду знать.

И там будут свои метаглюки. Независимые ни от чего

Гиперкуб

Я этот куб даже обновить нормально не могу. Лучше новую версию скачать и переустановить.

метакуб круче, чем гипер, ибо абстрагирует все от всего

Может и недообследовали, но у меня на OMAP на I2C висит FRAM, в которую непрерывно пишутся логи работы, так что обмен довольно интенсивный и никаких проблем в его работе я не заметил.
Для LPC еррату не смотрел, так как на баги вроде не наступал (хотя может и наступил, но не понял что это баг). В любом случае на LPC1758 и LPC1788 у нас тоже наверное уже тысячи устройств у заказчиков работают в режиме 24часа и если-б там были проблемы, мне бы уже плешь насквозь проели . :-)

После игрищ с кубом все прошлые выходные я для себя сделал заключение, что несомненно полезная вещь в нем - "графический редактор GPIO", который сам подсказывает где могут быть какие сигналы и что блокируешь каждым конкретным выбором из доступной периферии. Сильно ускоряет процесс, и автоматом делает удобоваримую документацию по назначению сигналов на пины. Последний раз полностью "распихать" ноги у LPC1768 и сделать в экселе табличку с сигналами и режимами для инициализации у меня заняло почти сутки (но там реально загружалось почти все что возможно по максимуму, два пина из сотни остались не у дел). Опять же код инициализации GPIO упрощает жизнь.

I2C у STM32F103C8 я для себя списал в утиль по результатам. Условно считаем что его нет, потому как бубна в комплекте с чипом не дают, а свой приносить для камлания вокруг их I2C модуля - много чести. SPI работает вроде устойчиво с кубовским драйвером. Поделка ради которой я решил попробовать STM32 и куб уже задышала на LPC1758. Но я слегка "подточил" свои библиотечки для LPC чтобы приблизить форматы передачи параметров к кубовским и без больших правок использовать код который накропал за время игрищ с кубом, вреда от этого никакого а польза когда то может быть.

Как тут уже писалось, аппаратные I2C модули во многих популярных МК настолько убоги, что проще использовать свою софтовую реализацию этого простого протокола. Ну правда, чтение документации, изучние erratы, написание кода - займет больше времени, чем написание кода софтового I2C (у бывалых людей он уже давно написан и кочует из поекта в проект, плюс он не привязан к ножкам) :-)

Точно!!!!!

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.
400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками.
А ведь бывает нужно на несколько разных интерфейсов I2C повесить устройства. Вот тут и появляются чудо-проекты, когда МК с несколько сот МГц тактовой едва хватает для опроса пары датчиков.
Видно все Ваши задачи заключаются в моргании несколькими лампочками, тогда да - чем ещё загружать CPU?

именно для этого и нужен десяток ядер в каждом камне

Точно! Даёшь каждому I2C-девайсу по ядру!

Очень часто нужно изредка что-то там поделать с I2C. Подождать 20 мкс - не проблема.
А если интенсивный обмен, то прерывание на каждый байт - тоже не сахар.

Никогда не использовал прерывания для i2c. По-моему это бред полный, ибо интерфейс синхронизируемый самим контроллером, можно делать обычные delay().

ЗЫ. Это я про мастер режим, разумеется, слейв - тут только аппаратный блок, придется изучать все ераты и пр.. К счастью, пока нужды в нем не было

и автоматом решается вопрос с маппингом и ерратами
10 уартов или 10 езернетов - пожалуйста

Обычные delay() допустимы только для однозадачной среды, в многозадачной среде они убъют все задачи приоритетом ниже той, в которой работает такой драйвер.
В нормально реализованном драйвере, работающем с аппаратной периферией, как раз наоборот - обмен по интерфейсам (с использованием прерываний и DMA) освобождает процессор для менее приоритетных задач
(в которых кстати тоже может идти обмен по другому интерфейсу, времянки которого не будут сбиваться более приоритетными задачами).
Опять приходим к тому, что в более-менее сложном ПО будет скорей всего многозадачная среда, а однозадачная среда - что-то простое типа моргания лампочками.