[nanorobot 3]

On 10/17/2018 at 7:21 PM, aaarrr said:

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

Думаю, ни у кого не вызывает сомнения, что получить даже 130мм разность длин сигналов при трассировке SDRAM - это специально стараться надо.

 

Эпсилон учтен.

Если подойти чисто арифметичкски, означает ли это, что для какой нибудь DDR3 / 400 MHz достаточное выравнивание с точностью :   100 мм / (400 МГц / 160 Мгц) = 100 / 2.5 = 40 мллиметров?

[aaarrr 63]

DDR3-400 - это 800Mbps, поэтому еще на два поделите.

[khach 33]

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

[LWW 0]

Я так смотрю на Хи7, ну а что там, по большому счёту, ничего уникального, относительно хороших старших братьев. Разве что CAN FD. Но что бы его воплотить, ответные модули должны так же содержать can_fd, а значит быть построенными на H7. 12-мегабитный UART легко реализуется на USB CDC, причём на ассемблере. И скорость передачи достигает 50 мегабайт в секунду. Много-много таймеров, ну куда их.. Куча шимов? Как и аналоговая часть - всё делается на внешних микросхемах с гораздо более высоким качеством.

 

Другие няшки-вкусняшки, хоть и редкие для ногодрыгалок, но лишь помогают быстрее выполнять программу.. Нет.. Такой сопроцессор нам не нужен 

 

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

[khach 33]

45 minutes ago, LWW said:

Я так смотрю на Хи7, ну а что там, по большому счёту, ничего уникального

Именно таймера, в том числе hires, АЦП быстрые синхронизированные между каналами, компараторы с прерываниями, многофазный ШИМ и еще куча вкусняшек. На внешних микросхемах конечно все реализуется, но даже правильно спроектировать систему прерывания и ДМА для кучи внешних микросхем уже проблема. Про рост цены и размеры платы в этом случаем умолчим. Параллельная шина конфигурируемая тоже большой плюс. А вот с памятью засада- нехватает ее. Ну что ж, прийдется пока урезать осетра. и делать двухпроцессорные системы на например на двух тех же H7.  А то управлять СВЧ синтезатором в режиме ЛЧМ,  обрабатывать поток данных с фурье преобразованием, показывать график на экране, одновременно обслуживать удаленный десктоп по LAN все таки ресурсов маловато.

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

 

[nanorobot 3]

On 10/8/2018 at 2:52 PM, hd44780 said:

H7 пока не делали, щупаю помаленьку на NUCLEO плате.

Не пробовали по FMC подключать LCD с контроллером SSD1963? Интересует как оно будет по сравнению с LTDC.  SDRAM не ставить, корпус процессора в два раза меньше. Заманчиво.  Уже бы сам начал пробовать, ПромЭлектроника до 09.01.19 пьянствует.

 

PS индикатор: https://www.ecom.cz/open_sheet/sheet_name=D59283

Изменено 6 января, 2019 пользователем nanorobot

[khach 33]

6 hours ago, nanorobot said:

Не пробовали по FMC подключать LCD с контроллером SSD1963?

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

[nanorobot 3]

54 minutes ago, khach said:

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

Имеется в виду считывание пикселей из контроллера? Не знаю, этим библиотека сама занимается. Верятно считывание ей тоже требуется, хотя в определенной степени это и от меня зависит. Есть надежда, что так как шина FMC при генерации сигнала лля LCD "не напрягается",  и в отличие от LTDC,  используется только для прорисовки  то скорость последней может возрасти.  Плюс экономия пинов процессора.  Честно говоря до вчерашнего дня не знал о существовании LCD такого разрешения(800 х 480) со встроенным контроллером, а то давно бы попробовал. Может бывалые люди уже пробовали, и отсоветуют мне идти в эту сторону?

 

Изменено 6 января, 2019 пользователем nanorobot

[AlanDrakes 1]

Помнится, мучался со считыванием пикселей на F7 из LCD на ILI9431 и им подобных. Там ТАКИЕ тормоза требуются для процесса считывания, что скорость шины становится просто смешной. В итоге, плюнул на это неблагодарное дело и подключил LCD так:

FrameBuffer -> CromeART -> FMC -> LCD

Данные пишутся в экранный буфер (Использую 16 цветов в режиме L4), на дисплей при обновлении кадра автоматически конвертируется в RGB-565 посредством DMA2D (CromeART), затем через FMC пишется на скорости интерфейса прямо в дисплей (но дисплей получает команды X=>0, Y=>0, RamWrite (0x22), а затем поток данных, и так каждый кадр).

Из минусов - имею частые обращения к памяти от DMA (должно сказаться на скорости, но пока проект отложен - не могу сказать точных цифр) и собственно, выделение памяти (в моём случае это 320*240/2 = 38400 байт) и динамическое выделение данных под скриншот (дёргаю из кучи, затем освобождаю по готовности). Запись на карту памяти из буфера - в разы быстрее чем из экрана, а так же свободна от артефактов считывания пикселей.

[nanorobot 3]

39 minutes ago, AlanDrakes said:

Помнится, мучался со считыванием пикселей на F7 из LCD на ILI9431 и им подобных. Там ТАКИЕ тормоза требуются для процесса считывания, что скорость шины становится просто смешной. В итоге, плюнул на это неблагодарное дело и подключил LCD так:

FrameBuffer -> CromeART -> FMC -> LCD

Данные пишутся в экранный буфер (Использую 16 цветов в режиме L4), на дисплей при обновлении кадра автоматически конвертируется в RGB-565 посредством DMA2D (CromeART), затем через FMC пишется на скорости интерфейса прямо в дисплей (но дисплей получает команды X=>0, Y=>0, RamWrite (0x22), а затем поток данных, и так каждый кадр).

Из минусов - имею частые обращения к памяти от DMA (должно сказаться на скорости, но пока проект отложен - не могу сказать точных цифр) и собственно, выделение памяти (в моём случае это 320*240/2 = 38400 байт) и динамическое выделение данных под скриншот (дёргаю из кучи, затем освобождаю по готовности). Запись на карту памяти из буфера - в разы быстрее чем из экрана, а так же свободна от артефактов считывания пикселей.

Честно говоря, мало чего понял. Экранный буфер - понятно, но что значит "пишется прямо в дисплей" - вероятно используется встроенный LTDC? Тогда неясно что за "команды X=>0, Y=>0, RamWrite (0x22)"  Для  320х240 экранный буфер полностью поместится во встроенную RAM и в этом случае, естественно, скорость будет максимальная. Это ясно, но к моему вопросу имеет очень малое отношение.  Меня интересует в каком случае можно получить большую скорость прорисовки:
1. При использовании LTDC и буфера экрана во внешней SDRAM памяти.
2. При использовании LCD с контроллером SSD1963 подключенного к FMC шине.

В обоих случаях предполагается использование DMA2D процессора STM32H743.

 

PS: ILI9431 использовали через SPI или по параллельной шине? В первом случае тормоза естественны.

Изменено 6 января, 2019 пользователем nanorobot

[khach 33]

Читать из буфера экрана приходиться при операциях типа отрисовки курсора. Из за невозможности читать экранный буфер контроллера по шине приходиться заводить его копию в ОЗУ. А чтобы не было морганий тзображения- два буфера в интерливе, в один рисуем, второй по ДМА выгружается в SSD1963. Но при этом мы оказываемся "опять на дерибасовской" т.к встроенной памяти не хватает. Вернее хватает только под экранный буфер. А если процессор занимается чем то более значимым чем выдача картинки с SD на экран и алгоритмы типа фурье жрут память под буфера данных, то становиться совсем грустно. Уж не говорю про USB или LAN - там память вообще сьедается мгновенно.

[nanorobot 3]

43 minutes ago, khach said:

Читать из буфера экрана приходиться при операциях типа отрисовки курсора. Из за невозможности читать экранный буфер контроллера по шине приходиться заводить его копию в ОЗУ. А чтобы не было морганий тзображения- два буфера в интерливе, в один рисуем, второй по ДМА выгружается в SSD1963. Но при этом мы оказываемся "опять на дерибасовской" т.к встроенной памяти не хватает. Вернее хватает только под экранный буфер. А если процессор занимается чем то более значимым чем выдача картинки с SD на экран и алгоритмы типа фурье жрут память под буфера данных, то становиться совсем грустно. Уж не говорю про USB или LAN - там память вообще сьедается мгновенно.

Почему невозможно считать экранный буфер? Вот здесь  http://forum.easyelectronics.ru/viewtopic.php?f=35&t=13375 вроде выяснили, что readback c SSD1963 работает.  Да и сам набор входных сигналов 1963 предполагает чтение. То есть с точки зрения ЦПУ это такая же внешняя память, как и любая другая. Или это все же не так?

Изменено 6 января, 2019 пользователем nanorobot

[AlanDrakes 1]

При использовании SPI интерфейса, чтение пиксельных данных из экрана невозможно.

У меня экран висит на 8-ми битной шине FMC контроллера. LTDC не задействовал - у него хоть и имеются интересные возможности, но нельзя использовать запакованые пиксели формата L4. Таких помещается два в одном байте - экономия памяти, которая потребуется в других задачах.

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

Например, на 8-ми битной шине, при частоте ядра контроллера в 100МГц (уточню, что использую STM32F745, а эта частота выбрана как удобная для расчётов), можно получить около 30 заполнений экрана в секунду. Именно заполнений - полноценных выводов нового кадра из памяти в экран. При бОльших частотах, естественно, можно и быстрее отрисовывать, но скорее всего сам контроллер экрана не сможет. Считывания упирались в какие-то внутренние тайминги экрана, и сильно портили картину. Чтение проихсодит, да, но как-то не всегда стабильно, и крайне медленно (1-2 секунды на чтение экрана - это просто что-то в чём-то).

18 часов назад, nanorobot сказал:

Экранный буфер - понятно, но что значит "пишется прямо в дисплей" - вероятно используется встроенный LTDC? Тогда неясно что за "команды X=>0, Y=>0, RamWrite (0x22)"

Ответил выше, но всё же.

FMC позволяет использовать пин RS (выполняет роль D/C) напрямую записывая данные в разные адреса памяти. Например, запись массива пикселей в адреса 0xC0040000...0xC007FFFF приводит к поднятию пина A18 (RS) в 1 и воспринимается контроллером дисплея как поток данных.

Запись же в адреса 0xC0000000...0xC003FFFF - опускает пин в 0 и дисплей воспринимает значения как команды.

Выглядит сие безумие примерно так:

if ((DMA2D->CR & DMA2D_CR_START) == 0) {
	LCD_SetBounds(0, 0, 319, 239);			// Set full screen bounds.
	DMA2D->CR = 0x00010000;				// Mem to Mem with PFC
	DMA2D->FGMAR = (uint32_t)&(ScreenBuffer[0]);	// Frame memory (indexed)
	DMA2D->OMAR = (0xC0040000);			// LCD address
	DMA2D->FGOR = 0;				// Memory Offset
	DMA2D->OOR = 0;					// LCD Offset
	DMA2D->FGPFCCR = 8;				// From L4
	DMA2D->OPFCCR = 2;				// To RGB565
	DMA2D->NLR = (240 << 16) | 320;			// Number of lines and rows
	DMA2D->CR |= DMA2D_CR_START;			// Start transmission
};

Буфер выдаётся на максимально доступной скорости с помощью встроеного DMA из DMA2D "ускорителя" (от ускорителя там только DMA и преобразование).

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

В моём случае проблемы могут быть при одновременном доступе от ядра и DMA2D. Но на практике незаметно.

 

Спойлер

 

Смотрю я на H743/753 чипы референс в области памяти... и тихонько так выпадаю в осадок. Есть у меня подозрение, что в Вашем случае может оказаться быстрее из внешней памяти.

Знаете... Попробуйте оба варианта - буфер в памяти и буфер во внешней памяти. Напишите бенчмарк (я именно так и делал несколько раз ради смеха и попугаев).

[khach 33]

15 hours ago, nanorobot said:

Почему невозможно считать экранный буфер? Вот здесь  http://forum.easyelectronics.ru/viewtopic.php?f=35&t=13375 вроде выяснили, что readback c SSD1963 работает.  Да и сам набор входных сигналов 1963 предполагает чтение. То есть с точки зрения ЦПУ это такая же внешняя память, как и любая другая. Или это все же не так?

 

Читать можно, но медленно и печально, оосбенено  если дисплей с платой процессора кабелем соединен. Писать можно со скоростью 6-8 мегапикселей, а читать - хорошо если 1 мегапиксель удасться получить. Буфера выходные у SSD1963  слабые, затягивают фронты при большой нагрузке. А плат с SSD1963  и двунаправленным буфером на мелкой логике для усиления нагрузочной сопособности никто не делает.

Да и тайминги там на чтение намного хуже чем на запись

 

Там кстати и с записью у H7 не все хорошо. https://community.st.com/s/question/0D50X00009ZChQbSAL/issue-with-using-lcd-with-fmc-in-sram-mode-stm32h743

Т.е шину приходится сильно тормозить чтобы получить правильные тайминги.

 

 

[nanorobot 3]

8 hours ago, khach said:

Читать можно, но медленно и печально, оосбенено  если дисплей с платой процессора кабелем соединен. Писать можно со скоростью 6-8 мегапикселей, а читать - хорошо если 1 мегапиксель удасться получить. Буфера выходные у SSD1963  слабые, затягивают фронты при большой нагрузке. А плат с SSD1963  и двунаправленным буфером на мелкой логике для усиления нагрузочной сопособности никто не делает.

Да и тайминги там на чтение намного хуже чем на запись

 

Там кстати и с записью у H7 не все хорошо. https://community.st.com/s/question/0D50X00009ZChQbSAL/issue-with-using-lcd-with-fmc-in-sram-mode-stm32h743

Т.е шину приходится сильно тормозить чтобы получить правильные тайминги.

 

 

Убедительно. НО. В моем случае курсор не требуется. Возможно в этом случае считывание экранного буфера не потребуется, и решение с SSD1963 может оказаться приемлемым(?) Наверное нужно просто попробовать. Опыт лишним не бывает.

 

PS. В библиотеке uGFX, которую я пользую, можно программно запретить возможность чтения пикселов. GDISP_HARDWARE_PIXELREAD = FALSE.  Как оказалось, это влечет за собой невозможность сглаживания шрифтов - ANTIALIAS, что для меня критично.

Изменено 7 января, 2019 пользователем nanorobot