Embedded шрифт 6x7 на полуглифах

Мне нравится, хоть некоторые символы выглядят странно (например, N, J, [). Насколько сложно добавить флаги «отзеркаливания» полуглифа по горизонтали и по вертикали? Возможно, будет лучше выглядеть.

lodepng в конвертере старенький. :)

IMHO подгонять людей под байты - так себе идея. Как и фигачить интерфейсы без дизайнера. Но в эмбедах почему-то принято считать, что это норм.

Можно ещё сэкономить на глифах за счёт зеркалирования но при этом усложнять код рисования. И почему то мне кажется что суммарно флеша сожрётся больше чем сейчас

Потому что если позвать дизайнера, стоимость устройства (и может даже разработки) рискует вырасти многократно за счёт появления ненужных элементов интерфейса.

Мне кажется, нужно танцевать от обратного: сначала нарисовать алфавит, потом разбивать его на глифы/полуглифы/zipглифы и оптимизировать. А у тебя, мне кажется, была идея, как хранить информацию, ты нарисовал несколько полуглифов, потом собрал из них алфавит. Дизайнер тут не нужен, нужен ПМ.

Надо взять векторный фонт, и забабахать опциональные фичи - кернинг, субпиксельное сглаживание, нарезку диапазонов и т.п.

Получается как-то так.

Ну не знаю, у меня 4 Кб флеша.

Может если не делать верхнюю загогулину у C, то и [ будет нормально выглядеть?

Технически подход конечно прикольный, но юзерам нужен не подход а внешний вид. И то что они безропотно хавают всякий шлак - не повод приучать их к плохому. Иначе будет как с машиной для стрижки:

• Но ведь у всех головы разные!
• Ага, до первой стрижки разные.

Я гонял всякие pixel-perfect шрифты, они меньше кило занимают по той спеке. Не помню уже деталей. Не жопа даже по меркам твоих 4К. Но я особо не упирал в оптимизацию битональников. Упор был на 3-4 бита grayscale/пиксель, с 3x по горизонтали, чтобы цветные говнодисплейчики казали не хуже чем на компах.

Далёк ты от романтики запихать часы с OLED экраном в 1к флеша тини13. Но твой подход более индустриальный.

Не знаю откуда эта тяга преодолевать, впихивать невпихуемое, по максимуму использовать смешные 5 ножек. При том что можно взять мк на пару эволюций выше(как ни странно по той же цене) и иметь уже более умную прошивку с бОльшим количеством защит.

Сейчас я тоже стал бить себя по рукам за очередную попытку «но я могу впихнуть это в attiny13a».

Экономия байт в суровом embedded действительно имеет место. Когда продукт выпускается миллионными тиражами.

Но я всё равно ментально против когда железо используется не рационально. Когда кто то делает на баше или питоне используя целый линукс микро пк то что можно на си в 8 битном мк за 3 копейки и выйдет даже лучше.

Если подобный подход распространиться то в embedded мире произойдёт тоже самое что и в пк мире где веб тормозит, жрёт память. Декстоп приложения пишут на веб технологиях. Эмулятор эмулятором погоняет. И то что 20 лет назад работало на первопне сейчас тормозит на свежем i7.

А это для каких дисплейчиков? И какие дисплейчики вы все используете? Какие самые дешовые и где их взять (выковырять)

Да нет, я вполне понимаю подобные алгоритмы как вид искусства. Но гнать такое в продукты… или экономить на сериях меньше 100К…

Но я всё равно ментально против когда железо используется не рационально. Когда кто то делает на баше или питоне используя целый линукс микро пк то что можно на си в 8 битном мк за 3 копейки и выйдет даже лучше.

Я начинал с железа, и потом очень долго отучался от эмбедских ухваток. Проблема многих эмбедеров не в том что байты экономят, а в том что экономят ВМЕСТО проработки архитектуры и целеполагания.

Если подобный подход распространиться то в embedded мире произойдёт тоже самое что и в пк мире где веб тормозит, жрёт память. Декстоп приложения пишут на веб технологиях. Эмулятор эмулятором погоняет. И то что 20 лет назад работало на первопне сейчас тормозит на свежем i7.

У меня есть 2 забавных примера.

1. Автор U8G2 точил формат шрифтов по-эмбедски. Экономил байты и все такое. Моя спека оказалась эффективнее (хотя с виду более развесистая).

2. Авторы LVGL долго и вдохновенно экономили байты. Переход на более формальное ООП сильно всё выпрямил и сэкономил заметно больше.

IMHO идея полубукв - частный случай упаковки по словарю (довольно убогий частный случай, т.к. всего 2 варианта сегментов, верх и низ). Подозреваю, это можно как-то вывести в общем виде, не насилуя буквы. Ну займет оно 100 байт вместо 40, зато любой фонт будет жать.

Знаешь почему я в спеке не стал упарываться с компрессией битональных шрифтов? Размер ядра LVGL около 64К. Потенциальный профит от экономии не стоил затрат. Оставил добровольцам (спека гибкая), у меня просто подходящих задач не нашлось, где это имело бы смысл.

Вот что реально полезно - переписать в LVGL декомпрессор, он сейчас медленный, т.к. неправильно сделан.

Загугли на алиэкспрессе «OLED display». Мелкие дисплеи с i2c/spi.

Но в тех же размерах и за похожие деньги есть цветные дисплеи (там же, по запросу «IPS display»), где разрешение выше и можно делать субпиксельное сглаживание.

Поэтому сейчас для применения монохромных OLED надо иметь какие-то веские аргументы. Бывает что выгоднее, но редко.

Аааа, понял. У меня на сломанном usb плеере, походу такой. Попробую выяснить что за модель и присоединится =)

Лучше ориентироваться на реально доступные. С али в первую очередь. А общий спектр как-то так https://www.buydisplay.com/oled-display/oled-display-panel.

Лучше ориентироваться на реально доступные

Это правильно, это поддерживаю. Главное доступность.

Ну, заказывать у меня денег нет, а этот дисплейчик я уже отковырял =)

Называется ug-2832 tswec 17 или ug-2832 tsweg 17 не разобрать надпись потёртая. Поискал вроде оно https://aliexpress.ru/item/32383742015.html?sku_id=56844769364 но надо ещё уточнить (почти оно буквы названия разные, надо ещё уточнять), порыл есть разные модификации на SSD1306/I2C и пассивные (что-бы это значило) на SPI.

За неимением иного и за имением того что вот прям у меня в руках буду пытаться вывести квадратик на это дисплей, тока там на шлейфе дорожки манюсенькие =( Надо удобную платку вытравить сначала, вот и испытаю парафиновый метод нанесения тонких дорожек в деле =)

Сделал бы чего реально полезного, вроде того же декомпрессора для LVGL.

А я бы взамен оторвал зад от стула, дошел до почты, и отправил тебе кулек дисплеев, esp и прочей хрени, которую выкидывать собрался (я отчаливаю, и не актуальное с собой не повезу)

часы с OLED экраном

1 bit?

декомпрессора для LVGL

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

Вечером поковыряюсь, пойму и будет интересно, сделаю. Не пойму не сделаю =)

Может даже интересно будет и к тому моменту когда сделаю ты куда то там уже уедешь, ну и ладна :D.

А ты куда собралсо то?

У меня такой (ну или почти такой) в проекте. SSD1306, SPI, 128x32, 0.91". Управляется сигналами 3.3V, питается от 5V (внутри сам повышает до 7.25V, нужны только два конденсатора).

Ну как возьмусь и будет затык я обращусь =)

На чём пишешь и какой МК?

ATmega8a-pu/Сишка. Я тока началь ^.^

https://github.com/wagiminator/ATtiny13-TinyOLEDdemo

512 байт в тиньке 13 для экранного буфера явно нет тч они выводят цифры процедурно. I2c софтовый вышел на удивление маленький.

Короче, если совсем кратко, у тебя два варианта:

• взять питание от USB (4.5~5.5V) и регулятор на 3.3V: от регулятора питаешь атмегу и контроллер дисплея, от USB питаешь встроенную повышайку (понадобятся два конденсатора на 1uF)
• взять питание чуть посерьёзнее (7~7.5V) и регулятор на 3.3V: от регулятора питаешь атмегу и контроллер дисплея, а высоким напряжением питаешь дисплей (в этом случае конденсаторы не нужны)

Думаю, для самого начала этой информации достаточно.

Красивый эффект на последней гифке – это какие-то манипуляции с памятью контроллера дисплея?

Я бы настоятельно рекомендовал stm8 как что то уже не такое ущербное как avr но при этом не требующее жирно HAL как Stm32. И главное есть готовые платы с дисплеями и кнопками https://github.com/TG9541/stm8ef/wiki/STM8S-Value-Line-Gadgets

1. STM32 не требует HAL
2. AVR вряд ли ущербнее STM8 и намного популярнее

Дай ссылку на матчасть

https://github.com/lvgl/lv_font_conv/blob/master/doc/font_spec.md#compression-algorithm

Декомпрессор:

https://github.com/lvgl/lvgl/blob/master/src/font/lv_font_fmt_txt.c#L356

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

В общем, стандартная тема для RLE-декомпрессора, которые изучены вдоль и поперек, надо только сделать нормально.

А ты куда собралсо то?

Тут ключевой момент не куда, а откуда :) . Я по пояс в говне распевать гимны не подписывался.

Не специалист в Stm32 но мне казалось что без Hal на голых портах там висилица. Только сильные духом вроде эдика могут.

Берешь stm32cube MX, ставишь галочки, и он тебе генерит всю инициализацию. Очень быстро и удобно. Во всех моих проектах так. А Эдик гордится тем, что умеет без генерилки такой код написать. И почему-то считает, что все должны страдать такой же херней, как он сам.

Ты это, не советовал бы 8-битные контроллеры для обучения. Сорта говна, IMHO. Потом переучиваться проблемно.

Спасибо =)

У меня 5 мег лежит. Я уже к usb присобачил. Для моих нужд любительских уже выше крыши. Правда с USB не так много вычислительного времени остаётся, но эт ладна. Но спасибо за совет. Если увлекусь дальше и мне надо будет больше. То да.

АВР всё же так сказать народный микроконтроллер. Удобный. От 2,7 вольта может на свехрнизких частотах работать и вообще =) Восьмебитная няшка. СТМ это уже для больших дядей с большими хотелками и которым главное ехать и никаких шашечек =)

и можно делать субпиксельное сглаживание

А на таком мелком размере монохромные не будут лучше бОльшим контрастом и лёгкостью читаемости? Или от конкретной модели сильнее зависеть будет?

Поковыряю. Сделаю и кастану и ссылку дам, не сделаю не кастану и ссылку не дам. Понравится возьмёшь, не понравится не возьмёшь =)

Не скажу что я тебя прям понял =) Ибо какая разница что данные в 8 битном виде что в 32битном. А реальные 32 битные регистры дёрганные вручную не везде есть, можно из 4х 8 битных сляпать, ну эт такое себе =) Обрабатывать 8 битные можно блоками по 32 и наоборот, оно же в виде массива приходит, входящее то. Я так поверхностно глянул, ну пришёл char массив и задан char выходящий.

Дальше правда начинается побайтовая дрочка. Извлечь байт, декодировать линию, записать в выходящий массив и так по кругу. Что изменится если брать блок по 32бита я хз один фиг из него дёргать байты и проверять. Ну там ещё можно часть функций как бы вообще выкинуть. Я наверное туповат и не так понял.

Давай проще. Вот у тебя входящие данные, битовый «поток» в виде массива char, выходной такой же. Ты хочешь что-бы войдя внутрь функции decompress перестала работать побайтовая дрочка, а брался из входящих данных кусок в 32 бита, декодировался и выплёвывался блоком в out массив (который обычный char)?

32-битные регистры

Прям регистры регистры ассемблерные? Или просто u/int32 блоки извлекаемые из входящего байтового «потока»?

Тут ключевой момент не куда, а откуда :)

Ладно, не будем про это.

Преимущества stm8 над avr.

• богаче периферия
• единый доступ к любому типу памяти. Всё лежит в едином адресном пространстве. Никаких тебе спец процедур для чтения eeprom и pgmspace
• человеческая отладки по шагам
• отсутствие фьюзов которыми можно превратить avr в кирпич при отсутствии специального высоковольтного программатора
• дешевле avr
• куча готовых плат с дисплеем и кнопками от китайцев(но сейчас всё меньше и меньше :-/)

Минусы

• только 8к флеша
• мало распространен среди энтузиастов. Нужно портировать код из avr

Ну, учту.

Никаких тебе спец процедур для чтения eeprom и pgmspace

А это даже приколько, eeprom как будто внешняя флешка маненькая торчит =) А PROGMEM это как вручную заданные ELF RO DATA в заголовке исполняемого файла, типа const char[] = "Hello Ворлд!" строка будет намертво вшита в заголовок ELF файла. Так же и с PROGMEM константа вшитая в программную память - читай как бинарник исполняемый типа, гы =), ну и что что обращаться к нему надо через функцию и обязательно приводить тип получая значение. Допустим это как будто оно хранится в сыром указателе, ну и надо приводить =) Если всё вот это воттак воспринимать, то как будто работаешь просто с некой библиотекой, ну вот так у неё всё устроено чтож поделать ¯_(ツ)_/¯

Да это неправильное восприятие гарвардской архитектуры, но да пофиг =)

Ну я лично храню экземпляры классов прямо в eeprom. Если бы пришлось читать побайтово то фиг бы я так сделал

Ну сначала определись, что надо вообще - чтобы читалось на солнце, или чтобы все-таки красиво выглядело. В станках вон до сих пор дисплеи на 7-сегментных восьмерках.

Субпиксельное сглаживание повышает разрешение по горизонтали в 3 раза. С ним 12px выглядит не хуже 14px.

Не скажу что я тебя прям понял =) Ибо какая разница что данные в 8 битном виде что в 32битном.

Меньше обращений к памяти. Заметно влияет. Можешь в трекере поискать, я где-то расписывал что косячно в декомпрессоре и методы исправления, но уже не помню деталей.

Короч, правильно написанный RLE может оказаться быстрее простого чтения из памяти. А текущий декомпрессор проще выкинуть нахрен, он deffective by design, бесполезно мелочи анализовать.

Давай проще. Вот у тебя входящие данные, битовый «поток» в виде массива char, выходной такой же. Ты хочешь что-бы войдя внутрь функции decompress перестала работать побайтовая дрочка, а брался из входящих данных кусок в 32 бита, декодировался и выплёвывался блоком в out массив (который обычный char)?

Как-то так. Просто сейчас декомпрессор типа «универсальный», который 1-2-3-4 бита на пиксель понимает. И кучу проверок делает, сколько битов. А надо реально сделать декомпрессию 3бит/px и этого большинству хватит на всю жизнь.

И подобного рода продолбанство по всему декомпрессору. Например битики считаются, вместо того чтобы в хвосте регистра флаг взвести, и после сдвига проверять значение регистра на ноль.

Прям регистры регистры ассемблерные? Или просто u/int32 блоки извлекаемые из входящего байтового «потока»?

Не, ну все на сишечке конечно, дальше компилер сам сообразит, что делать. Этого точно будет достаточно.

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

Посмотрите на чертежный шрифт ГОСТ. Вам надо типа такого придумать, но растровое

Понял, попробую.Если получится что-то путное отпишусь.

IMHO подгонять людей под байты - так себе идея.

Игнорировать объективную реальность, данную нам в кремнии, - вот это действительно хреновая идея.

ТС указал на область применения совоего поделия.

У HAL и у LL есть фатальный недстаток: их долбодятлы под руководством «эффективных менеджеров» «проектировали» и писали.

Они думали не о том, что нужно разработчикам девайсов (быстрая коррекция софта при обновлении железа), а о том, как обеспечить миграцию между своими линейками контроллеров.

MX - костыль, который был сделан для того, чтобы учёт изменений в железе не был настолько адской болью, как без MX.

человеческая отладки по шагам

• avarice,
• https://github.com/jdolinay/avr_debug
• simavr

отсутствие фьюзов которыми можно превратить avr в кирпич при отсутствии специального высоковольтного программатора

они там option bytes называюся, при желании можно окирпичить stm8/32 на отличненько

дешевле avr

• ХЗ

Минусы

• CISC с непредсказуемым временем выполнения команд

По каждому пункту согласен, кроме третьего.

дешевле avr

Этот пункт лютое 4.2. Не помню уже, что было раньше, но по крайней мере сейчас, в эру Микрочипа, AVR максимально дёшевы, дешевле разве что 8051.

Откроем, например DigiKey. В параметрах фильтра по микроконтроллерам «Core Processor: STM8, STM8A», «Product Status: Active», «In Stock». Видим всего три позиции: €1.10, €3.40, €3.50.

Теперь повторим поиск с другими параметрами: «Core Processor: AVR», «Product Status: Active», «In Stock». Что же мы видим? 479 позиций от €0.48 (первые 60 из них до €1).

Как твои успехи с подпаиванием к FPC с шагом 0.5mm?

Пока никак я собрал UART приёмо передатчик (и не только, с бутлоадером свисток) для того что-бы не городить USB каждый раз когда хочу общаться с микроконтроллерами https://linuxtalks.co/forum/hardware/576. Сделаю ещё платку с мегой для тестов и экспериментов и попутно буду пытаться сделать платку для дисплейчика заодно парафиновым методом. Об успехах отпишусь. А пока я вот сегодня взялся глядеть по поводу просьбы @ Vit переписать LVGL RLE декодер для его STM32 эмбеда. Хз может вечерком будет лишние полчасика, сделаю переходник под дисплейчик, дорожки 0,5 сделать вручную не проблема проблема будет подпаять 40 ватным паяльником размером с утюг :D Если смогу выложу вотку (если смогу снять нормально, на полуживой телефон где сломан (выдран с корнями фокус камеры) хехе

Вот тут я травил для теста в «негативе» https://i.ibb.co/Y3XZbkQ/20220515-133445.jpg, тоже самое можно сделать в «позитиве» примерно 0,5 мм и есть.