[Levontay 0]

На сколько я понимаю - FSCM управляет дисплеем параллельно а SPI - последовательно, то-есть - туда сгружаются пикселы. Здесь не понятно - а чем занимается чип? Если провести аналогий с видеокартой - то ей подаётся команда (полигон) а она уже загружает в видеопамять пикселы. Я к тому - что, командное управление, по идее, должно-быть одинаковым при использовании дисплеев с разной разрешающей способностью. Если микроконтроллер (для примера STM32F303) хочет сгружать пикселы при большем разрешении - то ему - да, - надо будет расширять место в памяти и запаса по вычислительной мощи. А если управлять векторно? Прошу прояснить этот момент и сослать на инфу - где подобное описывается.

[AlanDrakes 1]

FSMC - "Гибкий контроллер статической памяти". И он фактически позволяет передавать данные по параллельному интерфейсу (i8080 и аналогичным в режиме "LCD/PSRAM").
Он позволяет передавать данные быстро. Грубая оценка - 4 такта процессора на 1/2/3 байта (в зависимости от ширины шины). А передача команды/данных осушествляется записью байта в разные адреса в памяти (не в RAM, а в адресном пространстве, которое отображено на память) в случае моего проекта это блок 0xC00xxxxx, а FSMC сам разбирается с таймингами пинов и установкой уровня на пине RS (данные/команда).

 

SPI интерфейс с другой стороны, это последовательная шина. У него ВСЕГДА шинита в 1 бит, плюс делитель периферии... итого скорость вывода байта в периферию около 32 тактов ЦП на 1 байт. Плюс, дополнительно нужно кодом программы управлять пином RS самостоятельно, выбирая, когда отправляется команда, а когда данные.

 

По поводу "векторного" управления - сильно не все LCD контроллеры позволяют отправлять команды отрисовки примитивов. Тот же широко распространённый ILI9431/ILI9325/ILI9488/RENESAS_R61580/ST7735 (список того, с чем я работал), умеют только доступ к памяти. Всё. Даже заливку прямоугольника не позволяют выполнить своими силами.

 

ИМХО: У себя максимально использую буферы экрана - это позволяет устранить мерцание при отрисовке. Хотя память кушает хорошо. Экран 320*240 требовал для себя 38400 байт (да, именно половину от своего разрешения). В этот буфер выполняется отрисовка интерфейса, данных и прочего, после чего его обрабатывает "ускоритель" DMA2D, который распаковывает пиксели из формата L4L4 в RGB565, которые затем отправляет через FMC в дисплей.

LCD_BUF[320*240/2];

PX[4bit] -> DMA2D ----unpack------LUT-----> RGB[16bit] ---> FMC ---2x8bit--> LCD

Изменено 4 мая, 2022 пользователем AlanDrakes

[Obam 30]

Здесь не понятно - а чем занимается чип?

Добавляя к вышесказаному: формирует эл. сигналы, управляющие ЖК-матрицей ("стеклом"), а их там ой много, ну и питание "стеклу" (~ 6 уровней).

ILI9431/ILI9325/ILI9488/RENESAS_R61580/ST7735 (список того, с чем я работал), умеют только доступ к памяти.

ну и можно задать область и выводить в (или читать из) неё "плоским" образом

[AlanDrakes 1]

8 часов назад, Obam сказал:

ну и можно задать область и выводить в (или читать из) неё "плоским" образом

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

Плюс, в режиме SPI даже рисование пикселей с помощью таких команд - довольно затратная штука.
Опять же, для тех чипов, с которыми я работал, последовательность команд будет выглядеть:
SetWindow () 0x2A + (Left >> 8) + (Left & 0xFF) + (Right >> 8) + (Right & 0xFF) + 0x2B + (Top >> 8) + (Top & 0xFF) + (Bottom >> 8) + (Bottom & 0xFF) + 0x2C + (RGB >> 8) + (RGB & 0xFF)
13 байт + дёрганье ножкой RS (D/C). При скорости SPI в 20МГц получим (20 / 8) = 2.5МБ/с (8 бит при SCK = 20МГц). Будем считать, что точки расположены как попало, потому сэкономить на отправке которких команд не выйдет, а пин RS (D/C) для нас бесплатен и его переключение не занимает времени. (По факту - требуется дождаться окончания транзакции, убедиться в этом, и только потом менять его состояние. В противном случае... у меня были интересные странности в поведении дисплея).
Значит, 13 байт при максимальной скорости в 2500000 байт/с отправятся за 5,2мкс. Допустим, у нас порядка 2048 точек. ~10,65мс. Нужно не забыть стереть предыдущие пиксели перед этим (+10,65мс) = 21,3мс. Окей, на 50Гц обновления тянет.
А теперь нужно отрисовать интерфейс (с результатами измерений!). Пикселами будет КРАЙНЕ медленно - лучше рисовать как раз блоками. То же SetWindow с размерами окна, и пилить туда текст потоком пикселей.

Допустим, нужно отрисовать порядка 10 блоков измерений, размерами... хотя бы 12*64. 12 пикселей - высота и какой-нибудь узкий шрифт.
12 * 64 = 768 * 2 (rgb) = 1536 + 11 (SetWindow) = 1547 байт. Делим на 2.5МБ/с = 0,62мс на блок. * 10 блоков = 6.2мс. Так как перерисовка блока выполняется начисто (с фоном) - старые пиксели затираются автоматически.
Складываем 21,3 + 6,2 = 27,5мс ~36FPS, что ещё терпимо.

В результате, SPI интерфейс не особо скоростной :(

FSMC контроллер при тактовой в 20МГц сможет залить весь экран (320*240) * 2 (rgb565) за ~7,7мс (разве что для этого требуется частота ядра около 80+МГц).

Где-то я делал тесты по скорости вывода картинки в экран. И вроди бы использовал при этом максимально возможные частоты передачи... и получал на том же экране частоту обновления до 40Гц (с перерисовкой и почти без разрывов), тупо дёргая DMA2D по таймеру. Ядро при этом занималось своими делами.

[x893 35]

Можно использовать что то типа RA8875

Будет быстрее

[AlanDrakes 1]

Пол часа пытался найти что-то такое в гугле, пытаясь сформулировать запрос >_<

Ну да, с ним будет быстрее. Но потребуется внешний ROM для хранения фоновой картинки и каждый раз её перечитывать, а потом отрисовывать осциллограмму... ну не знаю. Здесь интереснее бы смотрелся контроллер с поддержкой слоёв: Задний слой с общими элементами типа фона кнопок, полей измерений и шкал, второй слой с графиком, и третий с надписями. Для осциллографа - прямо минимум необходимого. Опять же, можно попробовать посчитать скорость работы с точками путём пихания данных в регистры... применительно к RA8875 это... 0x91~0x94 (Start line), 0x95-0x98 (End line), Color (0x63-0x65), 0x90 (Draw!) (while (0x90 == draw) {} ).
Чёт тоже много действий. Было бы интереснее, если бы описали команду через запись одного регистра набором данных. Например, 0x90 => Draw (0x20), StartX1, StartX2, StartY1, StartY2 ... Color1, Color2.
Опять же, для осциллографа... (снова применительно к теме) требуется отрисовка линий по массиву точек.

А вот заливка прямоугольников будет экономить время. Особенно больших.

[yung 0]

1 hour ago, AlanDrakes said:

Здесь интереснее бы смотрелся контроллер с поддержкой слоёв: Задний слой с общими элементами типа фона кнопок, полей измерений и шкал, второй слой с графиком, и третий с надписями. Для осциллографа - прямо минимум необходимого.

Лет ...надцать назад был SED1335. Монохром, 8 пикселей в байте, 3 слоя. Можно попробовать поискать, чем это семейство продолжилось.

[x893 35]

2 hours ago, AlanDrakes said:

применительно к RA8875

Описание внимательно читать надо

Block Transfer Engine

Geometric Speed-up Engine

Dual Pages Mode

Horizontal Scroll

Vertical Scroll

Graphic/Font Rotation

Programmable Text Cursor

Support Graphic Cursor

User-defined Characters

[Obam 30]

Можно, но у ТС вопрос с другого форума Радиокот с "умным" управлением дисплеем, как видеокартой.

"Дикие люди - дети гор..."(с)
Забывают, что в комьютерном мониторе ещё "компьютер" (но узкоспециализированный).

[Levontay 0]

05.05.2022 в 09:51, AlanDrakes сказал:

но у ТС вопрос с другого форума Радиокот с "умным" управлением дисплеем

Да - есть такое.

05.05.2022 в 09:51, AlanDrakes сказал:

отправить в дисплей команды типа "Рисуй массив точек"

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

 

04.05.2022 в 11:01, AlanDrakes сказал:

А передача команды/данных осушествляется записью байта в разные адреса в памяти (не в RAM, а в адресном пространстве, которое отображено на память) в случае моего проекта это блок 0xC00xxxxx, а FSMC сам разбирается с таймингами пинов и установкой уровня на пине RS (данные/команда).

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

04.05.2022 в 11:01, AlanDrakes сказал:

Грубая оценка - 4 такта процессора на 1/2/3 байта

- то-есть - 4 такта на байт в худшем случае. Что значит - в зависимости от шины? Для STM32F303 в корпусе на 100 ножек - какая будет ширина? - как это определить?

Тут встаёт вопрос - на сколько это критично для SPI - какой у него потолок по графическому разрешению при STM32F303? Если 32 такта на байт - то в 32 раза медленнее. Буфер картинки АЦП будет 12 точек по стояку, и, для 100кГц и 30 кадров в секунду для двух периодов исследуемого сигнала и миллион выборок в секунду, получается: 0.00002 сек - развёртка, по пологой способности мы не ограничены - всё упирается в возможности буфера экрана (480 пикс.). Всё сводится к тому - что надо чертить линию указанной толщины между определёнными для нового экрана координатами. - Так что будет этим заниматься? Если мы будем чертить линии между точками на экране - то мы будем зависеть от его разрешения и серьёзно затормозимся. Вопрос в том: а реально-ли вообще заниматься черчением линии? Или мы на формирование возможности векторного управления потратим больше ресурсов - чем на копирование?..

Там мне уже посоветовали взять STM32H743 и с ним делать красивости (я, кстати, взял) - но это другая тема. 

Собственно, я пытаюсь определиться - а оправдано-ли вообще какая-то там возня при переходе на большее разрешение? 

05.05.2022 в 01:06, Obam сказал:

Цитата

чем занимается чип?

Добавляя к вышесказанному: формирует эл. сигналы, управляющие ЖК-матрицей

Это не вопрос: понятно - что он обслуживает экран. Вопрос был на предмет определиться - а на сколько подобные чипы поддерживают упрощённое управление собой - кроме как - копирование памяти. Хочется найти чип - чтоб послать в него линию - и он сам рассчитал - не затрагивая микроконтроллер.

 

05.05.2022 в 10:40, x893 сказал:

RA8875

То-есть - это ещё один чип, по сути - деталь - соизмеримая с микроконтроллером с памятью в 768кб ОЗУ!? Ого! - так лучше уж вообще отказаться от базового STM32F303...

Я подумаю.

- трижды.

**************************************************

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

Спасибо.

 

 

05.05.2022 в 09:51, AlanDrakes сказал:

для 20МГц ~7,7мс

- то-есть - 130fps для 320*240 (76 800). Буфер памяти нужно в два раза меньше - 38400МБ, а для экрана 480*800 (384 000) - что в пять раз медленнее: 130/5=26 (fps) - что не плохо. А теперь зададим естественную частоту в 72МГц, а ещё разгоним до 128... - ну это я уже играюсь... Буфер будет - 192 000 МБ, что для STM32F303VCT6, при его 40-RAM - будет маловато.

Изменено 9 мая, 2022 пользователем Levontay

[Obam 30]

Вопрос был на предмет определиться - а на сколько подобные чипы поддерживают упрощённое управление собой - кроме как - копирование памяти.

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

Хочется найти чип - чтоб послать в него линию - и он сам рассчитал - не затрагивая микроконтроллер.

Видеотерминал DEC VT-240 c ReGIS (Remote Graphics Instruction Set), отечественный клонаналог MC7105 соответственно с ГраНК.

[AlanDrakes 1]

09.05.2022 в 19:11, Levontay сказал:

Тем-более - для медленной смены картинок осциллографа скорость не очень важна.

Смысла делать "медленную" смену картинок осциллографу нет. Там наоборот, чем быстрее, тем лучше. Хорошие осциллографы выдают 60+FPS + отображают "интересные" кадры, которые были пойманы между отрисовками экрана. Вероятно, сложно описал мысль, но... Грубо говоря, имеем развёртку в 1мс на кадр (10 клеток по 100ns). При 60FPS между кадрами будет (1000 / 60 ) = 16,6мс, округлим до 16. В момент времени T=0 [0..1мс] - (первый экран) срабатывает триггер, данные отправляются в память. После этого ничего интересного НЕ происходит на протяжении... допустим, 8мс. В момент T=8.186мс снова срабатывает триггер. Захваченый буфер так же отрисовывается (старый может стать "призраком", потеряв часть яркости). Далее, допустим, в момент T=14.2мс приходит третий импульс, заставляющий сработать триггер. Естественно, отрисовываем и его. Получаем наложение трёх сигналов на ОДНОМ кадре.

Современные осциллографы позволяют рисовать по 50+ слоёв и имеют производительность в 60k+ WFS (WaveForms per Second - волновых форм в секунду).

09.05.2022 в 19:11, Levontay сказал:

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

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

09.05.2022 в 19:11, Levontay сказал:

Что значит - в зависимости от шины? Для STM32F303 в корпусе на 100 ножек - какая будет ширина?

Очевидно, 16 бит, так как это самый большой кристалл в линейке. Как определить? Простой способ - скачать STM32CubeF3 и в нём настроить периферию. Как минимум, хорошо визуализирует используемые пины. Код от него использовать - не рекомендую. А вот в Datasheet'е всё очень странно. Упоминание о контроллере памяти есть, но списка пинов - нет.

09.05.2022 в 19:11, Levontay сказал:

Тут встаёт вопрос - на сколько это критично для SPI - какой у него потолок по графическому разрешению при STM32F303? Если 32 такта на байт - то в 32 раза медленнее. Буфер картинки АЦП будет 12 точек по стояку, и, для 100кГц и 30 кадров в секунду для двух периодов исследуемого сигнала и миллион выборок в секунду, получается: 0.00002 сек - развёртка, по пологой способности мы не ограничены - всё упирается в возможности буфера экрана (480 пикс.).

Не путайте мух и котлеты - битность АЦП (12) и его возможное разрешение (4096 значений).
И мне интересно, что значит "12 точек по стояку"?. 12 пикселей в высоту? Мало. 12 пикселей в ширину? Не имеет смысла.
Если берёте экран на 480 пикселей - так используйте хотя бы 480 пикселей для буфера захвата. Нормальные приборы используют 4к точек. В высоком разрешении (12 бит) каждый отсчёт будет занимать 2 байта (12 / 8 = 1.5, округляем вверх до целого = 2). Значит нужно 8кБ памяти только под буфер выборок.
Хорошие приборы так же используют OverSampling - когда один пиксел (столбец) может скрывать под собой несколько отсчётов.

> для 100кГц и 30 кадров в секунду для двух периодов исследуемого сигнала и миллион выборок в секунду.
Входящий сигнал? Ну да, в этом случае, два периода сигнала займут всего-лишь:
2 (периода) * (1(с) / 100000(гц)) = > 2 * (1 / 100000) => 2 * (0,00001) = 0,00002с (если я не ошибся с количеством нулей)
30FPS = 1 / 30 = 0.033с = 33мс

0,033 - 0,00002 = 0,032997с... ничегонеделанья и один снимок на два периода сигнала. Ну, допустим... Хотя это и КРАЙНЕ странно.

09.05.2022 в 19:11, Levontay сказал:

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

Приведённый выше контроллер умеет только линию в 1px.

09.05.2022 в 19:11, Levontay сказал:

Или мы на формирование возможности векторного управления потратим больше ресурсов - чем на копирование?..

Я на это и намекаю. SPI не предназначен для такого потока данных. Во всяком случае, постоянное дёрганье пина RS (D/C) - рискуете не попасть в тайминги и дисплей воспримет данные как команду, или команду как данные.

09.05.2022 в 19:11, Levontay сказал:

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

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

09.05.2022 в 19:11, Levontay сказал:

 а для экрана 480*800 (384 000) - что в пять раз медленнее: 130/5=26 (fps) - что не плохо.

Для STM32F767 - можно попробовать... скажем... 480*800 / 2 = 192000 байт (187.5кБ из 368кБ) - хороший такой буфер памяти.
Чип гонится до 216МГц (штатно) и даже выше (я случайно разогнал его до 250МГц несколько раз). FMC контроллер работает на частоте ядра, но на такой скорости уже могут возникать проблемы из-за проводов, а так же требуются такты задержки для того, чтобы порты успевали зарядить дорожки до нужного напряжения. А там ёмкость небольшая, но на таких частотах = существенная нагрузка на чип.
Тайминги FMC на моей плате были... -/-/0/5/-/2, где "-" - значение не используется в данном режиме, 0~5 задержки в тактах, необходимые для корректной работы. Соответственно, на 200МГц получаем задержку шины в 7(!) тактов.
1 такт на 200МГц = 5нс, 7 тактов = 35нс. Шина - 8 бит (потому что ILI9431 LCD Shield для Ардуины).
Соответственно, скорость обмена в моём проекте была ~28,5МБ/с, и 384000 байт можно протолкнуть через шину за 13,47мс. Через параллельную шину. Ядру контроллера при этом желательно оставаться в состоянии сна, ибо у него приоритет выше, чем у DMA блока и если ядро будет работать с той же областью памяти, что и DMA, последний будет стоять в ожидании. Кстати, лол, 74FPS.
На SPI... эм... грубо говоря, делим на 16 (если SPI скоростной) или на 32. Соответственно, 480*800 на последовательной шине с горем пополам выдаст 2-4FPS с полным обновлением экрана.

Посмотрите в сторону более скоростных кристаллов, либо кристаллов со встроенным ускорителем и интерфейсом LVDS для таких размеров экрана.

Тот же Fnirsi 1013D построене на Allwinner F1C100s.

[Levontay 0]

Спасибо, я, примерно, понял.

 

Разрешение АЦП (12 стояка) - битность АЦП, умножаемая до пикселей на экране.

30fps - просто взято для примера - отсюда и остатки неиспользованного процессорного времени.