Ну вот мы подошли и к алгоритмам, а говорите не знаете.
Вам же поворот-растяжение то придется портировать ручками.
Но к сожалению c GUI не работаю сейчас, так что смотрите сами в мануалах.
На вскидку вам поможет помочь модуль Pixel Pipeline в i.MX RT, который и масштабирует и поворачивает аппаратно и alpha-blending делает.
Но опыт ADSP тут точно не пригодится, будет всё другое.
Планируйте на освоение периферии i.MX где-то полгода.

Но я бы с ADSP не переходил. Для такого рода эмуляторов не вижу никаких преимуществ при переходе на другую платформу.
Им же практически ничего не нужно из периферии.

Да ничем он не поможет по сути, там даже выбор портретный или альбомный вывод не предусмотрен, пришлось программно "поворачивать" для вертикально расположенной матрицы, поворот там только картинки, которая в буфере источника и передача ее в получатель, причем с ограничениями по выравниванию то-ли в 4 или 8 пикселей не помню... Там для ускорения нужен аппаратный блиттер, а он есть только в IMX6 да и то под НДА.

Сообщение отредактировал mantech - Mar 26 2018, 13:16

А разве не порвёт C6745 BF532 хотя-бы из-за:
1) VLIW до 6 команд одновременно - против 2 команд у BF532 //выигрыш в 3 раза
2) SDRAM 32 бит - против 16 бит у 532-го // выигрыш в 2 раза
3) Hardware floating point - против софтварных целочисленных рядов Тейлора на 532-м //выигрыш в специфических местах
4) 475 МГц - против 400 // несущественно, но приятно
5) У BF532 - скудный малооперандный ассемблер, в отличие от того же ARM. У C6745 вроде как по-лучше?

В целом вижу оправданным переход на C6745. Поправьте, если ошибаюсь.

Да переходите уже.
Здесь обсуждаем i.MX RT.
А то мне ваши посты придется перенести в "остальные микроконтроллеры"



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

Вот это поворот!! Так так, и каким это дисплеем оно поддерживается??, может "тупой" матрицей, без контроллера и памяти, с RGB входами и синхрой, или я чего-то не понял и можно перекинуть синхры наоборот, как фазы в движке, чтоб он назад поехал

Честно говоря - я уже не помню. Вроде по мануалам разобрался, но может и какие примеры смотрел.
Точно помню, что очень не хватало примеров по USB. Остальное что там использовал: SDRAM, EDMA3, McASP, SPI, UART, I2C, MMU, PRUSS, взаимодействие ядер и т.п. - затруднений не вызвало.

УСБ в них не EHCI-совместимое? Если нет, тогда да, засада...

Не понял эмоцию. А что еще есть дисплеи без поворотов? Там же контроллер стоит!

Это прикол или вы просто не в теме, какой контроллер в матрице, или что вы там под дисплеем понимаете и какой поворот, я не про экраны с контроллером и встроенной памятью, а про "тупые" матрицы с приемником ргб или лвдс и сегментными драйверами. Или что, они тоже должны уметь поворачивать на 90 град?

Сообщение отредактировал mantech - Mar 26 2018, 15:15

Ну я вам сочувствую, но я же предупреждал i.MX RT не для медиацентров.
От дисплея понадобятся кое какие сервисы.
Это нормально в данной теме.
В конце концов и внешних интерфейсов не вагон и памяти.
В i.MX все отлично сбалансировано для моих задач.

А причем тут медиацентр?? Банальная операция поворота изображения, причем всего и сразу, а не кусочков чего-то там. А если уж на то пошло, что дисплей "умный", т.е. с памятью и блиттером, так ему толку-то тогда от вашего видеопорта в МК, там достаточно быстрого SPI(QSPI) или 8и битной шины с синхрой...

Все претензии к NXP.
Я отлично могу сделать любую ориентацию изображения на дисплее как минимум тремя способами:
- средствами самой GUI (у меня uC/GUI),
- с помощью eDMA (Enhanced Direct Memory Access),
- программированием ориентации на самом дисплее (у меня 24 бита RGB, интерфейс DOTCLK )

что вы курите, я тоже такое хочу)))

Вот это

Дак чего мне к ним претензии-то выставлять...

средствами самой GUI я и сам делаю, хоть у меня она и своя собственная.

с помощью eDMA (Enhanced Direct Memory Access) - это как?

- программированием ориентации на самом дисплее (у меня 24 бита RGB, интерфейс DOTCLK )
- это не интересно совсем, ибо никто не будет мне доплачивать за покупку дорогих и навороченных дисплеев.