[denebopetukius 0]

на EBIU подцеплены SDRAM и через буфер LCD (обмен i8080 16бит, встроенный растеризатор и видеопамять)

 

первое ядро - выполняет программу из SDRAM (ICache и DCache WBack включены) и рисует картинку в L2 (Page 0)

 

в это время второе ядро - из L2 (Page 1) рисует в LCD

 

затем Page0 и 1 меняются местами и всё начинается сначала...

 

буфер L2 - необходим, так как в нём строятся несколько слоёв (плоскостей, оверлеев)

 

вопрос: как сильно обе задачи (программы , выполняемые ядрами 1 и 2) будут мешать друг другу из-за общей шины?

 

как ускорить процесс?

 

P.S. PPI НЕ предлагать!

Изменено 30 июня, 2009 пользователем denebopetukius

[Гость MALLOY2]

А что у блекфина нету кеша на каждом ядре, кеш должен все это компенсировать.

[denebopetukius 0]

А что у блекфина нету кеша на каждом ядре, кеш должен все это компенсировать.

 

кэши, безусловно есть и они в данной задаче включены. Но подсасывание в/из кэшей из/в SDRAM происходит-же ;)

 

на периферию буфера нет (как например в АРМ9), шина одна

 

вот мне и интересно, насколько сильно будет загружена шина и как её разгрузить, чтобы одновременность не потерять :)

[sysel 0]

Попробуте подсчитать сами:

1) Вам, думаю, известено количество записей в LCD в секунду

2) Вы задаёте настройки внешней шины для доступа к банку ассинхронной памяти (куда у Вас LCD прикручен). Т.о. Вы знаете, за сколько тактов системного клока будет происходить одна операция записи.

 

3) перемножаете величины из пункта 1 и пункта 2.

 

Получаете количественную оценку съедаемого записью в LCD времени шины

 

 

Второе ядро зачем? Чтоб палитру разруливать?

[denebopetukius 0]

Второе ядро зачем? Чтоб палитру разруливать?

 

да вот надо со вторым ядром что-то делать, а то обидно, что будет простаивать ничего не делая :)

 

в LCD можно писать 16-битным словом - 1 пиксель

или 32-битным словом - 2 пикселя сразу

 

ширина строба записи в LCD - 4 такта системной шины (133 MHz), остальные - по 1 такту

 

итого 133/(1+4+1)=оклоло 20 МГц

 

что б такое на 2-е ядро привешать?

[sysel 0]

что б такое на 2-е ядро привешать?

Ну если задача - эмулятор приставок, то второе ядро можно задействовать под звуковой синтезатор (выполнять функции того аппартного синтезатора, что у Вас к БФ532 привешан), чтобы старшие товарищи больше не нападали.

[denebopetukius 0]

Ну если задача - эмулятор приставок, то второе ядро можно задействовать под звуковой синтезатор (выполнять функции того аппартного синтезатора, что у Вас к БФ532 привешан), чтобы старшие товарищи больше не нападали.

 

хорошая мысль :rolleyes:

 

а вот мне ещё подумалось на второе ядро повешать процессинг звука и опрос джойстика. Оба требуют работы по прерыванию.

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

 

допускается ли работа обеих ядер одновременно с EBIU (одно ядро посылает кадр в LCD, второе читает код/данные из SDRAM в кэши)?

[blackfin 22]

..одно ядро посылает кадр в LCD,..

А зачем это? Есть же четыре контроллера MDMA они и должны "посылать кадр в LCD"..

Ядро при этом практически не участвует..

[sysel 0]

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

Ну для передачи в аудиокодек есть SPORT, который прекрасно вяжется с многоми аудиокодеками (собственно для работы с ними он и заточен). Передача через DMA, естественно.

 

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

допускается ли работа обеих ядер одновременно с EBIU (одно ядро посылает кадр в LCD, второе читает код/данные из SDRAM в кэши)?

А почему бы и нет? В данном случае EBIU будет разделяемым ресурсом.

У блекфинов есть буфера данных между ядром и переферией (куда EBIU тоже входит).

Если, допустим первое ядро без передышки пишет/читает SDRAM, а второе ядро пишет что-то в LCD, то пока не заполниться буфер данных второго ядра или не будет выполнена инструкция ssync, второе ядро будет работать. Как только буфер данных второго ядра заполниться или будет вызвана ssync, второе ядро погрузиться в ожидание освобождения места в буфере (т.е. пока часть данных уйдёт в LCD) или в случае ssync будет ждать полного сбрасывания буфера в LCD.

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

Аналогично, когда будет заполнение буфера первого ядра или команда ssync, оно погрузиться в ожидание.

 

На кого работает EBIU, когда оба ядра ожидают его, не знаю.

 

А зачем это? Есть же четыре контроллера MDMA они и должны "посылать кадр в LCD"..

Ядро при этом практически не участвует..

Товарищ работает с палитрой, а контроллер LCD хочет получать rgb для каждой точки. В контролле LCD нет поддержки палитры.

[blackfin 22]

Товарищ работает с палитрой, а контроллер LCD хочет получать rgb для каждой точки. В контролле LCD нет поддержки палитры.

Вот поэтому и надо переходить на BF547.. Пока не поздно.. ;)

[sysel 0]

Вот поэтому и надо переходить на BF547.. Пока не поздно.. ;)

Сейчас отошел от темы блекфинов, поэтому прошу вкатце просветить меня, что же в БФ547 появилось для решения этой задачи

[vik0 0]

P.S. PPI НЕ предлагать!

Объясните, все-таки, почему?

На кого работает EBIU, когда оба ядра ожидают его, не знаю.

На первое ядро

Товарищ работает с палитрой, а контроллер LCD хочет получать rgb для каждой точки. В контролле LCD нет поддержки палитры.

А кто мешает сформировать rgb буфер в l2 памяти и его по dma отправлять на LCD? А в это время формировать палитровый буфер нового кадра (к примеру).

[denebopetukius 0]

Объясните, все-таки, почему?

 

потому что:

 

1) на руках дисплей со встроенным контроллером

2) требуется получить много вариантов экзотических разрешений: от 160x144 до 320x240

3) не хочу тратить ресурсы на развертку кадра (эмуляция без прорисовки сжирает времени почти столько же, что и прорисовка экрана)

4) частота обновления дисплея должна быть 60 Hz

 

А кто мешает сформировать rgb буфер в l2 памяти и его по dma отправлять на LCD? А в это время формировать палитровый буфер нового кадра (к примеру).

 

Plane1, Plane2, Sprite0, Sprite1 => все эти 4 слоя рисуются во внутреннем буфере по-очереди в 8-битном разрешении. Лишь только потом они идут в палитру и рисуются в direct-RGB на дисплее

 

делал сразу 4 прорисовки без палитры в буфер - намного медленее.

 

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

 

Вот поэтому и надо переходить на BF547.. Пока не поздно.. ;)

 

небось все фичи на PPI? ;)

Изменено 30 июня, 2009 пользователем denebopetukius

[blackfin 22]

небось все фичи на PPI? ;)

Если кратко, то так:

 

Фичи связанные с графикой реализованы в отдельном модуле, который называется - Pixel Compositor.

С модулем работают три 32-битных канала DMA - два на входе модуля, один на выходе.

Используя одновременно все три канала DMA, Pixel Compositor выполняет преобразование двух изображений на входе (из L1, или L2, или L3) и получает новое изображение на выходе (в L1, или L2, или L3) по одной из формул:

 

OUT_IMAGE(YUV422) = MAIN_IMAGE(YUV422)*(15-alfa)/16 + OVERLAY_IMAGE(YUV422)*(1+alfa)/16, или

OUT_IMAGE(RGB888) = MAIN_IMAGE(YUV422)*(15-alfa)/16 + OVERLAY_IMAGE(YUV422)*(1+alfa)/16, или

OUT_IMAGE(YUV422) = MAIN_IMAGE(RGB888)*(15-alfa)/16 + OVERLAY_IMAGE(RGB888)*(1+alfa)/16, или

OUT_IMAGE(RGB888) = MAIN_IMAGE(RGB888)*(15-alfa)/16 + OVERLAY_IMAGE(RGB888)*(1+alfa)/16.

 

OVERLAY_IMAGE может быть расположен в любом месте MAIN_IMAGE и может иметь заранее заданный размер,

но меньший или равный MAIN_IMAGE.

 

Если нужен вывод на LCD, Pixel Compositor может одновременно выполнить преобразование:

RGB888 -> RGB666 или RGB888 -> RGB565.

Если нужен вывод на TV, Pixel Compositor может одновременно выполнить преобразование:

YUV422 ->YUV444.

 

Есть ещё и PPI. Их три штуки, но все они разной разрядности (8,16,24) и частично перекрываются по пинам.

Работают на частоте < 75 МГц. К ним тоже можно прицепить три 32-битных канала DMA, причем, если PPI1 или PPI2 не используется, то с оставшимся модулем PPI может работать сразу два канала DMA, что удобно при распаковке или упаковке видео в формате YUV.

 

И всё это практически без участия процессора.

[denebopetukius 0]

всеравно не то.

 

попытаюсь более понятнее объяснить.

 

u16 PALETTE[256]; //массив палитры (виртуальная палитра)

 

u8 VideoBuffer[256*256]; //видеобуфер

 

//Отрисовки в буфер

 

VideoBuffer=Sprite0[]; //Спрайты за плоскостью

VideoBuffer=Plane0[]; //Плоскость 0

VideoBuffer=Plane0[]; //Плоскость 1

VideoBuffer=Sprite1[]; // Спрайты перед плоскостью

 

//Передача буфера на дисплей (с учётом виртуальной палитры)

 

LCD_Data=PALETTE[VideoBuffer];

 

Спрайты и плоскости рисуются построчно в буфере, чтобы учесть видеоэффекты, которые могут возникнуть при обратном ходе луча ПО СТРОКЕ (изменение палитры например!!!).

 

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