После вышеописанных процедур мне удалось получить скорость кадров в 60 FPS. Я не уверен, способен ли дисплей отрисовать данные с такой скоростью, но таймер рапортовал именно так.
Удивительно, что такой старый дисплей может работать на такой скорости. Обычный предел таких экранчиков около 20 - 27 МГц. Если изображение остаётся "нормальным", значит работает. В противном случае, на дисплее могут возникать разные артефакты, однажды у меня просто один бит в зелёном цвете пропадал, а я голову ломал где ошибся в программе...
Автору респект и уважуха -- не мало мастерства и знаний надо даже при наличии инструментов. Но вот на практике мало верится что кто-то сможет рассмотреть что там на серёжках изображено. Не зря же для большего внимания их делают порой весьма большими :)
Это верно, к сожалению. Но по описанию проблемы, именно тут бы он хорошо бы подошёл, я только это хотел сказать. Сам на Perl писал больше 20 лет, но под новые проекты его не беру -- некому будет продолжать если что...
Это пока что не очевидно. Ну, вот мой пример: контроллер дисплеев. Я бы взял ESP32 в качестве контроллера дисплеев, по два на контроллер, каждый на своём SPI, а информацию что на дисплее показывать передавал бы через I2C. На мой взгляд, это было бы разумно: более медленный протокол передаёт более высокоуровневые команды, которые потом "простым" микроконтроллером транслируются в быстрые передачи по шине SPI, суммарно таким интеллектуальным образом увеличивая пропускную способность и разгружая центральный "мозг". А вот что у Вас за проект, мне пока не понятно. Если для связи с микроконтроллером используется SPI, то микроконтроллер должен много данных принимать быстро и что-то с ними делать ещё быстрее. И вот эта вот цель мне пока не понятна.
Идея интересная. Возникает вопрос: что это такое должно быть? Почему SPI? От себя: я знаю для чего я применил бы 3-4 управляемых ESP32, но для связи я бы взял I2C.
Хожу до сих пор с Samsung Galaxy Watch, 46 mm. Купил их когда они вышли, в 2018. 5 лет часам. При нормальном использовании заряда аккума хватает на 3-4 дня, никаких особых ухищрений для экономии аккумулятора, всё включено. На замену думаю взять только что-то типа "про" версии, остальный по акуумуляторам ну очень смешные. Но пока не созрел, работают и эти...
Жене вот в итоге не могу ничего подобрать -- "про" версия ей большая...
Я же давал ссылку на гитхаб с часиками, там это всё реализовано. Если коротко, то рисовать "в ОЗУ" намного быстрее, чем на физическом экране. Вплоть до того, что алгоритмы примитивов должны быть разными. Я сделал грубый замер бенчмарков для наклонной линии:
Если рисовать наклонную линию отрезками горизонтальных/вертикальных линий на физическом дисплее, то в среднем это в два раза быстрее, чем по точкам;
Если рисовать наклонную линию горизонтальными/вертикальными отрезками в ОЗУ, то в среднем это в два раза медленнее, чем точками. Этот эксперимент, правда, был очень грубым и на другой архитектуре.
Рисование в ОЗУ быстрее во много раз. Если сделать несколько виртуальных экранов (буферов в ОЗУ) то можно разные комбинации с ними делать. Шрифты, рисующиеся отдельными точками, уже не так уж медленно работают. Вот второй пример (ссылка на гитхаб в описании): https://www.youtube.com/watch?v=9nOHqma-i0U
Дисплей -- основной потребитель в консоли. Микроконтроллер кушает мало. Вайфай и блютус могут тоже кушать, ещё какое-то оборудование, но тут речь больше про дисплей.
А смысл? Я себе сейчас взял для "микро" RP2040 Zero, вот уж реально "микро" и при этом нормально так всё по мощности. А вот эти вот ардуиновские "2 KB RAM" при работе с какой-либо графикой вообще не прикольны.
Там всё не так прямо плохо. Проблема вообще в принципе оптимизации пересылок. Допустим, надо отрисовать точку, для этого типичному SPI дисплею требуется 5 операций:
послать команду установки горизонтальной области х,х;
послать координаты х,х;
послать команду установки вертикальной области у,у;
послать координаты у,у;
послать данные цвета точки.
Если же надо нарисовать прямоугольник, то там совершенно те же 5 операций, только коородинаты несколько большую облать задают и за одну 5ю операцию заливается всё. Именно разбивка на операции тормозит всё рисование. Нарисовать одну точку или 200 по времени отличается не так сильно. Поэтому, стремятся применять оптимизации рисования примитивов, например, рисовать наклонную линию из отрезков горизонтальных/вертикальных линий, а не по точкам. Экономить пересылку координат, если одна совпадает, то не пересылать её повторно. Ну и так далее.
Адафрукт изза изначальной ориентированности на слабые МК не делает максимума оптимизаций что возможны под конкретную архитектуру, они больше ориентируются на универсальность применения. Как и весь Ардуино-фреймворк, надо сказать.
На счёт текста -- многие библиотеки делают отрисовку символов попиксельно, обеспечивая таким образом "прозрачность" для незаполненных участков.
Я для себя решил, что рисовать надо в виртуальных экранах, а затем просто пересылать на экран результат. Это получается часто эффективнее и быстрее, чем рисовать попиксельно на настоящем экране.
Удивительно, что такой старый дисплей может работать на такой скорости. Обычный предел таких экранчиков около 20 - 27 МГц. Если изображение остаётся "нормальным", значит работает. В противном случае, на дисплее могут возникать разные артефакты, однажды у меня просто один бит в зелёном цвете пропадал, а я голову ломал где ошибся в программе...
Автору респект и уважуха -- не мало мастерства и знаний надо даже при наличии инструментов. Но вот на практике мало верится что кто-то сможет рассмотреть что там на серёжках изображено. Не зря же для большего внимания их делают порой весьма большими :)
Почти ничто из этого списка меня не задело, а за Кортану просто спасибо, что выкинули!
Решил посмотреть программу. Возникл вопрос: зачем в EEPROM на каждый UID отведено 5 байт, когда вы пользуетесь только 4-мя?
Я бы предпочёл вызывать Tcl-функции из перла (не сложно прилинковать libtcl). Но зачем?
Это верно, к сожалению. Но по описанию проблемы, именно тут бы он хорошо бы подошёл, я только это хотел сказать. Сам на Perl писал больше 20 лет, но под новые проекты его не беру -- некому будет продолжать если что...
Что, и доступ к USB получится?
На Perl надо было писать. Вот уж кто закостенел, но при этом достаточно гибкий...
Это пока что не очевидно. Ну, вот мой пример: контроллер дисплеев. Я бы взял ESP32 в качестве контроллера дисплеев, по два на контроллер, каждый на своём SPI, а информацию что на дисплее показывать передавал бы через I2C. На мой взгляд, это было бы разумно: более медленный протокол передаёт более высокоуровневые команды, которые потом "простым" микроконтроллером транслируются в быстрые передачи по шине SPI, суммарно таким интеллектуальным образом увеличивая пропускную способность и разгружая центральный "мозг". А вот что у Вас за проект, мне пока не понятно. Если для связи с микроконтроллером используется SPI, то микроконтроллер должен много данных принимать быстро и что-то с ними делать ещё быстрее. И вот эта вот цель мне пока не понятна.
Идея интересная. Возникает вопрос: что это такое должно быть? Почему SPI? От себя: я знаю для чего я применил бы 3-4 управляемых ESP32, но для связи я бы взял I2C.
Это обычные, не "про"? У которых заявлено "40 часов"?
Хожу до сих пор с Samsung Galaxy Watch, 46 mm. Купил их когда они вышли, в 2018. 5 лет часам. При нормальном использовании заряда аккума хватает на 3-4 дня, никаких особых ухищрений для экономии аккумулятора, всё включено. На замену думаю взять только что-то типа "про" версии, остальный по акуумуляторам ну очень смешные. Но пока не созрел, работают и эти...
Жене вот в итоге не могу ничего подобрать -- "про" версия ей большая...
Я же давал ссылку на гитхаб с часиками, там это всё реализовано. Если коротко, то рисовать "в ОЗУ" намного быстрее, чем на физическом экране. Вплоть до того, что алгоритмы примитивов должны быть разными.
Я сделал грубый замер бенчмарков для наклонной линии:
Если рисовать наклонную линию отрезками горизонтальных/вертикальных линий на физическом дисплее, то в среднем это в два раза быстрее, чем по точкам;
Если рисовать наклонную линию горизонтальными/вертикальными отрезками в ОЗУ, то в среднем это в два раза медленнее, чем точками. Этот эксперимент, правда, был очень грубым и на другой архитектуре.
Рисование в ОЗУ быстрее во много раз. Если сделать несколько виртуальных экранов (буферов в ОЗУ) то можно разные комбинации с ними делать. Шрифты, рисующиеся отдельными точками, уже не так уж медленно работают. Вот второй пример (ссылка на гитхаб в описании): https://www.youtube.com/watch?v=9nOHqma-i0U
Я вообще не в курсе частоты I2C "по умолчанию", просто ставлю сколько надо и всё. Если всё работает, то можно дальше ничего не подбирать :)
Не совсем. RP2040 -- MCU, а RPi Pico -- плата разработчика на этом микроконтроллере.
Дисплей -- основной потребитель в консоли. Микроконтроллер кушает мало. Вайфай и блютус могут тоже кушать, ещё какое-то оборудование, но тут речь больше про дисплей.
А смысл? Я себе сейчас взял для "микро" RP2040 Zero, вот уж реально "микро" и при этом нормально так всё по мощности. А вот эти вот ардуиновские "2 KB RAM" при работе с какой-либо графикой вообще не прикольны.
Я писал свою для ESP32. Вот тут она использовалась: https://www.youtube.com/watch?v=8uT_J_MVam4
Там всё не так прямо плохо. Проблема вообще в принципе оптимизации пересылок. Допустим, надо отрисовать точку, для этого типичному SPI дисплею требуется 5 операций:
послать команду установки горизонтальной области х,х;
послать координаты х,х;
послать команду установки вертикальной области у,у;
послать координаты у,у;
послать данные цвета точки.
Если же надо нарисовать прямоугольник, то там совершенно те же 5 операций, только коородинаты несколько большую облать задают и за одну 5ю операцию заливается всё. Именно разбивка на операции тормозит всё рисование. Нарисовать одну точку или 200 по времени отличается не так сильно. Поэтому, стремятся применять оптимизации рисования примитивов, например, рисовать наклонную линию из отрезков горизонтальных/вертикальных линий, а не по точкам. Экономить пересылку координат, если одна совпадает, то не пересылать её повторно. Ну и так далее.
Адафрукт изза изначальной ориентированности на слабые МК не делает максимума оптимизаций что возможны под конкретную архитектуру, они больше ориентируются на универсальность применения. Как и весь Ардуино-фреймворк, надо сказать.
На счёт текста -- многие библиотеки делают отрисовку символов попиксельно, обеспечивая таким образом "прозрачность" для незаполненных участков.
Я для себя решил, что рисовать надо в виртуальных экранах, а затем просто пересылать на экран результат. Это получается часто эффективнее и быстрее, чем рисовать попиксельно на настоящем экране.
Если посмотреть на даташит от SSD1306, то минимальный период для I2C SCL - 2,5 us. Что именно 400kHz.