Easyelectronics.ru

Электроника для всех
Текущее время: 24 сен 2020, 19:16

Часовой пояс: UTC + 5 часов



JLCPCB – Прототипы печатных плат за $2/5шт. два слоя. $5/5шт. четыре слоя
Крупнейший производитель печатных плат и прототипов. Более 600000 клиентов и свыше 10000 заказов в день!
Получите скидку на почтовую отправку при первом заказе в JLCPCB!

Начать новую тему Ответить на тему  [ Сообщений: 48 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 16:23 
Старожил
Аватара пользователя

Зарегистрирован: 28 дек 2016, 00:04
Сообщения: 264
Откуда: Россия, Москва
За основу взял https://github.com/4ilo/ssd1306-stm32HAL Очень клёвая библиотека, полностью на HAL, просто и понятно написана, использует страничную адресацию. Но поддерживает только I2C, а мне нужен был 4-wire SPI. Сделал форк, запилил SPI, проверил на четырех экранчиках. Вроде работает https://github.com/afiskon/stm32-ssd1306

Автору предложил накатить мои изменения, но он предпочел оставить ссылку на мой форк в README.

Возможно, также работает с SH1106 и SSD1309, но экранчики еще не доехали, чтобы проверить. Также библиотека не умеет русский шрифты и геометрические примитивы. С радостью приму соответствующие пулл реквесты, если есть интерес это реализовать. Когда у самого руки дойдут - не знаю.

Надеюсь, кому-нибудь пригодится.

_________________
https://eax.me/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 17:09 
Старожил

Зарегистрирован: 21 янв 2015, 16:19
Сообщения: 617
Спасибо, мил человек!!!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 18:00 
Старожил

Зарегистрирован: 08 авг 2013, 09:43
Сообщения: 2874
Спасибо, ссылку схоронил. Как раз недавно для друга закончил небольшой девайс с SSD1306 128x64, но на AVR делал.
А U8g2 не смотрели? Вроде портировали её успешно на STM32 тут: https://github.com/olikraus/u8g2/issues/179 Оно конечно корнями уходит к ардуино, но функционал либы неплох очень и фонты есть разные и свои добавить не сложно любые.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 18:56 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Блин, чувак, извини конечно, но подобных "поделок" по инету гуляет херова туча. Однако, чувак, если уж делать, то делать надо по-человечьи. Почему бы например вместо отдельной команды обновления дисплея не посадить SPI на DMA-канал и не забыть вообще про какие-то команды обновления дисплея? Один раз делается инит дисплея, один раз запускается поток и затем спокойно заполняется буфер. Любые изменения в буфере будут отражены на дисплее без лишних телодвижений и в любой момент.
Русские шрифты? Бля, чувак, а какая, в жопу, разница, в какой кодовой странице представлен массив шрифта? Разбор текста завсегда выполняется ф-цией printf, в стандартном или облегченном её варианте. В эту ф-цию вмонтирован вызов ф-ции поиска символа в шрифте, эта ф-ция отыскивает начало блока данных символа и передает указатель на начало.
Геометрические фигуры часто рисуются с помощью ф-ции SetPoint(x, y), где координаты очередной точки - есть функция, описывающая геометрическую фигуру.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 21:05 
Старожил

Зарегистрирован: 08 авг 2013, 09:43
Сообщения: 2874
BusMaster писал(а):
Один раз делается инит дисплея, один раз запускается поток и затем спокойно заполняется буфер. Любые изменения в буфере будут отражены на дисплее без лишних телодвижений и в любой момент.

Если я правильно помню специфику SSD1306, тогда изображение будет накладываться друг на друга. У них вроде свой буффер и его надо обнулять, если надо перерисовать экран. Что в общем-то не мешает использовать DMA, тем не менее.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 21:32 
Старожил

Зарегистрирован: 27 апр 2013, 13:53
Сообщения: 1394
Такое встретилось и без буфера для изображения.
MSP430: Драйвер OLED 128x64 SSD1306


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 21:39 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Чуваки, тише, тише, ничего никуда не будет накладываться. Ну блин, у меня же работает, блин, в полсотне мелких проектиков эти экранчики запустил по DMA без вопросов.
Тут беда не стоит и выведенного яйца, как говорит пословица. То есть, это такая мелочь, что тьфу-говно-вопрос! :))) После подачи команд инита и запуска дисплея переводим в режим DMA SPI и забиваем вообще на любые проблемы, связанные с функлицированием SPI. Возвращаемся к ним только когда надо изменить яркость дисплея или выключить его. А в остальном - буфер из ОЗУ МК напрямую транслируется в дисплей силами DMA-SPI.
Кстати, SSD1306 (1309) имеет команды прокрутки выделенной области дисплея. В SH1106 этого нет, он существенно упрощен, а еще в нем нет своего готового DC/DC, из-за чего приходится городить на плате фигню.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 21:57 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
Я одно время шрифтами и графикой пострадал, очень уж было интересно самому разобраться :)


Вложения:
Кириллица.jpg
Кириллица.jpg [ 95.39 Кб | Просмотров: 8116 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 21:59 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
В тему шрифтов :)
https://www.youtube.com/watch?v=3N4fXRm_Dic


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 28 мар 2018, 22:19 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Как показывает практика, и особенно на мелких дисплеях, "миленькие шрифты" грозят нечитабельностью и невпихуемостью нужного числа символов.

По поводу видоса и Джобса со своими "шрифтами" - блин, ну это говорит лишь о том, что руководитель, распинаясь в словоблудии, банально не сумел поставить задачу с самого начала, не сумел сразу написать пунктики 1) 2 ) 3) 4). Я не являюсь поклонником Эппла с айфонами, поэтому подобные видосики воспринимаю с насмешкой. Вообще, сам видосик - насмешка над Джобсом - мол, чувак, ну ты бля ваще - постоить дом без дверей. Это как раз в стиле "креативных манагеров". Он должен быть уволить сам себя.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 29 мар 2018, 00:48 
Старожил
Аватара пользователя

Зарегистрирован: 28 дек 2016, 00:04
Сообщения: 264
Откуда: Россия, Москва
BusMaster. Спасибо за конструктивную критику. Отсутствие DMA объясняется тем, что с STM32 я работаю пару месяцев и исключительно в качестве хобби, параллельно ботая FPGA (моя работа с электроникой и микроконтроллерами вообще не связана). Поэтому DMA попросту не успел осилить. В TODO себе добавил.

_________________
https://eax.me/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 29 мар 2018, 01:52 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
afiskon
Драйвер дисплея должен эмулировать линейное пространство экрана. Совершенно не важно какой тип экрана: символьный, пассивный жк, активная матрица или даже электронная бумага. Так-же как размеры, глубина цвета и время реакции. Всё должно сводится к линейной памяти - в которую можно "рисовать" символы и графику.

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


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

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 30 мар 2018, 17:57 
Старожил
Аватара пользователя

Зарегистрирован: 28 дек 2016, 00:04
Сообщения: 264
Откуда: Россия, Москва
AVI-crak, звучит, как неплохая идея. Только я не совсем понимаю одну вещь. Что делать, если со сменой акцента меняется разрешение экрана и количество отображаемых им цветов (уж не говоря о переходе с графического экранчика на текстовый)?

Я не очень представляю себе отображение пространства экрана на память при котором в этом случае не пришлось бы переписывать код. Разве что забить на эффективность, используя самое жирное разрешение и политру, какую сможем. Но разве в этом случае картинка не будет на всех экранчиках одинаково плохой?

_________________
https://eax.me/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 30 мар 2018, 21:27 
Старожил
Аватара пользователя

Зарегистрирован: 23 сен 2012, 20:35
Сообщения: 2471
afiskon писал(а):
Я не очень представляю себе отображение пространства экрана на память при котором в этом случае не пришлось бы переписывать код.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 30 мар 2018, 22:29 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Я бы все-таки не стал бы слишком универсалить. В конце концов, это просто излишние операции. Тем более, на начальном этапе один хрен будет сто раз переписываться графическая составляющая в поисках наиболее удобного (правильного, читаемого, интересного, и тп.) варианта.
Например я не мешаю в одну кучу все дисплеи сразу. Ибо монохромные дисплеи часто (почти всегда) имеют упакованное в байт представление пикселей. И там нет градаций яркости, нет возможности смешивания цветов, все эти параметры просто лишние.
У цветных TFT-дисплеев другие особенности. К тому же, при работе с некоторыми МК, из-за их аппаратных возможностей появляется несколько другой подход, и графическую библиотеку приходится переписывать именно под эти аппаратные возможности. Даже банальный пример - рисование залитого прямоугольника - универсальный подход будет проигрывать в быстродействии на некоторых типах МК. В тот же ряд становится и декодирование bmp-картинок. Даже программно - и то у вас появляется еще один параметр смешивания - альфа прозрачности. Для монохромных дисплеев без градаций серого он излишний.

Вобщем, я - противник универсального подхода ко всем существующим дисплеям. Практика показала, что не стоит стремиться написать один раз и на все случаи. Чем меньше лишних параметров у вас будет в конкретном случае, тем более оптимально и быстрее будет работать этот конкретный случай.
Да и пока вы только учитесь, тренируетесь, вам не под силу охватить сразу всё. И чем меньше вы универсалите, тем проще вам разобраться с конкретно вашим примером. В процессе нарабатывания опыта вы сами начнете понимать, где проходит граница общих методов, и где начинаются различия по частностям.

Конкретно, что касается именно SSD1306 и растровых шрифтов. Тут вот какая фишка. Дисплей требует информацию вводить в виде упакованных по 8 пикселей байтов, постранично. Логично, что вы и будете иметь буфер дисплея именно в этом упакованном формате, ведь так он занимает в 8 раз меньше места в ОЗУ. Такие дисплеи ведь ставятся на маленькие МК, и не от хорошей жизни.
С другой стороны, растровые монохромные шрифты так же хранятся в таком же упакованном формате. И тоже логично, что вы этот шрифт не будете сначала распаковывать, а потом перепаковывать обратно. Вы просто возьмете массив шрифта и выведете его как есть, сдвинув байты в координаты вывода.
И иной подход у вас будет при выводе шрифта на цветной дисплей. Совершенно иной! Мало того, что вы распакуете байт шрифта, так вы еще и прогоните его через программное наложение цвета. Или через аппаратный модуль наложения с автоматической конвертацией цветового пространства, то есть с автоматическим закрашиванием и наложением с заданным соотношением прозрачности. То есть у вас будет совершенно разная middleware-часть.
Такие вот дела!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 31 мар 2018, 04:42 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
У меня все графические команды и вывод текста работают через функции SetPixel, ClrPixel. Изменив их для конкретного дисплея и/или платформы, больше ничего менять не надо. Но насколько я понял, это довольно простой вариант, где универсализация возможна.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 31 мар 2018, 04:44 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
BusMaster писал(а):
Как показывает практика, и особенно на мелких дисплеях, "миленькие шрифты" грозят нечитабельностью и невпихуемостью нужного числа символов.

По поводу видоса и Джобса со своими "шрифтами" - блин, ну это говорит лишь о том, что руководитель, распинаясь в словоблудии, банально не сумел поставить задачу с самого начала, не сумел сразу написать пунктики 1) 2 ) 3) 4). Я не являюсь поклонником Эппла с айфонами, поэтому подобные видосики воспринимаю с насмешкой. Вообще, сам видосик - насмешка над Джобсом - мол, чувак, ну ты бля ваще - постоить дом без дверей. Это как раз в стиле "креативных манагеров". Он должен быть уволить сам себя.

Не,не, я и сам когда только посмотрел фильм, считал Джобса дебилом. А потом меня чего то на сыром девайсе, имея гораздо более важные дела, торкнуло почему то шрифтами :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 31 мар 2018, 07:14 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
afiskon писал(а):
Только я не совсем понимаю одну вещь. Что делать, если со сменой акцента меняется разрешение экрана и количество отображаемых им цветов (уж не говоря о переходе с графического экранчика на текстовый)?

Все очень просто, это нижний уровень драйвера - его придётся переписывать под новый экран.
А для того чтобы свести всё это безобразие к линейной памяти - необходимо два слоя совместить по параметрам функций, проще говоря - написать свой маленький стандарт.
+ общая структура - которая будет описывать параметры дисплея как линейную память. Это размер по вертикали и горизонту, глубина каждого цвета отдельно, текущая точка для печати/курсора/графики (на каждый слой), используемый в данный момент шрифт, его масштаб по вертикали-горизонту, цвет в полном формате rgb для нескольких слоёв, графическая функция выполняющаяся в данный момент (монорежим) - или список задач которые что-то рисуют прямо сейчас, и как это не странно - статус.
Выглядит жирно, но это минимум для комфортной работы.

Для драйвера уровня железа есть масса вариантов прикинуться линейной памятью. Тут даже можно организовать кеш для линейной записи через дма в случае совпадения направления закраски пикселей. Когда оно совпадёт по направлению (после второй записи) - сохранять данные в свой буфер на одну строчку, до смены направления или номера строки. А после пинать дма, и принимать новые данные во второй буфер. Тут точно так-же, если вторая запись попадает в линейную часть - то хаваем пока влезет, а если не - стоп машина, и пусть весь мир подождёт.

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

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

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

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 31 мар 2018, 08:34 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
AVI-crak писал(а):
свести всё это безобразие к линейной памяти - .

Для SSD1306- и KS0107-подобных дисплеев с упакованными пикселями - это не нужно. Зачем вам хранить в ОЗУ бесполезно в 8 раз больший размер буфера? Преобразуйте координаты из пространства X-Y в пространство С-P-S (колонка-страница-смещение в странице), то есть в то пространство, которое понимает дисплей и в каком виде он принимает инфу.

Для монохромных дисплеев не нужны никакие параметры цвета, глубины цвета и наложения цветов. Это лишние параметры, лишние вычисления, лишняя путаница и лишний объем кода. Никакой комфортной работы! это просто дикое нагромождение неиспользуемых параметров. В монохромном дисплее просто нет этого!
А при работе с цветным дисплеем опять же надо смотреть на возможности конкретного МК. Я уже писал об этом. Даже вывод растрового шрифта, особенно крупного размера, может быть ускорен в несколько раз за счет использования возможностей МК вместо программного универсального кода. Конкретно, там, где есть DMA2D, вывод и наложение символа шрифта с его помощью выполняется гораздо быстрее, чем при универсальном программном способе. Так же, при работе с DMA2D сам собой отпадает вопрос в конвертации разных цветовых моделей (к примеру, RGB565->RGB888, AL44->ARG8B888). Сам собой отпадает вопрос наложения нового изображения на предыдущее. Реализация "всплывающего окна" с помощью слоев LTDC выглядит совсем иначе, чем при программном универсальном алгоритме.

AVI-crak писал(а):
прикинуться линейной памятью. .

Что есть в вашем понимании "линейная память"???
Ясен пень, что видеобуфер в ОЗУ расположен последовательно с возрастанием адресов. Без разницы, будет это одномерный массив gram[100*200] или двухмерный массив gram[100][200], все равно массив расположится в адресном пространстве в одну линию от А до B. Но вы можете в процессе работы создать доп.переменные и преобразовать двухмерный массив в одномерный и наоборот.
Массив должен лежать в таком виде, в котором его забирает дисплей, и без доп.преобразований. Тогда вывод на дисплей будет наиболее быстрым и независимым от кода. Просто потому, что эту работу возьмет на себя DMA или LTDC.

AVI-crak писал(а):
. Ну например не печатать символ за границей экрана (размер и позиция известны), автоматически переводить на новую позицию и строку. .

По опыту скажу, что это почти никогда не нужно. Вы сами подумайте, как будет работать эта фича.
Вложение:
Без-имени-1.jpg
Без-имени-1.jpg [ 31.69 Кб | Просмотров: 7323 ]

Это я к тому, что этот ваш автоматический перенос текста нужен только в том случае, когда вы выводите неизвестный текст из каких-нибудь файлов или входного потока. И алгоритм переноса должен быть пословным. И особенно сложно это будет реализовываться при использовании пропорциональных шрифтов, у которых разная ширина символа, в зависимости от символа. То есть, вначале, еще перед выводом слова вы должны просчитать суммарную длину слова, просмотрев параметры (ширину) каждого входящего в слово символа и суммировав её (ширину), затем сравнить ширину слова с оставшимся до конца видимой области дисплея, и принять решение о переносе всего слова. Более сложные алгоритмы с учетом орфографических правил переноса слов - это уже ну ващееее. Короче, эта задача уже конкретная и вталкивать ее в универсальный код бессмысленно.

По теме Стива Джобса - он прав в том, что чисто визуально шрифты как раз и определяют привлекательность и прочие визуальные характеристики. Однако, визуальная привлекательность - это дело не программиста, а дизайнера, или руководителя. Ошибка Джобса была в том, что он, как руководитель, тупо "проебал вспышку". Это чисто его косяк. Ведущему программисту как-то похрен на "миленький шрифтик". Джобс должен был нанять дизайнера и спрашивать с него за "миленькость". А раз он не сделал ни одного, ни другого, то и должен был уволить сам себя, за свой недосмотр.
Хотя, сейчас просто невозможно заходить на сайт Эппла. Это ужас! Шрифты ОГРОМНОГО размера, просто дикого! На моем 23" монике это выглядит просто взрывомозговыносительно! Мне хочется отбежать от моника метров на 5 или уменьшить масштаб на тыщщу процентов. Всё какое-то гигантское, топорное, неприятное.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 31 мар 2018, 22:59 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
BusMaster - мне интересно как вы работаете с DMA2D - неужели прямыми командами??? Ещё наверное адреса с ручным заполнением... С таким подходом представление графики в виде линейной памяти действительно не нужно. Это почти как на ассемблере писать. И кстати не слишком далеко от аурдинщиков.
А теперь попробуй перенести всю графику на немощный f030... Я знаю реплику, типа памяти не хватит, скорости и вообще это не для этого. Но я могу перенести графику, а у тебя этого не получится, в этом вся разница.

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 31 мар 2018, 23:16 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
А что, надо работать изогнутыми непрямыми командами? У DMA2D вообще нет команд, если чо. Но bmp он декодирует в десятки раз быстрее программной писанины, и способен даже автоматически загрузить CLUT и конвертировать цвета. Адреса всех параметров и начала всех блоков записаны в самом bmp-формате.
К F030 мало кто станет прикручивать большой полноцветный дисплей, там достаточно и вот такого SSD1306. А перегружать F030 лишней фигней универсальных ф-ций с параметрами наложения цвета - да это дурь какая-то. Да, это банально неумение мыслить и писать.
Чо это у меня не получится перенести графику? Слухай, чувак, епт, у меня прекрасно все работает, как на F030 с SSD1306, так и на H753 c дисплеем 1024х768. В этом вся разница. Чувак, у меня давно уже отработанные методы, оптимизированные под конкретные задачи. Посему моя графика работает быстрее, чем твоя, черт знает сколько хлама содержащая.

Кста, ты так и не рассказал, что ты понимаешь под "линейной памятью"??? Блин, чувак, прежде чем придумывать какие-то термины, ты бы хоть пораскинул мозгами, посоображал бы, как байты хранятся в ОЗУ МК, в каком порядке идут, как хранятся массивы, ну и тп.
Ты вообще походу перепутал всё и вся. Ардуинщики не пишут на ассемблере. Ассемблер - это самый низкоуровневый язык, ниже - только машинные коды. А где ты видел ардуинщика, пишушего на низкоуровневом языке? Ой, кароче, не пори чушь на ночь глядя, а...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 01 апр 2018, 13:53 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1268
BusMaster писал(а):
К F030 мало кто станет прикручивать большой полноцветный дисплей, там достаточно и вот такого SSD1306.

Зайди на ali, поищи экраны 320x480, из самых дешевых большинство заточено для использования с ардуиной :) Я цеплял к F0 экранчик 240x320 с тачем, за 3$, ставить вместо него чб 128x64 за 2.5$ имеет смысл только если важно потребление. А вот LTDC и DMA2D среди любителей редко используются, соответственно буферы в памяти также достаточно редкое явление. SSD1306 не в счет, ему нужно всего 1КБ...

Цитата:
Кста, ты так и не рассказал, что ты понимаешь под "линейной памятью"???

Скажу за себя, у меня есть 5 разных цветных экранов, от 160x128x8, до 320x480x16. Чтобы вывести точку в произвольном месте на части из них нужно задать окно целиком, на других нужно задать две координаты внутри уже существующего окна, а на некоторых достаточно поменять одну координату, если вторая не меняется. В целях унификации при изменении координат в библиотеке всегда задается окно и внутри него идет вывод слева направо и сверху вниз, какая бы из 4-х ориентаций не была выбрана при инициализации. Нельзя писать в произвольное место этого окна, но если выводить данные последовательно, то по сути можно говорить о неком аналоге "линейной памяти". Сама унификация практически бесплатна, т.к. при заливке прямоугольных областей, выводе картинок или шрифтов окно задается лишь один раз, дальше просто гонятся сырые данные, хоть при помощи DMA.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 01 апр 2018, 14:50 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
У ЛЮБИТЕЛЕЙ может и редко LTDC используется, поскольку ЛЮБИТЕЛИ чаще всего тупо ниасиливают даже через Куб, уже не говоря о том, чтобы разводить на плате много дорожек да еще и крутить рядом SDRAM.
А про DMA2D я всегда привожу пример на из отладочной платы STM32F469I-DISCO, в которую с завода залита демка, где показывается наглядно в сравнении работа с программной графикой и с ускорителем DMA2D. Результат, как говорится, очевиден.
Согласен, что ЛЮБИТЕЛИ редко доходят до такого, им проще мудохаться экранчиком 320х240 в текстовом режиме.

Про определение "линейной памяти" от AVI-crak вообще ничего не понятно. Это какое-то новое слово в эмбедде.
Массив любой размерности, будь то одномерный или двухмерный, располагается в памяти МК линейно, байт за байтом, строка за строкой, без разрывов.
Если дисплей, подобно ILI9341, имеет возможность вывода в пределах заданного ранее окна, не затрагивая весь экран, то и буфер вывода будет определяться строго размерами этого окна. Потому что если бы была возможность хранить буфер на полный размер дисплея 240х320, тогда не надо было бы и извращаться с выводом маленького окна. Как бы вот.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 01 апр 2018, 16:39 
Старожил
Аватара пользователя

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
BusMaster писал(а):
Кста, ты так и не рассказал, что ты понимаешь под "линейной памятью"???

Возможность "печатать" или рисовать графический символ в произвольное место оперативной памяти, а также переносить эти данные (по сути линейный массив) в видимую область экрана.
Для экранов с собственной памятью и ограниченными ресурсами мк - это задание окна для копирования или чтения данных посредством дма. Для экранов без памяти - прямая "печать" в экранную область внешней памяти, или в произвольную область основной памяти с последующим применением dma2d (то самое окно).

В любом случае вся графическая часть будет обращаться к физическому драйверу через две очень простых функции чтения/записи. Буквально: rgb прочитать (x,y), записать (x,y,rgb). Этого достаточно чтобы разделить программный и аппаратный уровень. Важно иметь одинаковую декларацию для этих простых функций во всех своих проектах. Можно использовать их как обёртки, можно переписывать саму функцию - главное чтобы декларация не менялась в названии и параметрах. А для того чтобы физический драйвер понимал куда необходимо писать или читать - потребуется та самая жирная структура что я описал выше.

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

А вот если для того-же проекта использовать прямое обращение к жк экрану или регистрам dma2d - то незначительное затруднение превращается в бесконечный марафон боли и страданий.

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 01 апр 2018, 17:30 
Старожил

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
погоди, давай разберемся. Что такое "возможность рисовать символ в произвольное место оперативной памяти" и как это связано с определением "линейная память"?? Нет, ну серьезно же. Мне так сильно чето кажется, что ты банально слишком всё позапутал в терминах. Хотя идеологически правильно - да, в ОЗУ отражается либо полный размер дисплея (240х320 точек), либо его часть, определенная окном вывода. Но согласись, само слово "линейная" тут как бы вообще не при делах.
DMA2D работает совсем не так, как область (окно) вывода в ILI9341. Тут это как бы долго объяснять. DMA2D работает не "после", а "перед". Он является "смесителем" и "заполнителем" прямоугольных областей, с автоматическим конвертированием цветовой модели (формат пикселя, по терминологии СТМ), и результат своих действий он помещает как раз в эту самую ОЗУ, в буфер, из которого забирается картинка в дисплей.

Я вот про что говорю - для монохромного дисплея без градаций серого совсем не нужны операнды R, G, B, это излишне! лишние операции, лишняя память, лишние действия. Это просто лишнее. Кстати, ты забыл еще один параметр - способ наложения. Ведь могут быть случаи, когда нужна полупрозрачность, суммирование, вычитание, инверсия. Если уж ратуешь за универсальность, чё ж не добавил таких фич?

Понимаешь, написать драйвер для монохромного дисплея - это как два пальца об асфальт, то есть, очень простая задача. Лично я могу с нуля написать драйвер для WG12232, при этом даже не вспотею.
Вообще же, строго говоря, драйвер дисплея определяет лишь взаимодействие с дисплеем, а графика относится к более высокому, среднему уровню. Причем, графика делится на векторную и растровую. И рисовать растровый шрифт или растровую картинку с помощью векторных ф-ций - это излишняя потеря скорости. Это не просто слова, чувак, это испытано на практике лично. Да ты и сам можешь убедиться, если дотянешь мозгами.

AVI-crak писал(а):
использовать прямое обращение к жк экрану или регистрам dma2d - то незначительное затруднение превращается в бесконечный марафон боли и страданий.

НИКАКОЙ БОЛИ, НИКАКИХ СТРАДАНИЙ! Ты просто не умеешь это использовать, чувак. Так бы и сказал, что банально ниасилил тему. Впрочем, эта тема дается далеко не всем.
Но всё отлично там работает. И освоив эту тему, получим графику, практически на порядок превосходящую по скорости. Я уже писал, что как где почему и насколько. Могу показать примеры, но это много букав будет.
DMA2D может работать вообще без экрана. Абстрактно. Он не выводит ничего на дисплей. Он кладет результат в такую же ОЗУ, внутреннюю или внешнюю. На дисплей выводит уже другой модуль - будь то LTDC или SPI или FSMC.
Тем более, ты не учитываешь нюансов. Это хорошо, когда всё просто и примитивно. А подумай, когда у тебя дисплей в формате RGB888, а bmp-картинка лежит в ARGB1555. Программно конвертировать? Программно - там где нет DMA2D. И автоматически - там, где есть DMA2D. Так сравни скорости работы и размеры кода! Разница на порядок, если не больше! С помощью DMA2D ты автоматически решаешь вопрос как конвертации цвета, так и вписывания прямоугольной картинки в заданные координаты вывода, без программного отслеживания в циклах for-for. Хотя сам DMA2D весьма примитивен, его возможности небольшие, но даже их ты ниасилил.
Нет никакой нужны писать универсальных библиотек и ебаться потом со скоростью и неоптимальностью. Надо использовать все предоставляемые "железом" возможности, на то ты и посажен программистом, а не хуём с горы.

Вобщем, чувак, не надо неумение мыслить и лаконично писать выдавать за how-to, ибо это херня и жопа. А то, что ты испытываешь затруднение с внятным мЫшлением - это уже и без того понятно. Чего только стоит эта твоя "линейная память", в которой слово "линейная" вообще с херовой горы.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 48 ]  На страницу 1, 2  След.


Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB