Jump to content

    

__inline__

Участник
  • Content Count

    463
  • Joined

  • Last visited

Community Reputation

0 Обычный

About __inline__

  • Rank
    Местный

Recent Profile Visitors

1057 profile views
  1. Нашли S1D13746F01 - видео-буфер с композитным видео-выхлопом для NTSC/PAL TV. Дополнительные функции: растяжение, сжатие размеров видео-изображения на экране ТВ с фильтром, аппаратное вращение на углы кратные 90 градусов, автоцентрирование кадра, поддержка бордюров, растровые операции (sepia, blur, edge, sketch и др.), программируемый фильтр, двойная буферизация для потокового видео и многое другое. Только на запись и весь кадр сразу! Цепляется к контроллеру по параллельной шине i8080 (поддерживаются как 8-битная, так и 16-битная шины данных), что очень сильно облегчает сопряжение уже имеющейся макетной платы Mini C6745 с видео-выхлопом (проще говоря - отсоединив LCD, вешаем S1D13746F01). Так что и буфер и ЦАП и энкодер - под одной крышкой! :) И поддержка нужной шины с нужной разрядностью! И с авто-инкрементом адресов буфера (логика работы почти как в LCD со встроенным контроллером--памятью) Видеоконтроллер S1D13746F01 полностью открыт и документирован, есть API на языке C и понятные блок-диаграммы в тех-мануале!
  2. Я за то же время на C6745 подыму больше, чем на олвиннере A13. К тому же конструкция на 80% близка к завершению. Нужен дополнительно выхлоп видео на ТВ или VGA-монитор. Специально для тех кто не любит ЖК экраны с размером 3 дюйма. У стандартного PAL частота кадров 50 Гц, а надо 60, так как все портированные эмуляторы работают в этом режиме и игры тоже, и я поклонник NTSC, так как недолюбливаю медленный темп музыки в PAL и вытянутость изображения по вертикали мне как-то больше нравится. А что это, правда, за разрешение такое, куда ни прикину - так везде либо 320х240, как у старых компов-игрушек, или 640х400, как у ХТшки айбиэмовской или VGA 640х480 и т.д. Ну или ТВ 510строк или как его уж не помню... У старых DOS-игр не 320x240, а 320x200 @ 70 Hz 400x240 - это формат кадра под названием WQVGA. Такой дисплей стоит в телефонах LG GX500 и многих других. Стандартного QVGA 320x240 мне не хватило - эмуляторы CPS1,2 работают в разрешении 384x224, пришлось расшириться. Рисунок ниже: Оставшихся ножек не хватает. Надо 16 бит на цвет и 2 на синхронизацию. Ну и прийдётся в состав кадра включать бордюры всякие с уровнем черного, что увеличивает размер буфера. Поэтому мы подыскиваем сейчас НЕЧТО, что грамонично впишется на EMIFA 8 бит. Концепт таков - предусмотреть возможность работы с LCD и ТВ (или analog VGA) - либо одно, либо другое.
  3. На плате olinuxino A13 есть R-ЦАП на VGA выхлопе, и ничего. Картинки видел, по качеству устраивал. + сам так делал. Тогда из 640x480 сделать 400 на 240 путём стретча пиксела по горизонтали в 1,6 раз и с двойным сканированием строки - чтобы 240 строк стали толще в 2 раза для покрытия 480. И ещё больной вопрос про aspect ratio: 400x240 на мониторе 4:3 будет смотреться вытянутым по вертикали - тут решение с бордюами наверное лучше, чем OverScan (на весь экран) В общем прикинул, в моем случае ничего хорошего не получится. Нет детерминированности в обращении к памяти. L1 отданы под кеш, L2 также отдан под кеш + стек , во внешней SDRAM код и данные. Так что чтение из любой из них приведет к неопределенному времени. Пикселы будут неровными и будет дрожать. Не годится. Это в случае - PRUSS+ GPIO. С ДМА всё ещё более сложнее - неизвестно сколько времени будет чтение из SDRAM, на которую претендует ещё CPU и кеш. Увы, без ПЛИС или спец-контрорллера тут не отделаешься. В простейшем случае нужен видеоконтроллер с 8 битной шиной (на EMIFA чтоб завязаться) с фреймбуфером не менее 187,5 кБайт (400x240 16 bpp)
  4. На McASP занят 1 канал - дует звук в аудио-ЦАП. Чем решение с GPIO плохое? Допустим, есть ещё свободные биты GPIO: 16 штук + 2 (на синхры). Неужели для PRUSS ничего нельзя сообразить толкового при таких условиях? С GPIO тоже не выходит, часть заняты и нету с 0 по 15 свободного GPIO. Остаётся EMIFA 8 бит и 2 на H/V sync + скрип зубов от потери цвета при суб-пиксельной дискретизации YUV 4:2:2 и ещё конверт RGB в YUV на плечи процессора В этом случае всё-же AD724 или CXA1145 будут лучше, так как они тупо принимают аналог RGB и делают NTSC/PAL, без всякого дополнительного программирования по I2C(как в случае ADV7390 ). Как вариант - рассмотреть вывод на монитор (аналог, D-SUB). Не могу найти времянки для 400x240, вижу только стандартные растактовки кадров, стандартизированных VESA'ой (640x480, 800x600 и т.д.)
  5. Посадить на EMIFA можно. Требуется только один режим из двух: или LCD (со своим контроллером и памятью) или ТВ. Вопрос, насколько ощутима потеря цветовых оттенков из-за суб-дискретизации в 4:2:2 из RGB 5:6:5 на ТВ приёмнике (ЭЛТ, кинескоп) ? И где брать HSYNC, VSYNC - из стробов WR и CS делать функцию или отдельные GPIO ?
  6. EMIFA 8 бит - занят LCD, EMIFB 16 бит занят SDRAM. Делать временное разделение шины не хотелось бы (нужна производительность). Остаются GPIO + PRUSS.
  7. Необходимо обеспечить передачу видео-сигнала NTSC на 75-омный видео-вход ТВ. (AV in). В качестве энкодера NTSC микросхемы: AD724 или CXA1145 или CXA1645, которые из RGB, Hsync,Vsync делают NTSC. Значит, необходимо со стороны PRUSS реализовать чтение видеопамяти, сформировать сигналы H,V-sync , компоненты RGB превратить в аналоговые с помощью простейшего резистивного ЦАП и подать их в энкодер. Требуемый режим: 400x240 60 Гц, 16 бит на точку (5:6:5, можно 5:5:5). Можно не на весь экран, а с бордюрами. PRU ядро, на частоте 228 МГц, память кода 4 кБ и данных 0,5 кБ для этих целей хватит? Или не взлетит? DSP TMS320C6745. P.S. с ПЛИСами и спец-чипами заморачиваться неохотно, желается сделать решение на 1 кристалле C6745
  8. А вот использование DMA для чтения-записи SD-карты при использовании FAT FS весьма сомнительное удовольствие. Следующий сектор неизвестно какой может быть, если не прочитан текущий. Как тут быть? По теме надумалось еще. Может чтение фреймбуфера из DDR с частотой 60 Гц съедает полосу? Упомянуто относительно высокое разрешение дисплея и LTDC. Сюда же ещё и DMA-копирование. А память общая и внешняя DDR. И всё-же дисплей со своей видеопамятью и растеризатором - лучшее решение, когда надо разгрузить центральный процессор :)
  9. STM32MP1 - bare metal

    Где-то в DSP-разделе полегла моя тема с запуском McASP через DMA. Суть в том, пока в DRAE не будут взведены нужные биты, прерывание конца пересылки возникать не будет. Сложности возникают, когда DMA работает в режиме пмять=>периферия. Если сравнить с STM32, то у C6745 DMA всё-же сложнее. Но это нисколько не умаляет его достоинств и преимуществ перед убогим ДМА на STM32 :)
  10. CubeMX и User code

    Говнокодеров везде хватает, в том числе и на ZX :) И почему выводы делаете только по одной ссылке?
  11. Ради интереса поднял тесты на C6745. SDRAM 16 бит, 152 МГц. Кеширование включено. Передача буфера 128x128 коротких слов(2 байта на точку) разными порциями: байт, полу-слово, слово, двойное слово в дисплей (память закеширована, дисплей - нет): #define LCD_BASE 0x60000000 /* 32MB Async Data (CS2) */ #define LCD_I LCD_BASE #define LCD_D (LCD_BASE+0x00004000) /* A12 */ #define LCD_I8 (*(volatile unsigned char*)LCD_I) #define LCD_D8 (*(volatile unsigned char*)LCD_D) #define LCD_I16 (*(volatile unsigned short int*)LCD_I) #define LCD_D16 (*(volatile unsigned short int*)LCD_D) #define LCD_I32 (*(volatile unsigned int*)LCD_I) #define LCD_D32 (*(volatile unsigned int*)LCD_D) #define LCD_I64 (*(volatile unsigned long long*)LCD_I) #define LCD_D64 (*(volatile unsigned long long*)LCD_D) //64 bit transfer: 128x128 651 FPS n>>=3; register u64 *P=(u64*)&Picture[o]; while(n--)LCD_D64=*P++; //32 bit transfer: 128x128 615 FPS /* n>>=2; register u32 *P=(u32*)&Picture[o]; while(n--)LCD_D32=*P++; */ //16 bit transfer: 128x128 553 FPS /* n>>=1; register u16 *P=(u16*)&Picture[o]; while(n--)LCD_D16=*P++; */ //8 bit transfer: 128x128 461 FPS /* register u8 *P=(u8*)&Picture[o]; while(n--)LCD_D8=*P++; */ С ДМА получилось чуть-больше, чем с 64-битной передачей : //128x128 682 FPS void EDMA3_Run(void) { EDMA3_ESR=0x00000001; //Channel 0 set } Что важно, настройка DBS, меньше 32 байт даёт уже меньше производительность: L1P_Config(L1_SIZE_32K); //Enable L1P L1D L2 Cache L1D_Config(L1_SIZE_32K); L2_Config(L2_SIZE_256K); SDRAM_Cacheable(CACHEABLE_ON); //Enable SDRAM Cacheable CFGCHIP0=(2<<2)|2; //PLL MMRs unlock & TC1 64 byte & TC0 64 byte (DBS) В олвиннерах DBS регулируется? В случае DDR сохраняется однотактность доступа к памяти через DMA? Может в этом кроется причина медленной работы DMA с DDR ? В случае с C6745 SDRAM может работать в пакетном режиме - доступ вроде как однотактный там. Поэтому и DMA там довольно быстрый
  12. STM32MP1 - bare metal

    У C6745 ДМА очень не простой. Много вещей пришлось курить. В частности, не так просто было добиться прерывания по завершению передачи. Нужно было заэнаблить биты в теневых регистрах, которые к ДМА имеют очень косвенное отношение. А без этого только статус-порт опрашивать, не очень хорошо.
  13. CubeMX и User code

    Плохо ищите :) 1) http://gendev.spritesmind.net/forum/ 2) https://zx-pk.ru/forum.php 3) http://forums.nesdev.com/ Этих ребят никакими облаками не заманишь :) В качестве хост-платформы - почему бы и нет? Помнится, на этапе появления 95-й винды, Билл Гейтс предложил окна, из-за чего был послан игроделами далеко и по-дальше. В то время господствовали Full-screen DOS игры :) Правда в 98-й появился DirectX, с этого момента пошло массовое предательство и закат байто*бства на ПК )))
  14. Блиттера хардварного у меня не было. Всё делалось ручками (CPU). Ещё по наблюдением, нужно было немного корректировать времянки дисплея в бОльшую сторону с использованием кеширования и DMA (параметры циклов записи на шину) - возможно из-за более плотной передачи данных. Пока не скорректировал - были артефакты на дисплее, вплоть до срыва всего кадра и отключения дисплея (интерфейс общения с дисплеем простой - через 2 порта: команда, данные). На счёт медленности ДМА в оллвиннерах, может не всё так плохо? ДМА может хоть и медленее CPU перекидывает блок, но за счёт параллельности может давать выигрыш. К примеру: Программа идёт 9 мкс, отрисовка CPU 3 мкс - всего 12 мкс. С ДМА: программа - также 9 мкс, отрисовка ДМА: 9 мкс - в 3 раза медленее, но за счёт параллельности - суммарное время - 9 мкс вместо 12 мкс. Тот самый случай когда за счёт параллельности достигается небольшой выигрыш, хотя ДМА меделенный. На C6745 как-раз с этим сталкивался неоднократно - там встроенный сопроцессор PRUSS который намного слабже (частота вдвое ниже ядра, ограниченный набор команд, отсутствие кеша), чем сам DSP за счёт отрисовки параллельно давал нехилый суммарный выигрыш.
  15. Спасибо, буду знать. На счёт чтения, не представляю себе пользы чтения видеопамяти дисплея. Всегда заводил промежуточный буфер и делал там все операции - по альфа-смешению и прочее - в системной памяти (которая кеширована на чтение и запись), затем сформированный буфер отсылал в дисплей (но он был не фрейм-буффером, а простым регистром данных с авто-инкрементом адреса внутри дисплейного контроллера. Читать память такого дисплея - дорогое удовольствие, к тому же всегда в формате пиксела 6:6:6, что неудобно когда используеься 5:6:5)