контроллер at91rm9200. частота ядра 180мгц, шина 60мгц. на шине статическая память с 16-битной шиной, с NWS=0(без дополнительных тактов). кеши оба включены-память закеширована write-back, в ней исполняется программа.
обработчики прерываний в этой памяти.

вопрос-
если обработчики разместить во внутренней sram контроллера,будет ли выигрыш в производительности?
или с кешами это не принципиально?
как обработчик прерывания в keil скопировать из одной памяти в другую с учётом коррекции счётчика адреса(РС?)

И ещё-пробовал стек делать во внутренней памяти - на глаз быстродействие не изменилось

Вы же писали:

А разве можно буферизовать дисплей(его регистры)?
ведь кадр искривится и будет мусор!
или я чего-то ещё не сделал?

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

Разобрался!
Мусор возникал из-за неверной времянки дисплея-пришлось подправить-увеличил RWSETUP=6, раньше было 0.
для дисплея удалось поставить биты buferable и cachable! регистры внутренней периферии(spi, pio) тоже забуферизовал, а вот закешировать не удалось-повисает.
может я сделал что-то лишнее? или вредное?

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

дополнительно разогнал до 206мгц, шина 103,память с nws=0 !!!
гонял час- стабильно!(требуется работа устройства при комнатной температуре )

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

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

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

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

Так.


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

Спасибо за ответы!
в целом меня устраивает производительность программы сейчас.
проснулся чисто спортивно-исследовательский интерес- можно ли ещё ускорить процесс фильтра, например написать на ассемблере код фильтра? или лучше, чем сделает Си-компилер,уже не сделать?
или принудительно работать со строками кэша? чтобы уменьшить промахи. кстати, как сделать префетч?
где можно найти внятную инфу про кэши и их управление, с примерами пересылки данных?

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


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

Это полезно

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

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


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


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

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

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

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

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


ICache prefetch:
MCR p15, 0, Rd, c7, c13, 1

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

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

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

Есть функция, которая заполняет буфер 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[i],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-передаче должен быть ещё прием, так?

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

Сообщение отредактировал axa09 - Feb 26 2009, 01:36

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

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

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

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

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