SpyBot 0 11 января, 2016 Опубликовано 11 января, 2016 · Жалоба Обычные delay() допустимы только для однозадачной среды В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Quasar 20 11 января, 2016 Опубликовано 11 января, 2016 · Жалоба Это программная эмуляция имеющейся в МК периферии - убогая идея. Ногодрыг - это тяжёлое наследие АВР и иже с ними. 400кГц (обычная частота для I2C) даст 800кГц прерываний! Это угробит производительность даже самого жирного МК на бессмысленное дёрганье ножками. А ведь бывает нужно на несколько разных интерфейсов I2C повесить устройства. Вот тут и появляются чудо-проекты, когда МК с несколько сот МГц тактовой едва хватает для опроса пары датчиков. Видно все Ваши задачи заключаются в моргании несколькими лампочками, тогда да - чем ещё загружать CPU? I2C не сильно-то нагруженный интерфейс, чаще всего, пару байт переслать раз в минуту/час. Это не SPI/I2S/Ethernet/CAN, которые чаще всего загружены "по полной". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 11 января, 2016 Опубликовано 11 января, 2016 · Жалоба В многозадачной среде есть необычные delay(), которые в момент отдыха данной задачи отдают управление менее приоритетной задаче. Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 11 января, 2016 Опубликовано 11 января, 2016 · Жалоба Такие delay задают задержку в количестве тактов таймера планировщика задач, который имеет частоты обычно не более единиц кГц. I2C на такой задержке будет ну очень медленный. У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 241 11 января, 2016 Опубликовано 11 января, 2016 · Жалоба У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется А Вы откуда знаете? Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ. В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости. Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц? PS: Имхо - тактировать шедулер 10кГц можно конечно, но по-моему многовато - много накладных расходов на переключение задач. У меня обычно максимум 1кГц или меньше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 12 января, 2016 Опубликовано 12 января, 2016 · Жалоба У меня задачи переключаются с частотой 10000 раз в сек - это вполне нормальная скорость. I2C не для передачи изображений же используется Кхе.... Весьма жирновато. Еще для FreeRTOS с ARM LPC2148 48Мгц прикниул, что сохранение-переключение-востановление контекста в прерывании занимает 2.2 мкс А тут период планировщика 100 мкс, то есть в этом случае 2.2% времени процессора будет тратиться на переключение контекста. 10 уартов или 10 езернетов - пожалуйста Тогда по паре таймеров на ядро еще бы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Quasar 20 12 января, 2016 Опубликовано 12 января, 2016 · Жалоба А Вы откуда знаете? Мы в некоторых изделиях используем матричные ЖКИ висящие на I2C. А также FRAM-память на I2C размером в 32кБ. В других изделиях есть ADE78xx работающая по I2C непрерывным потоком на макс. скорости. Если Вы думаете, что I2C используется только для передачи пары байт и никаких других применений нет, то зачем в новых МК ввели I2C с SCL до 1МГц? Ну это ВЫ так используете, но в массе своей, практика показывает, что высоконагруженное I2C это экзотика, так же как и I2C в слейве со стороны МК. Никто же не спорит, что это не нужно или нереально, просто речь идет о том, что I2C в 99% случаев, для эмбеддера это мастер с небольшим объемом данных, и все эти мегагерцы на SCL и аппаратный I2C - просто не нужны. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 12 января, 2016 Опубликовано 12 января, 2016 · Жалоба Опять приходим к тому, что в более-менее сложном ПО будет скорей всего многозадачная среда, а однозадачная среда - что-то простое типа моргания лампочками. Вы не представляете, как много всякого разного и вполне многозадачного можно сделать в рамках схемы Super Loop. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 12 января, 2016 Опубликовано 12 января, 2016 · Жалоба Ну это ВЫ так используете, но в массе своей, практика показывает, что высоконагруженное I2C это экзотика, так же как и I2C в слейве со стороны МК. Никто же не спорит, что это не нужно или нереально, просто речь идет о том, что I2C в 99% случаев, для эмбеддера это мастер с небольшим объемом данных, и все эти мегагерцы на SCL и аппаратный I2C - просто не нужны. Все верно, даже добавить нечего, ибо эта шина создавалась именно для конфигурирования и управления блоками телерадиоаппаратуры фирмы филипс. А использовать жк экраны или другие высокоскоростные стриминговые устройства считаю нерациональным, ибо почти все они есть на более скоростном SPI, с которым работать куда приятнее. ЗЫ. А так, если принципиально "упираться", можно и на 1wire дисплей повесить, но нужно-ли? :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 12 января, 2016 Опубликовано 12 января, 2016 (изменено) · Жалоба Тогда по паре таймеров на ядро еще бы. хоть по десять я ведь не против, если ядер будет 16 или 256 только учтите, что одно ядро тянет одну нить а значит один цикл, и один таймер, но общий а если в цикле инкрементировать две переменных, тогда разрешение будет поменьше Изменено 12 января, 2016 пользователем Огурцов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 12 января, 2016 Опубликовано 12 января, 2016 · Жалоба я ведь не против, если ядер будет 16 Да уже и есть наверно, только программирование линукс-онли, поэтому - обламингос :crying: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 12 января, 2016 Опубликовано 12 января, 2016 · Жалоба какой линукс, речь про что-то типа 2313, только лишь штук 256 в одном соике и на гигагерц тактовой Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 50 12 января, 2016 Опубликовано 12 января, 2016 · Жалоба какой линукс, речь про что-то типа 2313, только лишь штук 256 в одном соике и на гигагерц тактовой Ооо да!! Даже не представляю, как бы все это называлось Хотя да, берете плисину на стопятьсот лог. вентилей и втюхиваете туда свои кучи ядер... Тут главное критическую массу не набрать, а то мало-ли что... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 12 января, 2016 Опубликовано 12 января, 2016 (изменено) · Жалоба за доллар ? давайте вообще, зря смеетесь, алу на кристалле занимает очень мало места в сравнении с флешем или рамой так что ядер может очень много за счет уполовинивания памяти кстати интересная фича про перывания - как в с# - несколько ядер могут подписаться на одно прерывание Изменено 12 января, 2016 пользователем Огурцов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 13 января, 2016 Опубликовано 13 января, 2016 · Жалоба Как тут уже писалось, аппаратные I2C модули во многих популярных МК настолько убоги, что проще использовать свою софтовую реализацию этого простого протокола. Ну правда, чтение документации, изучние erratы, написание кода - займет больше времени, чем написание кода софтового I2C (у бывалых людей он уже давно написан и кочует из поекта в проект, плюс он не привязан к ножкам) :-) Ну, скажем, программный там и писать нечего. 5 строчек... )) И действительно лениво ... )) Честно сказать в последнем проекте (stm32f407) так и есть. У меня там клава по I2C подключена. Она реализована на stm8 (slave). Казалось бы написать мастера - 2 пальца об асфальт. Ну у меня там специфика - хотел без прерываний сделать... На начальном этапе включил софтовый драйвер. Когда уже проект закончил - решил подключить аппаратный. Написал первоначальный вариант - виснет иногда. Перечитал всё - написал все возможные обработчики ошибок - виснет гораздо реже. Настолько редко, что выловить причину не смог. Плюнул - оставил софтовый. А в LPC1764/65 действительно прекрасно работает. Да и на старом LPC2106 тоже не припомню проблем. На stm32f103 slave удалось нормально сделать. Через прерывания. Оно и на 407 наверное можно... просто жалко времени... )) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться