Easyelectronics.ru

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

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



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

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

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
Всё верно, я не осилил ручное заполнение функции для dma2d. Которое имеет зависимость от размеров используемого экрана, позиции экранной области и её размеров, а так-же глубины используемого цвета и его прозрачности. Для меня это дикий овердрайв, плавно переходящий в неизлечимое заболевание глаз. Точно так-же как ручное заполнение функции задания окна для жк имеющего память.
Это-же дикость, зачем это всё осиливать, и героически побеждать? Через день смениться физический экран - и опять переписывать функции для 100500 сцен???
Я говорил о структуре для физики жк экрана, но не упоминал о том что эта структура должна быть полностью видна со стороны графической части. Структура предназначена прежде всего для физики, именно от туда берутся все переменные для работы физического драйвера. И естественно для символьного экрана эта структура будет намного проще.

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

_________________
Потоковая OS


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

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Еще раз спрашиваю - что ты понимаешь под "линейной памятью"??
А теперь добавилась еще какая-то "структура для физики".. Что такое "структура" в твоем понимании?
И дисплей не меняется через день. Даже тот же самый ILI9341 может работать как со своей внутренней памятью, так и в режиме RGB без использования своей памяти. А заменив цветной 320х240 на монохромный 128х64 ты всё равно будешь ПОЛНОСТЬЮ переписывать все экраны - банально не влезет по размеру.
В монохромном дисплее нет цветов, значит и не нужны параметры цвета. Ну это же так просто и так очевидно, черт возьми! Как, КАК это можно не видеть? Как можно не соображать, чтобы не суметь убрать лишние аргументы, вот как это так тупить? Не знаю...
Ты пишешь о "структуре для физики экрана" и почему то не различаешь разную "физику" у монохромного и цветного дисплея, разное количество бит на пиксель. КАК это так? Ну как? Как у тебя появляется аргументы цвета RGB для монохромного дисплея с одним битом на пиксель? Ну как это???

Еще раз повторяю - блин, чувак, если ты не в теме, не выдавай заведомо неправильную инфу. У тебя же все смешалось, даже в пределах одного поста. ОС вообще никак не мешает графике, ей вообще начхать. Запусти графику в отдельном процессе, разграничь доступ мьютексами - и никакой разницы не будет. Прозрачность при наложении лучше всего работает на LTDC и (или) DMA2D. Хотя можно и программно, но это в десять раз медленнее. Да так и делают там, где нет аппаратных возможностей. Но если они есть - то почему не использовать их? Никаких там сложностей и ужасов нету, всё прекрасно работает. А башка тебе на то и дана, чтобы ты не только жрал в неё.

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

Кароче, чувак... Не умеешь в воду пердеть - нехрен рыб пугать. (С)Народная мудрость.


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

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1268
AVI-crak писал(а):
Конечно, рисовать сразу в физический экран это круто, и ощущается локальным достижением. До тех самых пор пока нет ос, не задействовано дма (даже самое простое), и не требуется использование прозрачности.

Если вернуться к F030, у которого всего 8КБ RAM, то какого размера будут буферы для экрана 240x320? Допустим хочу я линию нарисовать, (0,0) - (90,90), линейный буфер под это дело больше всей RAM имеющейся в наличии, что будет происходить? А если вдобавок экран подключен по 8-ми битной шине, т.к. такой дисплей с тачем дешевле SPI-го без тача? DMA ведь в таком случае практически бесполезен...


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

Зарегистрирован: 18 май 2013, 20:43
Сообщения: 4904
Откуда: Кемеровская область, Киселевск
Ну дма лишь трансфер уменьшает транзакции и ускоряет вывод. Можно на мелкие блоки разбивать и обрабатывать, а выгружать через дма. Обработка в ОЗУ быстрее + параллельно можно заниматься. Дело в том что работая просто со SPI через регистр с помощью CPU это медленнее намного, мало того что вы загрузите CPU, так у вас еще и DMA будет простаивать. Дабы уменьшить вычисления, можно картинку запилить во флеш которая слишком часто нужна для вывода на экран и ее сливать через дма. Есть такая техника как применялась в 8 битных консолях, игры состояли из маленьких блоков. Так вот DMA умеет перетаскивать такие блоки в дисплей просто изумительно быстро. Именно такая техника у меня используется в плеере. Иконки, графика блочная. Текст я тоже буферизирую в ОЗУ и готовый блок символа DMA перетаскивает на экран.
Вложение:
4efa200c25c1e26686349c9c99129af4.png
4efa200c25c1e26686349c9c99129af4.png [ 2.86 Кб | Просмотров: 2269 ]

_________________
RADIOWOLF.RU


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

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
Reflector писал(а):
AVI-crak писал(а):
Конечно, рисовать сразу в физический экран это круто, и ощущается локальным достижением. До тех самых пор пока нет ос, не задействовано дма (даже самое простое), и не требуется использование прозрачности.

Если вернуться к F030, у которого всего 8КБ RAM, то какого размера будут буферы для экрана 240x320? Допустим хочу я линию нарисовать, (0,0) - (90,90), линейный буфер под это дело больше всей RAM имеющейся в наличии, что будет происходить? А если вдобавок экран подключен по 8-ми битной шине, т.к. такой дисплей с тачем дешевле SPI-го без тача? DMA ведь в таком случае практически бесполезен...

Ничего страшного не произойдёт.
Я говорил о сохранении стандарта на декларацию функции, но само содержание функции полностью зависит от конкретного дисплея.
Допустим рисуем наклонную линию. Драйвер следит за последовательностью поступающих данных для записи. В том случае когда следующая точка находится чёт знает где, а не там где можно сохранить все данные в линейный массив - драйвер (случай с spi интерфейсом) собирает командный массив для записи одной цветной точки, и пинает дма.
В случае совпадения направления - данные сохраняются в память, это в нашем случае около 200 байт. До момента явного несовпадения, или перехода на новую строку, или наступил момент принудительного обновления экрана. Случай явного ногодрыга тоже может использовать dma, просто памяти под командный буфер понадобится намного больше, даже не на всю строку. Рисовать в память это многократно быстрее чем сразу в физический экран.

Даже для случая применения dma2d. Тут кстати можно вообще не заморачиваться с ручным высчитыванием границ, диапазонов и прочей фигни - просто тупо рисовать в нужный вам слой. Когда новая точка выйдет за размеры буфера, или наступит время принудительного обновления - драйвер сам пнёт dma2d, без внешней команды. Что может быть проще???

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

Повторюсь - основная графическая функция записи видит экранную область как линейную. Для неё есть х горизонтальных отчётов помноженные на y вертикальных. Чисто математически это от нуля до x[размер x] * y[размер y].
При этом гипотетически графическая функция может знать о размере по вертикали и горизонту, но это уже уровень адруино.
При смене ориентации дисплея - такая функция нарисует откровенный мусор. То-есть графической функции знать о реальных размерах дисплея не нужно и даже вредно. Это должен знать драйвер, который будет брать эти значения из своей структуры (мотай на предыдущую станицу).

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

Кстати, для любителей экономить - можете использовать типы uint_least(8-16-32)_t и int_least(8-16-32)_t из stdint.h .

_________________
Потоковая OS


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

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

Блин, черт возьми, да прочти ты уже мануал, а!
DMA2D НЕ ТАК РАБОТАЕТ! DMA2D не выводит буфер в дисплей. DMA2D, он же ускоритель Chrom-Art - это просто смешиватель, заливальщик и копировщик прямоугольных областей, с возможностью конвертации формата пикселя.

Вложение:
Без-имени-1.jpg
Без-имени-1.jpg [ 63.82 Кб | Просмотров: 2248 ]

Вложение:
Без-имени-2.jpg
Без-имени-2.jpg [ 79.29 Кб | Просмотров: 2248 ]


И САМЫЙ ГЛАВНЫЙ ВОПРОС ЭТОЙ ТЕМЫ - чувак, какой, к ебеням, DMA2D при работе с монохромным дисплеем SSD1306, который в заголовке темы???
Какая, к чертям, унификация, и какая, кхуям, "линейная память" у монохромного дисплея SSD1306 с постраничным упакованным в байты, вводом инфы?? Как ты выводить на дисплей будешь из твоей "линейной памяти", когда дисплей понимает только упакованный по 8 пикселей в один байт формат данных???
Мало того, что ты со своей "линейной памятью" аж в 8 раз раздул буфер дисплея, так ты еще и требуешь дополнительных ручных преобразований в драйвере, когда драйвер вручную будет упаковывать пиксели в байты. Ну это же жопа! И какой ценой!


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

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
BusMaster писал(а):
DMA2D НЕ ТАК РАБОТАЕТ! DMA2D не выводит буфер в дисплей.

В каком конкретном месте у тебя бомбит? конкретно строка моего сообщения где я вывожу изображение НА экран с помощью dma2d. Мне просто интересно, какая из моих фраз может иметь иное значение, чем то что задумал я.

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

_________________
Потоковая OS


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

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
Да у тебя каждая фраза имеет иное значение. Взять хотя бы эту твою "линейную память". Ты все-таки объяснишь внятно, что означает эта твоя "линейная память"?? Линейная, это как бы вроде в одну линию, байт за байтом. Так?
Вот смотри, вот два массива - одномерный и двухмерный. Они расположены в одну линию байт за байтом? Да или нет?
Вложение:
Без-имени-1.jpg
Без-имени-1.jpg [ 45.71 Кб | Просмотров: 2222 ]

А все потому, что организация адресного пространства в МК - линейна. Ячейка памяти задается одним адресом от начала, а не как в MS Excel - пересечением столбца и строки - A5 или R16.
Но когда работаешь с двухмерным дисплеем и с двухмерной графикой, то тут появляется ортогональная двухмерная система координат X-Y, и каждая точка задается пересечением координаты X и Y. Все дисплеи имеют счетчик строк и счетчик столбцов, в двухмерной ортогональной, а не линейной системе координат.
Но даже двухмерный массив в памяти МК лежит и адресуется в одномерной линейной плоскости. Во внешней SDRAM есть разбиение на строки, столбцы и банки, но благодаря модулю FMC адресное пространство остается таким же одномерным, в одну линию. Поэтому просто нет речи о чем-то другом, и это определение "линейной памяти" так же бессмысленно, как и "мокрая вода" или "соленая соль". Но применительно к двухмерной графике в ортогональной системе - понятие "линейная" опять же бессмысленно, поскольку это противоречит двухмерной плоскости X-Y. Это же школьный курс геометрии! Уравнение прямой y = (2*x)+5 - тут выражение координаты Y через координату X.

Вот в чем фишка то... Беда в том, что AVI-crak не умеет оперировать понятиями и не понимает смысла написанных им же самим фраз.


Последний раз редактировалось BusMaster 02 апр 2018, 00:09, всего редактировалось 1 раз.

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

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1268
AVI-crak писал(а):
Я говорил о сохранении стандарта на декларацию функции, но само содержание функции полностью зависит от конкретного дисплея.
Допустим рисуем наклонную линию. Драйвер следит за последовательностью поступающих данных для записи. В том случае когда следующая точка находится чёт знает где, а не там где можно сохранить все данные в линейный массив - драйвер (случай с spi интерфейсом) собирает командный массив для записи одной цветной точки, и пинает дма.
В случае совпадения направления - данные сохраняются в память, это в нашем случае около 200 байт. До момента явного несовпадения, или перехода на новую строку, или наступил момент принудительного обновления экрана. Случай явного ногодрыга тоже может использовать dma, просто памяти под командный буфер понадобится намного больше, даже не на всю строку. Рисовать в память это многократно быстрее чем сразу в физический экран.

200 байт - это 100 точек в линию по горизонтали или по любой из осей? Драйвер поймет, что линия из 100 вертикальных точек - это те же 200 байт, если окну сделать ширину 1, или воспримет их как 100 отдельных точек, по одной на каждой линии? В любом случае у моей диагональной линии каждая точка смещена на 1 по обоим осям, потому это 100 отдельных точек как ни посмотри... Заменив непосредственную отрисовку записью в буфер, который потом будет опять разобран на точки, мы просто потерям время. С выводом шрифтов, которые представляют собой множество мелких отрезков, вероятно будет то же самое...

Цитата:
Даже для случая применения dma2d. Тут кстати можно вообще не заморачиваться с ручным высчитыванием границ, диапазонов и прочей фигни - просто тупо рисовать в нужный вам слой. Когда новая точка выйдет за размеры буфера, или наступит время принудительного обновления - драйвер сам пнёт dma2d, без внешней команды. Что может быть проще???

DMA2D - это отдельная тема, там без буфера всего экрана в памяти ловить особо нечего. Хотя можно и к FMC прикрутить, брать 4-8-ми битный цвет и преобразовывать в 16-ти битный.

Цитата:
О том как написать такой драйвер - отдельная песня.
Думаю у вас ничего не получится. До тех пор пока не пропадёт явное сопротивление наличия в проекте структуры, которая будет описывать все физические свойства экрана и его слоёв.

Чтобы пропало сопротивление нужно сначала увидеть, что другой подход привносит заметные улучшения. Пока я вижу, что он сложнее, в случае дисплеев с параллельным интерфейсом в связке с мк без FSMC еще и точно медленнее, остальное под вопросом :)


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

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
BusMaster писал(а):
Но применительно к двухмерной графике в ортогональной системе - понятие "линейная" опять же бессмысленно, поскольку это противоречит двухмерной плоскости X-Y. Это же школьный курс геометрии! Уравнение прямой y = (2*x)+5 - тут выражение координаты Y через координату X.


Это действительно не имеет смысла пока нулевая точка экрана X,Y находится где-то в оперативной памяти (который нужно помнить и применять в расчётах), или на внешнем девайсе через набор периферийных узлов. Когда ваша функции печати символов и графики напрямую обращается к экрану или его выделенной памяти.
Все смещения, промежуточные команды и константы можно и нужно оставить драйверу. Пусть он пыхтит и вычисляет. А на вход ему подавать те самые целые беззнаковые числа значений X и Y.
Вот только тогда уравнение y = (2*x)+5 можно применить к известному диапазону Х. Тогда функция печати символов и графики станет переносимой между разными мк и жк экранами.
Считается ли это линейным хранением информации - да.
Потому-что те значения что не попали в функцию y = (2*x)+5 - должны остаться первоначального цвета, их нельзя выбрасывать. Если просто взять двухмерный массив и заполнить его по этой формуле - то его можно перенести с помощью дма в экранную область жк экранчика. Да это очень жирно, но для примера подойдёт.

Это означает возможность автоматического использования дма в случае совпадения направления закраски пикселей - даже для самых маленьких мк. Так-же как и другой доступной периферии в конкретном железе.

Reflector писал(а):
200 байт - это 100 точек в линию по горизонтали или по любой из осей?

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

Reflector писал(а):
Чтобы пропало сопротивление нужно сначала увидеть, что другой подход привносит заметные улучшения.
Да не вопрос - STemWin, uGFX, и наверное emWin.
Имеет смысл посмотреть ролики на ютюбе, перед тем как скачивать.
Дело в том что любая графическая библиотека на 100% не имеет совместимости с вашим железом. Там отличие в подключении буквально одной свободной ноги мк - моментально даёт косяк в непредсказуемом месте.
По этой причине стоит поступить подло - использовать библиотечные графические функции как есть (они легко переносятся), а физический драйвер написать самому. Ну то-есть выбросить все эти заботливо скомпилированные библиотеки нафиг.

_________________
Потоковая OS


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

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1268
AVI-crak писал(а):
Это не горизонталь и не вертикаль, это просто массив в который может поместиться окно экранной области. Тут даже количество байт не важно, главное чтобы размеры буфера позволяли его применение в конкретном мк. А так-же количество требуемых байт для закраски окна экранной области было меньше или равно размеру буфера.

Похоже я еще больше запутался :) Еще раз, с начала... Экран 240*320 требует 150КБ под буфер, если мы хотим перекрыть всю его площадь, потому учитывая количество памяти доступное у F0, можно рассчитывать на 1/30 от этого объема. Для вывода одной точки нужно отправить на экран 2 байта, но если предварительно необходимо задать координаты, то в худшем случае, для дисплеев где для этого приходится задавать окно целиком, добавится еще полтора десятка байт. Если есть строго горизонтальная линия длиной 90 точек и дисплей автоматически инкрементит адрес по горизонтали слева направо, то достаточно задать окно и вывести эти данные цветов, итого получаем примерно 90 * 2 + ~14 байт. Для вертикальной линии получаем то же самое, если у окна будет ширина равная 1, то получим инкремент по вертикали и такое же общее число байт. В случае же диагональной линии(45гр), где наблюдается смещение по обоим осям, придется задавать окно для каждой точки и общее число байт увеличится в 7.4 раза. Это если отсылать данные сразу на дисплей, без буферов, а понять я хочу что будет если такие линии отрисовать в буфере... Для начала интересно что в буфере находится до начала отрисовки? Он пустой или туда предварительно читаются данные с экрана? Медленно прочитал, быстро в буфере нарисовал диагональ, медленно вывел весь буфер обратно? Или буфер пуст, там рисуется линия и потом точки как-то собираются в группы отрисовки? Может в буфере не сами точки, а команды? Не похоже, ты говорил, что буквально есть две функции записи и чтения по заданным координатам... Итого мало что понятно, т.е. как-то реализовать это все конечно можно, но эффективность под большим вопросом.


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

Зарегистрирован: 18 май 2013, 20:43
Сообщения: 4904
Откуда: Кемеровская область, Киселевск
Встречный вопрос про линию по диагонали. Линия накладывается на текущий буфер который в дисплее? Если требуется сохранить буфер, придется попиксельно выводить в свои координаты. Просто еще D/C пин есть, он тормозит вывод.
Обычно всякие диагональные линии рисуются какими то специфичными приложениями. Там обычно идет своя оптимизация уже.
Установка пиксела требует 11 байт на установку координат и 2 байта цвет, это я говорю про дисплей SPI ILI9341 240*320

2A COLUMN - 4байта
2B PAGE - 4 байта
2С COLOR - 2 байта
-------------
13 байт + нужно дергать D/C

Поэтому попиксельный вывод это огромный тормоз.

_________________
RADIOWOLF.RU


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

Зарегистрирован: 22 июл 2017, 11:48
Сообщения: 4198
Откуда: Чобля - долбаный кетайец
AVI-crak, походу, не только сам запутался, но и всех уже запутал к чертям со своей "линейной памятью". "Линейное уравнение" и "линейная память" - это не родственные понятия. Линейное уравнение - это описание прямой линии вида ax+by+c=0, а линейная память - это память с единым возрастающим адресом, от начала и до конца. Применителтно к СТМ память линейная всегда. Я показывал картинку.

Теперь уже не понятно, то ли буфер кадра должен лежать в ОЗУ МК, то ли он должен быть в самом дисплее. Хер пойми. Вобщем, AVI-crak, если бы ты поменьше болтал, да побольше работал, ты бы сам понял, что и как.
И не забывайте, что основное название именно ЭТОЙ темы - ...для экранчиков на базе SSD1306


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

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1268
Oxford писал(а):
Обычно всякие диагональные линии рисуются какими то специфичными приложениями. Там обычно идет своя оптимизация уже.

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


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

Зарегистрирован: 09 янв 2013, 21:54
Сообщения: 102
Откуда: Челябинск
Reflector писал(а):
допустим лежит во флеше картинка в готовом виде, я могу задать для экрана окно такого же размера, натравить на нее DMA и нарисовать

Если картинку надо вывести на краю экрана и часть её выходит за пределы, DMA тоже ведь не применить?


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

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 1268
Rius писал(а):
Если картинку надо вывести на краю экрана и часть её выходит за пределы, DMA тоже ведь не применить?

Смотря за какие пределы, если сверху или снизу, а картинка выводится по горизонтали, то можно.


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

Зарегистрирован: 09 янв 2013, 21:54
Сообщения: 102
Откуда: Челябинск
Хм... Взять только участок данных картинки вместо полной. Да, можно. Спасибо.


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

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


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

Зарегистрирован: 27 мар 2015, 01:22
Сообщения: 1949
BusMaster писал(а):
И не забывайте, что основное название именно ЭТОЙ темы - ...для экранчиков на базе SSD1306

Давайте может и правда вернёмся к b/w дисплеям [т.е. с однобитным цветом]
Меня вот сильно интересуют библиотеки b/w виджетов, любые, хоть для мк, хоть для компа, но именно специально заточенные под b/w [ну и графические конечно, не псевдографика]
Кто-нибудь знает такие?


Вложения:
windows-1.png
windows-1.png [ 3.95 Кб | Просмотров: 1937 ]

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

Зарегистрирован: 30 мар 2015, 23:56
Сообщения: 832
Reflector писал(а):
И еще вопрос для AVI-crak, допустим лежит во флеше картинка в готовом виде, я могу задать для экрана окно такого же размера, натравить на нее DMA и нарисовать, но если между экраном находится еще какой-то менеджер принимающий по одной точке, то придется так по точке в буфер и копировать?

Это уже отдельная функция копирования данных, которая полностью зависит от используемого железа. Но декларация и в этом варианте может иметь стандарт. По сути это просто передача одного большого массива в ограниченную экранную область, то-есть для объявления достаточно: адрес отправителя, адрес получателя, и размер; ответ:статус операции.
Ничего не напоминает???

_________________
Потоковая OS


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Допилил библиотеку для экранчиков на базе SSD1306 (STM32)
СообщениеДобавлено: 03 фев 2020, 19:27 
Здравствуйте!

Зарегистрирован: 03 фев 2020, 19:22
Сообщения: 1
Ставлю жЫрный лайк! Нет ли в планах аналогичной библиотеки для PCD8544 по SPI?


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

Зарегистрирован: 01 фев 2013, 02:21
Сообщения: 333
Портируйте под свои мк и дисплеи - littlevgl.


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

Зарегистрирован: 02 май 2017, 18:54
Сообщения: 277
2: "BusMaster"

Чувак, семки есть?
(интонацию письмом передать сложно...)


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


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


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

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


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

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

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