[aaarrr 69]

Вы же писали:

0x00200С00 - периферия(дисплей) не кешируется и не буферизуется

[axa09 0]

А разве можно буферизовать дисплей(его регистры)?

ведь кадр искривится и будет мусор!

или я чего-то ещё не сделал?

[aaarrr 69]

ведь кадр искривится и будет мусор!

Почему искривится и откуда возьмется мусор?

[axa09 0]

Разобрался!

Мусор возникал из-за неверной времянки дисплея-пришлось подправить-увеличил RWSETUP=6, раньше было 0.

для дисплея удалось поставить биты buferable и cachable! регистры внутренней периферии(spi, pio) тоже забуферизовал, а вот закешировать не удалось-повисает.

может я сделал что-то лишнее? или вредное?

 

это подняло производительность всей программы на 11 %

 

дополнительно разогнал до 206мгц, шина 103,память с nws=0 !!!

гонял час- стабильно!(требуется работа устройства при комнатной температуре )

 

итого производительность всей программы возросла на 18%

[aaarrr 69]

для дисплея удалось поставить биты buferable и cachable! регистры внутренней периферии(spi, pio) тоже забуферизовал, а вот закешировать не удалось-повисает.

может я сделал что-то лишнее? или вредное?

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

[axa09 0]

тоесть оставить только buferable для регистров внешней периферии( на EBI)

и убрать оба (cachable, buferable) у регистров внутреней периферии(spi, pio), так?

 

кстати,заметил, что один cachable для регистров дисплея тоже ведёт к повышению скорости обмена с индикатором- почему?

[aaarrr 69]

тоесть оставить только buferable для регистров внешней периферии( на EBI)

и убрать оба (cachable, buferable) у регистров внутреней периферии(spi, pio), так?

Так.

 

кстати,заметил, что один cachable для регистров дисплея тоже ведёт к повышению скорости обмена с индикатором- почему?

Потому что это режим write-through cache, и буфер записи все равно включен.

[axa09 0]

Спасибо за ответы!

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

проснулся чисто спортивно-исследовательский интерес- можно ли ещё ускорить процесс фильтра, например написать на ассемблере код фильтра? или лучше, чем сделает Си-компилер,уже не сделать?

или принудительно работать со строками кэша? чтобы уменьшить промахи. кстати, как сделать префетч?

где можно найти внятную инфу про кэши и их управление, с примерами пересылки данных?

[aaarrr 69]

проснулся чисто спортивно-исследовательский интерес- можно ли ещё ускорить процесс фильтра, например написать на ассемблере код фильтра? или лучше, чем сделает Си-компилер,уже не сделать?

Что-то улучшить всегда можно. Но начинать стоит с самого алгоритма, соревноваться с RealView в плане скорости кода довольно трудно.

 

или принудительно работать со строками кэша? чтобы уменьшить промахи. кстати, как сделать префетч?

где можно найти внятную инфу про кэши и их управление, с примерами пересылки данных?

Prefetch для DCache можно сделать, выполнив последовательно чтение с интервалом, кратным размеру строки кэша (8 слов для ARM920T). Для ICache есть специальная инструкция.

Внятную информацию лучше всего брать из Technical Reference Manual (с примерами там только туго).

[Rst7 5]

проснулся чисто спортивно-исследовательский интерес

 

Это полезно ;)

 

А какая у Вас в основном работа идет с пикселями исходного изображения? Имеется в виду - попиксельно или группами (блоками)?

 

Если попиксельно - рассмотрите вопрос о хранении пикселей исходной картинки, например, в виде 00rrr00ggg00bb00, по 16 бит на пиксель (конечно, буфер экрана будет весить в 2 раза больше). Тогда операцию усреднения можно выполнять сразу над пикселями и обращений к таблице будет намного меньше. Нечто такое:

void foo(volatile unsigned char *dst, unsigned int *src)
{
  unsigned int t;
  //Пиксели по *src хранятся в виде
  //00rrr00ggg00bb00
  t=src[64];
  t+=*src++;
  t+=t<<16;
  //Имеем после сложения четырех пикселей
  //rrrxxgggxxbbxx00----------------
  
  //По таблице конвертируем r- и g-составляющую в rrrggg00, а составляющую b обрабатываем банальным сдвигом
  *dst=pal[t>>24]|((t>>20)&3);
  
  //Повторяем
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
  t=src[64];t+=*src++;t+=t<<16;*dst=pal[t>>24]|((t>>20)&3);
}

 

В результате, одна итерация выглядит так (после IAR'а)

   \   0000002C   002193E5           LDR      R2,[R3, #+256]
   \   00000030   04C093E4           LDR      R12,[R3], #+4
   \   00000034   02208CE0           ADD      R2,R12,R2
   \   00000038   022882E0           ADD      R2,R2,R2, LSL #+16
   \   0000003C   22CCD1E7           LDRB     R12,[R1, +R2, LSR #+24]
   \   00000040   222AA0E1           LSR      R2,R2,#+20
   \   00000044   032002E2           AND      R2,R2,#0x3
   \   00000048   0C2082E1           ORR      R2,R2,R12
   \   0000004C   0020C0E5           STRB     R2,[R0, #+0]

 

Вроде ниче не напутал.

[axa09 0]

если нетрудно,напишите пожалуйста фрагмент кода на Си для работы с префетчем.

я понял это так:

читаем 8 последовательных 32-битных слов, сделав перед этим префетч с начального адреса где лежат слова, я не напутал?

 

напишите плиз ещё асм-код самого префетча.

 

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

[aaarrr 69]

читаем 8 последовательных 32-битных слов, сделав перед этим префетч с начального адреса где лежат слова, я не напутал?

Напутали, похоже:

1. Располагаем данные так, чтобы начало было выровнено по границе 8-ми слов.

2. Читаем слово 0, затем слово 8, затем 16 и т.д. На каждом чтении происходит загрузка строки кэша.

 

напишите плиз ещё асм-код самого префетча.

ICache prefetch:

MCR p15, 0, Rd, c7, c13, 1

 

А описание можете прочитать в TRM :)

[axa09 0]

Спасибо за ответы! :)

 

В той же программе оптимизирую другой кусок кода.

 

Есть функция, которая заполняет буфер 32 байта. Этот буфер требуется переслать по SPI периферийному устройству, которое имеет внутренний аппаратный буфер.

Периферийное устройство шлет внешнее прерывание контроллеру когда нужна порция данных в аппаратный буфер.

 

Сейчас сделано так:

в обработчике прерывания циклом засылаю в SPI Data register по-очереди все 32 байта. После передачи каждого байта тупо жду. На последнем 31-м шаге цикла перед опросом состояния вызываю функцию постройки нового буфера 32 байт, в надежде потратить время на постройку буфера.

 

Но к сожалению времени иногда не хватает, а на первых 31 шагах цикла время теряется на тупой опрос состояния занятости SPI.

 

Ядро 200мгц, SPI клок 8мгц (ограничение периферийного устройства).

Вот я и прикинул : 200/(8/8/32) = 6400 тактов теряем впустую - а ведь можно было это время потратить целиком на построение буфера.

 

Значит надо использовать DMA.

 

Псевдокод обработчика прерывания:

 

__irq void SebdData(void)

{

static u32 i=0;

DMA_Send(Buffer,32); //посылаем в DMA первый буфер Buffer[0] - 32 байта

CreatePacket(Buffer[i^1]); //строим второй Buffer[1] - 32 байта

i^=1; //переворачиваем для того чтоб обменять первый и второй буферы местами для следующего раза

AIC_EOI=0; // конец перывания

}

 

в силу специфики системы использую SPI с указанием NPCS в регистре SPI_TDR (регистр передачи)

тоесть :

 

SPI_TDR=(номер NPCS<< на сколько-то бит)|Data;

 

вопрос, как организовать пересылку по DMA?

кеши у меня включены оба.

 

где-то читал, что с SPI+DMA заморочки по поводу буферов - нужно тратить все 32 бита для того чтоб отправить в SPI.

 

помогите пожалуйста с DMA в моем случае!

 

что должно быть в буфере, который должен съесть DMA? (формат). Для моего случая

 

буфер приёма тоже должен быть? и при DMA-передаче должен быть ещё прием, так?

 

если можно, то напишите Си-кодом плиз.

Изменено 26 февраля, 2009 пользователем axa09

[axa09 0]

если текущий режим spi не подходит, можно сменить на fixed mode, получив возможность организовывать 8-битный буфер без лишнего.

 

для ДМА нужен некешируемый кусок памяти,так?

появилась идея внутреннюю срам закэшировать по адресу 0х00000000-для векторов прерываний и др. нужд.

та же память, но доступная по адресу 0х00200000-не кешировать- для ДМА.

 

Получится ли так использовать внутренюю срам чтоб кешировалась при обращении к ней по первому адресу и не кешировалось по второму?

если да, то remap- forever ;)

 

p.s. не хочу заводить ТТВ второго уровня (4кб страницы) или гробить 1мб памяти для каких-то 32 байт для ДМА.

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

[aaarrr 69]

Получится ли так использовать внутренюю срам чтоб кешировалась при обращении к ней по первому адресу и не кешировалось по второму?

Получится. Нужно только не смешивать кэшируемые и некэшируемые области при работе.