Просветите новичка: софтовый i2c может оказаться быстрее аппаратного?
Разгон аппаратного выше 400кГц я просто не встречал(может и есть возможность, но библиотеку “поковырять” надо).
А программный “ногодрыг” - почему бы и нет?
Вот, нашёл, надеюсь Komandir не против будет.
https://arduino.ru/forum/proekty/imitatsiya-razlichnykh-shkal-na-displee-12864?page=1#comment-608780
А если аппаратный разогнать получится - ещё лучше
В наличии есть ещё и STM32103xxx на мелкой платке и адаптер СТМовский же для записи загрузчика. Стоит попробовать прописать в среде Ардуино IDE.
И всё же не очень понятно: в скетче кроме определения пина как Output имеется loop в котором идёт последовательный перебор нулей и единиц посылаемых на вышеупомянутый пин. В отличии от классического Blink в этом скетче нет задержек между переключениями состояния выхода. Так какого же чёрта частота на этом пине не поднимается выше 0,9 МГц? Чем таким важным занимается rp2040-zero с тактовой частотой « до 133 МГц »?
Увы, не знаком с этим контроллером
На всякий случай, повторюсь, речь не про обычную нано, а про китайский клон на
У них есть некоторые отличия
Спасибо всем кто приня участие в обсуждении проблемы.
С уважением Андрей Назаренко
P.S
Немного тупанул, извиняюсь. Код , о котором речь выше это для MASTER-a. Для слэйва надо будет переписывать.
Всё же проще будет разогнать железо
Извиняюсь за паузу, ходил в ночной за хлебом.
Попробую найти программную реализацию шины i2c для slave. И всё же загадка BLINK с практически пустым наполнением и столь низкой частотой смены уровней на выходе как то напрягает. Возникает законный вопрос: сколько тактов затрачивает контроллер на одну единственную пересылку бита на выход. Хотя конечно прежде чем сдвинуть бит на выход его надо ещё установить в ноль или единицу, но мне думается это не самая сложная задача при частоте контроллера «до 133МГц». Кто бы ещё подсказал как к этому относиться. Вот в PIC контроллерах всё понятно : в описании есть выбор источника тактовой частоты то есть заране известно что дискрет жестко определён. Плюс в описании команд для каждой указано количество тактом необходимых для исполнения каждой команды. После этого зная время берёшь ассемблер и пишешь исходный код. Программируешь и заранее знаешь результат. Ну веслищами возникли трудности с периферией периферийного же контроллера заменяешь условно кварц на кнопку без дребезга, вешаешь на выходы светодиоды и пошагово прогоняешь прогу, если конечно временные интервалы не сильно нужны. А в данном случае такое впечатление что китайцы каких-то важных регистров в кристал не положили.
Из даташита на ATmega328PB:
“Работа ведомого устройства не зависит от скорости передачи данных или настроек предварительного делителя, но тактовая частота ЦП в ведомом устройстве должна быть как минимум в 16 раз выше частоты SCL.”
То.есть максимально 2МГц. Просто взять плату с 328pb(32MHz) , и, посмотреть. Возможно без “танцев с бубном” потянет аппаратный I2C.
Вот-вот,
видимо, и на меня сказались праздники, и я опять жестоко протупил.
Думал про одно, но написал про другое.))
Не ATmega328PB, а LGT8F328P то есть , другой клон.
здесь
На сих всё, приношу свои извинения,
поспешишь людей насмешишь - пошёл я спать))
А вы реально регистрами ворочали или digitalWrite() мучали? Если второе, то посмотрите, какой ворох тянет за собой эта функция. Там ни разу не “просто пересылка бита” 
1 лайк
Да нет там никакой загадки.
Ногодрыг ( запись нулей и единиц в порт) на любом контроллере теоретически возможен вплоть до частоты в половину такта ядра. То есть на Нано это 8 МГц, а на Пико - 66 МГц.
На практике там будут ещё накладные расходы на организацию цикла и могут быть ограничения железа - но все равно для Стм32 и Пико это десятки МГц.
То, что вы не можете получить эти цифры - связано только с вашим неумением работать с контроллером.
Начните с того, что выложите свой тестовый код, чтобы было что обсуждать.
Внешняя шина физически может держвть максимальную частоту 33MHz. Это обусловлено физикой меди. При превышении данной частоты идут критические завалы фронтов импульсов, связанные с паразитными ёмкостями медных дорожек. Все эти частоты выше, это внутренние процессорные частоты. Человечество держит медь, как и держит пока асм 8086 на наших компах. Как и нет в природе кварца выше 20 MHz на первой гармонике,
Вот тут почитать можно про PIO на этих девайсах, если одолеешь будет тебе нужная скорость твоего I2C
Я с Рico не знаком, но сдается мне, что там организация ногодрыга похожа на ее реализацию в СТМ32. А именно, не зависимо от частоты камня, частота ногодрыга для каждого из пинов определяется отдельно его настройкой.
digitalWrite() - это функция. И прежде чем что-то записать в порт там куча вычислений идет. Вам об этом уже @v258 говорил выше (но Вы почему-то его не послушали).
В скетче Blink убраны задержки между переключениями состояний выхода, плюс в цикле ножка дёргается три раза и только потом «возврат каретки» . На осциллограмме видно 0,5 мкс/клетка : один из нулей (третий слева) длиннее остальных. Похоже время тратится на возврат к началу цикла.
Так там ТС в принципе хрень какую то замеряет.
Во первых программирование идёт в сторонней IDE, а не в родном SDK, во вторых используется встроенная функция, которая преобразуется в итоге хз во что.
Для сравнения:
digitalWrite() ардуиновский переключает пин примерно за 16мкс, а прямая запись в порт за один такт (0,0625 мкс).
Сколько времени занимает тот же функционал для RP при использовании фреймворка Ардуино сложно сказать.
К тому же никак не настраивается скорость работы пина.
1 лайк
Это бред, а не измерения.
Вам уже три человека говорят - функция digitalWrite() не пишет в порт сразу, там уйма вычислений происходит. А Вы уперлись и не слышите этого.