[SpyBot 0]

Обычные delay() допустимы только для однозадачной среды

В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче.

 

[Quasar 18]

Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними.

400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками.

А ведь бывает нужно на несколько разных интерфейсов I2C повесить устройства. Вот тут и появляются чудо-проекты, когда МК с несколько сот МГц тактовой едва хватает для опроса пары датчиков.

Видно все Ваши задачи заключаются в моргании несколькими лампочками, тогда да - чем ещё загружать CPU?

 

I2C не сильно-то нагруженный интерфейс, чаще всего, пару байт переслать раз в минуту/час. Это не SPI/I2S/Ethernet/CAN, которые чаще всего загружены "по полной".

[jcxz 187]

В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче.

Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный.

[mantech 35]

Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный.

 

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

[jcxz 187]

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

А Вы откуда знаете?

Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ.

В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости.

Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц?

 

PS: Имхо - тактировать шедулер 10кГц можно конечно, но по-моему многовато - много накладных расходов на переключение задач. У меня обычно максимум 1кГц или меньше.

[Alechek 0]

У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется

Кхе.... Весьма жирновато.

Еще для FreeRTOS с ARM LPC2148 48Мгц прикниул, что сохранение-переключение-востановление контекста в прерывании занимает 2.2 мкс

А тут период планировщика 100 мкс, то есть в этом случае 2.2% времени процессора будет тратиться на переключение контекста.

 

 

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

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

 

[Quasar 18]

А Вы откуда знаете?

Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ.

В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости.

Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц?

 

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

[scifi 1]

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

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

[mantech 35]

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

 

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

ЗЫ. А так, если принципиально "упираться", можно и на 1wire дисплей повесить, но нужно-ли? :laughing:

[VCucumber 0]

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

хоть по десять

я ведь не против, если ядер будет 16

или 256

только учтите, что одно ядро тянет одну нить

а значит один цикл, и один таймер, но общий

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

Изменено 12 января, 2016 пользователем Огурцов

[mantech 35]

я ведь не против, если ядер будет 16

 

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

[VCucumber 0]

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

[mantech 35]

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

 

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

 

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

[VCucumber 0]

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

 

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

так что ядер может очень много за счет уполовинивания памяти

 

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

Изменено 12 января, 2016 пользователем Огурцов

[SapegoAL 0]

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

Ну, скажем, программный там и писать нечего. 5 строчек... )) И действительно лениво ... ))

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

 

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