Кхе.... Весьма жирновато.
Еще для FreeRTOS с ARM LPC2148 48Мгц прикниул, что сохранение-переключение-востановление контекста в прерывании занимает 2.2 мкс
А тут период планировщика 100 мкс, то есть в этом случае 2.2% времени процессора будет тратиться на переключение контекста.



Тогда по паре таймеров на ядро еще бы.

Ну это ВЫ так используете, но в массе своей, практика показывает, что высоконагруженное I2C это экзотика, так же как и I2C в слейве со стороны МК. Никто же не спорит, что это не нужно или нереально, просто речь идет о том, что I2C в 99% случаев, для эмбеддера это мастер с небольшим объемом данных, и все эти мегагерцы на SCL и аппаратный I2C - просто не нужны.

Вы не представляете, как много всякого разного и вполне многозадачного можно сделать в рамках схемы Super Loop.

Все верно, даже добавить нечего, ибо эта шина создавалась именно для конфигурирования и управления блоками телерадиоаппаратуры фирмы филипс. А использовать жк экраны или другие высокоскоростные стриминговые устройства считаю нерациональным, ибо почти все они есть на более скоростном SPI, с которым работать куда приятнее.
ЗЫ. А так, если принципиально "упираться", можно и на 1wire дисплей повесить, но нужно-ли?

хоть по десять
я ведь не против, если ядер будет 16
или 256
только учтите, что одно ядро тянет одну нить
а значит один цикл, и один таймер, но общий
а если в цикле инкрементировать две переменных, тогда разрешение будет поменьше

Да уже и есть наверно, только программирование линукс-онли, поэтому - обламингос

какой линукс, речь про что-то типа 2313, только лишь штук 256 в одном соике и на гигагерц тактовой

Ооо да!! Даже не представляю, как бы все это называлось

Хотя да, берете плисину на стопятьсот лог. вентилей и втюхиваете туда свои кучи ядер... Тут главное критическую массу не набрать, а то мало-ли что...

за доллар ? давайте

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

кстати интересная фича про перывания - как в с# - несколько ядер могут подписаться на одно прерывание

Ну, скажем, программный там и писать нечего. 5 строчек... )) И действительно лениво ... ))
Честно сказать в последнем проекте (stm32f407) так и есть. У меня там клава по I2C подключена. Она реализована на stm8 (slave). Казалось бы написать мастера - 2 пальца об асфальт. Ну у меня там специфика - хотел без прерываний сделать... На начальном этапе включил софтовый драйвер. Когда уже проект закончил - решил подключить аппаратный. Написал первоначальный вариант - виснет иногда. Перечитал всё - написал все возможные обработчики ошибок - виснет гораздо реже. Настолько редко, что выловить причину не смог. Плюнул - оставил софтовый.

А в LPC1764/65 действительно прекрасно работает. Да и на старом LPC2106 тоже не припомню проблем. На stm32f103 slave удалось нормально сделать. Через прерывания. Оно и на 407 наверное можно... просто жалко времени... ))

Дак ясно дело жалко, причем клаву можно на низкой скорости запустить, куда там спешить-то?

Вобще-то "использует" её производитель, применив именно такую, а не иную шину в своей микросхеме. Не знаю для кого она создавалась, но факт - это наличие микросхем именно с этой шиной.
И если в устройстве нужна например FRAM и внешние часы RTC, то выгоднее поставить одну микросхему содержащую в себе FRAM+RTC, чем ставить две отдельные на разные шины.
Тогда и получается, что нужны массированные транзакции обмена с памятью по I2C.
Да и EEPROM-ов разных на I2C тоже тьма - тоже их зачем-то именно на I2C делают.

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

Да конечно делают, только объемы памяти, как правило не соизмеримы с SPIшными или нандами... И сам делал голосовой информатор на 128кБ i2c епроме, и ничего, звук, 12кГц, не прерывался и не глючил - чисто программный интерфейс, да еще и на АВРке... Во время проигрывания еще обслуживался модем, клавиатура, датчики и еще по мелочи. Все зависит от рук и головы программиста

Да ладно... SPI NOR flash - наше всё. Хотите 16 мегабайт? Их есть у нас. И стоит всего полтора дублона в розницу.

Я знаю, вроде и больше видал, я писал про I2C, что у них объемы небольшие по сравнению с SPI и т.д.

У меня в предыдущем изделии (пока выпускается) стоит FRAM + EEPROM на I2C. Процессор LPC1765. Написал и забыл. Даже начальную инициализацию сделал так, что автоматически определяется размер установленных микрух и автоматически настраивается всё. И больше вопросов не возникало. Выпускается лет 5 уже.
На stm единственно обнаружил нюанс, что некоторые таймауты обрабатываются аппаратно. Например при ожидании ASK, по-моему. Уже не помню. Короче напрямую в ОС нельзя. Некоторые операции в транзакции надо завершать. Поэтому лучше на прерываниях писать и следить за временем их исполнения.
Но в целом мне не понравилось. Ни в AVR, ни в STM. В MSP не работал с этой шиной.

На LPC17xx и на LPC23xx я сделал уже множество изделий с микрухами висящими на I2C (МК везде мастер). Это и FRAM и RTC-часы и ЖКИ и датчики и ADE78xx.
Эти изделия выпускаются серийно и давно уже множество их работает у заказчиков. Проблем нет. В том числе и испытания на ЭМС нормально проходят.
И в других проектах на Tiva, OMAP, MSP430, DSP C5502 - много где использовал I2C - везде только аппаратный, нигде не страдал фигнёй типа программной эмуляции существующего в МК I2C.
И проблем тоже не было с ним. И сложного там ничего нет.
На STM32 правда с I2C я не работал.