Модель дисплея секретная что ли? Нигде в тексте не вижу. Про готовые библиотеки на гитхабе, пересылку данных из виртуального буфера и самые распространённые названия тут уже отметились, очевидно. Но, надо признать, ситуация со шрифтами не такая однозначная.
Конкретно под этот дисплей, конечно, можно сделать вообще шик-блеск по эффективности, если принять высоту шрифта кратной 8 и у-координата левого верхнего угла символа всегда кратна 8. В этом случае можно закодировать бинарные данные символа вертикально и напрямую слать в контроллер.
В этом же гитхаб-репозитории моя экспериментальная библиотека с поддержкой разных типов дисплеев и шрифтов, а так же проект с красивым морфингом чисел на часах.
Я надеялся узнать о программировании эффектов, поскольку думаю для дома что-то подобное собрать.
Не понятен выбор "чёрной пилюли", когда в статье упоминается о синхронизации между контроллерами. Вообще ни слова в итоге про это. Припаять микросхему и резистор -- для чего?
Взял за основу primes-3.cpp, немного потестировал его под WSL/Ubuntu 20.04.
isqrt vs sqrtf - 10% разницы в пользу sqrtf (для всей программы)
clang++ -march=tigerlake vs no -march
1.5sec vs 2.4sec (версия с isqrt)
g++ (v10.3) vs clang++ (v10) примерно одинаково без указания -march, но при указании, g++ десятой версии как будто ничего не знает про архитектуру и быстродействие его результата практически не меняется. Возможно, в g++ 11й версии это исправили, нет под рукой чтобы проверить.
Процессор для опытов -- Intel Core i7 1165G7. Возможно, на дескптопном или серверном или просто другой модели процессора ситуация будет иной. Надо проверять. На каком-нибудь микроконтроллере isqrt может оказаться производительнее, чем sqrtf.
Вопрос быстродействия очень сложный и делать далеко идущие выводы, отталкиваясь от небольшого числа частных случаев, надо осторожно. Нужно реально проверять разные архитектуры, версии процессоров, понимать где бутылочные горлышки, от чего тормозит память или ломается предсказатель ветвлений и тому подобное.
Я написал свой комментарий в дополнение к изложенной информации. Будете ли вы это использовать, или кто-то другой -- я не могу повлиять. Мне просто было что сказать.
"Впрочем, оптимизировать тут можно в любом случае." -- я ж об этом и написал. У меня есть опыт программирования для SSD1306, который не сильно отличается от SH1106.
Возвращаясь к тому, что я сказать хотел. Реорганизацией представления данных можно заметно повысить эффективность как по памяти, так и по быстродействию, мало ли что ещё надо делать микроконтроллеру в это же самое время. Если бы это было в статье, она была бы интереснее, с моей точки зрения. А так, мы просто обучились пользоваться несколькими приложениями.
Я правильно понимаю, что проеобразованный в Си код содержит изображение построчно? И это для дисплея с внутренним по-колоночным буфером (по 8 бит в колонке)? То есть, мощность процессора у нас запасом?
Я к чему -- если картинка размером по вертикали кратна 8 и выводится по вертикальной координате в кратную 8 позицию, то вывод битмапа можно существенно оптимизировать. Впрочем, оптимизировать тут можно в любом случае.
Название символа -- это полезно, конечно, но визуальный контроль в комментариях исходника вреда не несёт, так почему бы и нет? Не настаиваю, я сейчас на другим вопросом думаю -- как бы такой вот алфавит сделать в визуальном редакторе, а не подгонкой координат руками, как я это для десяти цифр сделал: https://www.youtube.com/watch?v=GvBGo-hvBrQ
Сам я больше бэкендер по работе, фронтендом только по случаю занимаюсь, в основном веб, редко приложения для десктопа... Мне нужен (мне нужно сделать) визуальный редактор символов, рисуемых из кубических кривых Безье на поле 100х160 (мой размер из демки) с возможностью добавления полей в разные стороны. Ну это так, лирическое отступление на тему шрифтов и их редакторов. Свой первый редактор матричных шрифтов я делал ещё на MSX-Basic году так в 1990м...
На счёт сжатия шрифта. Я пробовал модификацию RLE. Экономия размера до 30%, но разжатие каждого символа довольно дорого получается и требует выделения памяти хотя бы один раз в двойном размере. Поскольку у меня ESP32 и там нет такой уж явной нехватки памяти, то экономия пары килобайт на шрифт не имеет критической важности, а алгоритм упрощается заметно и скорость тоже вырастает.
Мне тоже недавно захотелось побаловаться с микроконтроллерами. Ардуино и прочая мелочь таки мне скучна в виду слабый возможностей коммуникации, поэтому обратил внимание на ESP32. Поскольку это моё личное время, то трачу его как хочу :) -- написал свою графическую библиотеку с поддержкой разных экранчиков, но откуда брать шрифты, не рисовать же их? Творчески переработал опенсорсную утилиту, которая на основе freetype конвертирует "обычные" шрифты в код на Си. Некоторые идеально прямо вот конвертируются в нужные размеры, но большинство "корявенько", поскольу монохром, а для качества надо бы хотя бы сглаживание. Впрочем, если требуется большой размер символов, то почти любой шрифт подойдёт для конвертации. Вот тут, например, можно видеть результат: https://www.youtube.com/watch?v=9nOHqma-i0U
Я, возможно, не гуру теории программирования, но пояснения к "Фрагмент N4: неудачное явное приведение типа" меня как-то не удовлетворили. Я так понимаю, автор собирал библиотеки на 64-битной системе, где int имеет размер 32 бита, а size_t размер 64 бита. В этом случае объяснение и решение верное, но разве эра 32-битных ситем закончилась и их нигде и никак не осталось? Может быть это уже можно считать верным для десктопа, но для встраиваемых систем это точно вряд ли. Как я понимаю, на 32-битных ситсемах размер size_t будет те же 32 бита, а тогда ни о каком решении проблемы переполнения речи нет.
Прочитав статью, могу сказать, что сравнение было не с Перлом, а с имеющимися знаниями о Перле. Что CGI масштабируется плохо — известно было с очень давних пор, в мире Перла выходов из этого было много, но автору они были не интересны (автор не представляет как отлаживать программы на Перл и не был сильно уж заинтересован узнать).
У меня сложилось впечатление, что как в 2000 году автор выучил какое-то подмножество Перл, достаточное для каких-то сайтов, так с тех пор его знания о Перле остались на том же уровне.
Знаю о чём говорю, в одиночку писал проекты на Перл в 100 тыщ строк, участвовал в проекте в почте 200 тыщ строк.
В общем, автор поделился своими достижениями в Паскале, что, конечно, не плохо, но Перл является очень недооценнённым языком именно из-за предубеждения знатоков из 2000 года.
Модель дисплея секретная что ли? Нигде в тексте не вижу. Про готовые библиотеки на гитхабе, пересылку данных из виртуального буфера и самые распространённые названия тут уже отметились, очевидно. Но, надо признать, ситуация со шрифтами не такая однозначная.
Конкретно под этот дисплей, конечно, можно сделать вообще шик-блеск по эффективности, если принять высоту шрифта кратной 8 и у-координата левого верхнего угла символа всегда кратна 8. В этом случае можно закодировать бинарные данные символа вертикально и напрямую слать в контроллер.
На счёт шрифтов я таки озаботился конвертором из TTF. Отличные матричные шрифты получаются из terminus ttf чётных размеров. Пример: https://github.com/jef-sure/ili9341_dgx/blob/main/components/dgx/src/fonts/TerminusTTFMedium12.c
В этом же гитхаб-репозитории моя экспериментальная библиотека с поддержкой разных типов дисплеев и шрифтов, а так же проект с красивым морфингом чисел на часах.
Я надеялся узнать о программировании эффектов, поскольку думаю для дома что-то подобное собрать.
Не понятен выбор "чёрной пилюли", когда в статье упоминается о синхронизации между контроллерами. Вообще ни слова в итоге про это. Припаять микросхему и резистор -- для чего?
Взял за основу primes-3.cpp, немного потестировал его под WSL/Ubuntu 20.04.
isqrtvssqrtf- 10% разницы в пользуsqrtf(для всей программы)clang++ -march=tigerlake vs no -march
1.5sec vs 2.4sec (версия с isqrt)
g++(v10.3) vsclang++(v10) примерно одинаково без указания-march, но при указании,g++десятой версии как будто ничего не знает про архитектуру и быстродействие его результата практически не меняется. Возможно, вg++11й версии это исправили, нет под рукой чтобы проверить.Процессор для опытов -- Intel Core i7
1165G7. Возможно, на дескптопном или серверном или просто другой модели процессора ситуация будет иной. Надо проверять. На каком-нибудь микроконтроллереisqrtможет оказаться производительнее, чемsqrtf.Вопрос быстродействия очень сложный и делать далеко идущие выводы, отталкиваясь от небольшого числа частных случаев, надо осторожно. Нужно реально проверять разные архитектуры, версии процессоров, понимать где бутылочные горлышки, от чего тормозит память или ломается предсказатель ветвлений и тому подобное.
Python нужен для работы ESP-IDF, поверх которого работает библиотека Arduino для ESP32.
Я написал свой комментарий в дополнение к изложенной информации. Будете ли вы это использовать, или кто-то другой -- я не могу повлиять. Мне просто было что сказать.
"Впрочем, оптимизировать тут можно в любом случае." -- я ж об этом и написал. У меня есть опыт программирования для SSD1306, который не сильно отличается от SH1106.
Возвращаясь к тому, что я сказать хотел. Реорганизацией представления данных можно заметно повысить эффективность как по памяти, так и по быстродействию, мало ли что ещё надо делать микроконтроллеру в это же самое время. Если бы это было в статье, она была бы интереснее, с моей точки зрения. А так, мы просто обучились пользоваться несколькими приложениями.
Я правильно понимаю, что проеобразованный в Си код содержит изображение построчно? И это для дисплея с внутренним по-колоночным буфером (по 8 бит в колонке)? То есть, мощность процессора у нас запасом?
Я к чему -- если картинка размером по вертикали кратна 8 и выводится по вертикальной координате в кратную 8 позицию, то вывод битмапа можно существенно оптимизировать. Впрочем, оптимизировать тут можно в любом случае.
Название символа -- это полезно, конечно, но визуальный контроль в комментариях исходника вреда не несёт, так почему бы и нет? Не настаиваю, я сейчас на другим вопросом думаю -- как бы такой вот алфавит сделать в визуальном редакторе, а не подгонкой координат руками, как я это для десяти цифр сделал: https://www.youtube.com/watch?v=GvBGo-hvBrQ
Сам я больше бэкендер по работе, фронтендом только по случаю занимаюсь, в основном веб, редко приложения для десктопа... Мне нужен (мне нужно сделать) визуальный редактор символов, рисуемых из кубических кривых Безье на поле 100х160 (мой размер из демки) с возможностью добавления полей в разные стороны. Ну это так, лирическое отступление на тему шрифтов и их редакторов. Свой первый редактор матричных шрифтов я делал ещё на MSX-Basic году так в 1990м...
Не скажу на счёт общей востребованности, но, когда требуются не стандартные символы, то весьма полезно, считаю. https://github.com/jef-sure/dgx_clock/blob/main/components/dgx/src/fonts/WeatherIconsRegular24.c
На счёт визуализации шрифта в исходнике. Вот тут можно видеть что получается: https://github.com/jef-sure/dgx_clock/blob/main/components/dgx/src/fonts/TerminusTTFMedium12.c
На счёт сжатия шрифта. Я пробовал модификацию RLE. Экономия размера до 30%, но разжатие каждого символа довольно дорого получается и требует выделения памяти хотя бы один раз в двойном размере. Поскольку у меня ESP32 и там нет такой уж явной нехватки памяти, то экономия пары килобайт на шрифт не имеет критической важности, а алгоритм упрощается заметно и скорость тоже вырастает.
Мне тоже недавно захотелось побаловаться с микроконтроллерами. Ардуино и прочая мелочь таки мне скучна в виду слабый возможностей коммуникации, поэтому обратил внимание на ESP32. Поскольку это моё личное время, то трачу его как хочу :) -- написал свою графическую библиотеку с поддержкой разных экранчиков, но откуда брать шрифты, не рисовать же их? Творчески переработал опенсорсную утилиту, которая на основе freetype конвертирует "обычные" шрифты в код на Си. Некоторые идеально прямо вот конвертируются в нужные размеры, но большинство "корявенько", поскольу монохром, а для качества надо бы хотя бы сглаживание. Впрочем, если требуется большой размер символов, то почти любой шрифт подойдёт для конвертации. Вот тут, например, можно видеть результат: https://www.youtube.com/watch?v=9nOHqma-i0U
Я, возможно, не гуру теории программирования, но пояснения к "Фрагмент N4: неудачное явное приведение типа" меня как-то не удовлетворили. Я так понимаю, автор собирал библиотеки на 64-битной системе, где int имеет размер 32 бита, а size_t размер 64 бита. В этом случае объяснение и решение верное, но разве эра 32-битных ситем закончилась и их нигде и никак не осталось? Может быть это уже можно считать верным для десктопа, но для встраиваемых систем это точно вряд ли. Как я понимаю, на 32-битных ситсемах размер size_t будет те же 32 бита, а тогда ни о каком решении проблемы переполнения речи нет.
У меня сложилось впечатление, что как в 2000 году автор выучил какое-то подмножество Перл, достаточное для каких-то сайтов, так с тех пор его знания о Перле остались на том же уровне.
Знаю о чём говорю, в одиночку писал проекты на Перл в 100 тыщ строк, участвовал в проекте в почте 200 тыщ строк.
В общем, автор поделился своими достижениями в Паскале, что, конечно, не плохо, но Перл является очень недооценнённым языком именно из-за предубеждения знатоков из 2000 года.