Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Bопрос по АРМ9
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
axa09
Feb 22 2009, 00:03
контроллер at91rm9200. частота ядра 180мгц, шина 60мгц. на шине статическая память с 16-битной шиной, с NWS=0(без дополнительных тактов). кеши оба включены-память закеширована write-back, в ней исполняется программа.
обработчики прерываний в этой памяти.

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

И ещё-пробовал стек делать во внутренней памяти - на глаз быстродействие не изменилось sad.gif
aaarrr
Feb 22 2009, 14:14
Цитата(axa09 @ Feb 22 2009, 03:03) *
вопрос-
если обработчики разместить во внутренней sram контроллера,будет ли выигрыш в производительности?
или с кешами это не принципиально?

Теоретически выигрыш может быть, так как внутренняя память все же быстрее. На практике все зависит от конкретного случая.

Цитата(axa09 @ Feb 22 2009, 03:03) *
как обработчик прерывания в keil скопировать из одной памяти в другую с учётом коррекции счётчика адреса(РС?)

А зачем? Не проще его сразу по нужному адресу положить?

Цитата(axa09 @ Feb 22 2009, 03:03) *
И ещё-пробовал стек делать во внутренней памяти - на глаз быстродействие не изменилось sad.gif

Значит, в вашей программе не так уж часто нужен стек.
sergeeff
Feb 22 2009, 15:46
Цитата(axa09 @ Feb 22 2009, 03:03) *
контроллер at91rm9200. частота ядра 180мгц, шина 60мгц. на шине статическая память с 16-битной шиной, с NWS=0(без дополнительных тактов). кеши оба включены-память закеширована write-back, в ней исполняется программа.
обработчики прерываний в этой памяти.

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

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


Кеш работает с такой же частотой, что и внутренняя SRAM. Посему разница ничтожна. А стек в ARM'ах задействуется не столь часто, только когда не хватает внутренних регистров. К тому же современные компиляторы стараются оптимизировать скорость выполнения потока команд, учитывая pipeline.
axa09
Feb 22 2009, 22:48
За ответы спасибо!
с праздником!

можно повысить производительность системы путём манипуляций с кешами?
сейчас таблица трансляции адресов(по 1мб) находится в кешируемой области внешней памяти. вся память кроме регистров кешируема и буферизована(биты cachable и buferable равны 1). кеш асинхронный.
подскажите дальнейшие пути повышения производительности:
1)при выполнении кода
2)при блочном чтении из памяти
3)при блочной записи в память
слышал, что перед передачей данных надо втыкать prefetch. можно по-подробнее?
есть ещё invalidate,flush и др. как их пользовать?

извините за кашу в голове- просто хочется разобраться, помогите плиз.
aaarrr
Feb 22 2009, 23:09
Цитата(axa09 @ Feb 23 2009, 01:48) *
можно повысить производительность системы путём манипуляций с кешами?

Можно, но не в разы. Судя по описанию, ваша система и так правильно настроена.
Заниматься тюнингом производительности следует только при наличии насущной необходимости. Она есть?

Цитата(axa09 @ Feb 23 2009, 01:48) *
сейчас таблица трансляции адресов(по 1мб) находится в кешируемой области внешней памяти.

Напрасно.

Цитата(axa09 @ Feb 23 2009, 01:48) *
кеш асинхронный

Режим тактирования имеется в виду?
axa09
Feb 22 2009, 23:26
Надо хотябы на 25% повысить.
почему напрасно?
как правильно и на что влияет?

ДА! режим тактирования имел ввиду.
aaarrr
Feb 22 2009, 23:32
Цитата(axa09 @ Feb 23 2009, 02:26) *
Надо хотябы на 25% повысить.

Повысить для каких условий? Если у Вас есть некая функция, которую необходимо ускорить, то оптимизацию следует начинать с ее кода, а уж в последнюю очередь пытаться оптимизировать работу кэша.
Просто повысить производительность системы на 25% невозможно.

Цитата(axa09 @ Feb 23 2009, 02:26) *
почему напрасно?

Потому что выборки из таблицы трансляции не идут через кэш. Расположение таблицы ни на что не влияет.
sergeeff
Feb 23 2009, 00:15
Цитата(axa09 @ Feb 23 2009, 01:48) *
За ответы спасибо!
с праздником!

можно повысить производительность системы путём манипуляций с кешами?
сейчас таблица трансляции адресов(по 1мб) находится в кешируемой области внешней памяти. вся память кроме регистров кешируема и буферизована(биты cachable и buferable равны 1). кеш асинхронный.
подскажите дальнейшие пути повышения производительности:
1)при выполнении кода
2)при блочном чтении из памяти
3)при блочной записи в память
слышал, что перед передачей данных надо втыкать prefetch. можно по-подробнее?
есть ещё invalidate,flush и др. как их пользовать?

извините за кашу в голове- просто хочется разобраться, помогите плиз.


Да уж конечно надо смотреть в сторону собственно обработчика прерываний. Что за скорость то нужна, если 180 МГц rm9200 не хватает?
axa09
Feb 23 2009, 00:19
Нужно ускорить переброс видеобуфера в дисплейную память(шина 8 бит, на ebi, i80).
тоесть если таблица трансляции расположена в кешируемой внешней памяти, то память не будет кешироваться?
и доступ к таблице будет медленным?
нужно ли кешировать внутреннюю память-срам 16кб?
где правильнее расположить таблицу трансляции?
aaarrr
Feb 23 2009, 00:34
Цитата(axa09 @ Feb 23 2009, 03:19) *
Нужно ускорить переброс видеобуфера в дисплейную память(шина 8 бит, на ebi, i80).

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

Цитата(axa09 @ Feb 23 2009, 03:19) *
тоесть если таблица трансляции расположена в кешируемой внешней памяти, то память не будет кешироваться?
и доступ к таблице будет медленным?

Будет, не волнуйтесь. Просто располагать ее в кэшируемой памяти нет смысла.

Цитата(axa09 @ Feb 23 2009, 03:19) *
нужно ли кешировать внутреннюю память-срам 16кб?

Нужно.

Цитата(axa09 @ Feb 23 2009, 03:19) *
где правильнее расположить таблицу трансляции?

В наиболее скоростной памяти. Но гробить под нее всю внутреннюю SRAM не стоит.
axa09
Feb 23 2009, 01:28
Пришла в голову мысль расположить таблицу во внутренней sram.
затрутся только reset, undef и swint.
irq, fiq останутся!
таблица у меня сильно фрагментирована.
тоесть во внутренней срам будут вектора прерываний, стек и таблица трансляции адресов!
отпишусь когда сделаю!
я- великий извращенец! wink.gif
AndrewN
Feb 23 2009, 06:16
Цитата(axa09 @ Feb 23 2009, 02:48) *
таблица трансляции адресов (по 1мб)

Подскажите пожалуйста, что это такое; где про это можно почитать и где
можно посмотреть какой-нибудь примерчик.

За ответы спасибо.
С праздником.
axa09
Feb 23 2009, 07:45
В общем удалось ради эксперимента таблицу запихать во внутреннюю срам.
прироста в скорости не дало sad.gif
по ходу больше никак не выжать.

вот собственно задача:
есть буфер MxN байт- индексов другого массива(палитра).
требуется находить средние интенсивности компонент цвета из 4-х смежных точек(2х2 пиксела). короче,некое подобие фильтра при уменьшении картинки в два раза.
как можно сделать быстрее?
буфера во внешней памяти
sergeeff
Feb 23 2009, 10:58
Цитата(AndrewN @ Feb 23 2009, 09:16) *
Подскажите пожалуйста, что это такое; где про это можно почитать и где
можно посмотреть какой-нибудь примерчик.

За ответы спасибо.
С праздником.


Удивительное нежелание хотя бы на местном форуме сначала поискать, а потом уже вопрос вываливать! По принципу - пусть другие мне готовое на тарелочке преподнесут.

Смотри http://electronix.ru/forum/index.php?showt...&hl=d-cache
aaarrr
Feb 23 2009, 12:22
Цитата(axa09 @ Feb 23 2009, 10:45) *
прироста в скорости не дало sad.gif

И не должно было. Таблица буферизируется через TLB, чего в нормальной жизни вполне достаточно.

Цитата(axa09 @ Feb 23 2009, 10:45) *
вот собственно задача:

Можно поподробнее? Чему равны M и N, что из себя представляет палитра, какие требования к скорости?
sergeeff
Feb 23 2009, 13:02
Цитата(axa09 @ Feb 23 2009, 10:45) *
В общем удалось ради эксперимента таблицу запихать во внутреннюю срам.
прироста в скорости не дало sad.gif
по ходу больше никак не выжать.

вот собственно задача:
есть буфер MxN байт- индексов другого массива(палитра).
требуется находить средние интенсивности компонент цвета из 4-х смежных точек(2х2 пиксела). короче,некое подобие фильтра при уменьшении картинки в два раза.
как можно сделать быстрее?
буфера во внешней памяти


Даже любопытно, как удалось 16 KB'ую таблицу запихнуть в 16 KB'ую SRAM и сохранить в ней таблицу векторов прерываний?
axa09
Feb 23 2009, 13:32
Цитата(sergeeff @ Feb 23 2009, 04:02) *
Даже любопытно, как удалось 16 KB'ую таблицу запихнуть в 16 KB'ую SRAM и сохранить в ней таблицу векторов прерываний?



все просто. прикиньте сами:
0x00000000 - внутренняя SRAM после ReMap - отхавает RESET(вектор 0)
0x00100000 - внутренний ROM - отхавает Undef (вектор 1)
0x00200000 - внутренняя SRAM всегда - отхавает SWInt (вектор 2)

далее не затираем. Поэтому IRQ и FIQ целые. Остальные не пользуем wink.gif

0x00200400 - первый мегабайт SRAM (NCS0)
0x00200404 - второй мегабайт SRAM
итд...
0x00200С00 - периферия(дисплей) не кешируется и не буферизуется
...
стек в конце


О задаче по -подробнее:


//Буфер 256x240 исходного изобржения. Элемент -байт - индекс массива палитры
extern uint8 *Buf;

//Палитра. Каждый элемент 00rrr00ggg00bb- нули для того чтобы при сложении 4-х цветов небыло переполнения.
u16 PALETTE[256];

/*
256

1212121212..
3434343434..
1212121212.. 240
3434343434..
............
*/

/*
Далее ниже находим "средний пиксел"(среднее арифметическое каждой интенсивности R,G,cool.gif
Для этого складываем все компоненты смежных пикселов "1"+"2"+"3"+"4"
Потом сдвигами и битовыми "И" приводим к виду RRrGGgBB = R:G:B=>3:3:2
И отправляем байт в дисплей (шина EBI,8бит, автоинкремент адреса, 128x120 авто-скругление по кадру)
*/

#define Pixel \
c =PALETTE[*(u8*) Buf ]; \
c+=PALETTE[*(u8*)(Buf+ 1)]; \
c+=PALETTE[*(u8*)(Buf+256)]; \
c+=PALETTE[*(u8*)(Buf+257)]; \
Display_Data_Register=((c>>2)&0x03)|((c>>4)&0x1C)|((c>>6)&0xE0); \
Buf+=2;

void BlitScreen(u8 *Buf) //Отрисовка экрана
{
register u32 y,BufE,c;
for(y=0;y<120;y++)
{
BufE=(u32)Buf+256;
for(;(u32)Buf<BufE;)
{
Pixel
Pixel
Pixel
Pixel
}
Buf+=256;
}
}

//Таким образом изображение 256x240 ужимаем в 128x120 с применением палитры(конвертируем цвета)
// и "фильтра"(среднее значение компонент смежных пикселей 2x2)

Как можно оптимизировать быстрее??? На ассемблере?
aaarrr
Feb 23 2009, 14:28
Цитата(axa09 @ Feb 23 2009, 16:32) *
Как можно оптимизировать быстрее??? На ассемблере?

Можно сначала попробовать соптимизировать чтение - читать данные 32-бит словами, сразу для двух блоков 2x2.
Ну, и листинг не грех посмотреть.
axa09
Feb 23 2009, 14:47
У меня память 16 бит шина данных. всёравно по 32 бита читать?
листинг смотрел-быстрее тот вариант, который с меньшим количеством обращений к памяти(операнды в квадратных скобках)
и всё-же, предложите свой вариант который,возможно, быстрее wink.gif
sergeeff
Feb 23 2009, 14:56
Цитата
0x00200400 - первый мегабайт SRAM (NCS0)


Значит 16 КБ таблица пишется с начальным смещением в 1 КБ в память объемом 16 КБ и там еще место под стек осталось? Так не бывает.
aaarrr
Feb 23 2009, 15:03
Цитата(axa09 @ Feb 23 2009, 17:47) *
У меня память 16 бит шина данных. всёравно по 32 бита читать?

Вы все равно уже читаете кэш.

Цитата(axa09 @ Feb 23 2009, 17:47) *
и всё-же, предложите свой вариант который,возможно, быстрее wink.gif

Сколько занимает по времени этот вариант?
axa09
Feb 23 2009, 15:14
Вариант идёт с 45 преобразований/с. но это не чисто- ещё много другого в цикле делается(не путать с циклом отрисовки!)

по таблице. не надо все 16кб заполнять!
надо только память и периферию. остальное не имеет значение-всёравно обращений по этим адресам не будет!
aaarrr
Feb 23 2009, 15:41
Цитата(axa09 @ Feb 23 2009, 18:14) *
Вариант идёт с 45 преобразований/с. но это не чисто- ещё много другого в цикле делается(не путать с циклом отрисовки!)

Т.е. не измеряли что ли?

CODE

#define Pixel \
a = Bufw[0]; \
b = Bufw[64]; \
c = PALETTE[a & 0xff]; \
c += PALETTE[(a >> 8) & 0xff]; \
c += PALETTE[b & 0xff]; \
c += PALETTE[(b >> 8) & 0xff]; \
Display_Data_Register=((c>>2)&0x03)|((c>>4)&0x1C)|((c>>6)&0xE0); \
c = PALETTE[(a >> 16) & 0xff]; \
c += PALETTE[(a >> 24) & 0xff]; \
c += PALETTE[(b >> 16) & 0xff]; \
c += PALETTE[(b >> 24) & 0xff]; \
Display_Data_Register=((c>>2)&0x03)|((c>>4)&0x1C)|((c>>6)&0xE0); \
Bufw++;


void BlitScreen(u8 *Buf)
{
u32 *Bufw = (u32*)Buf, a, b, c, y, x;
for(y = 0; y < 120; y++)
{
for(x = 0; x < 64 / 4; x++)
{
Pixel
Pixel
Pixel
Pixel
}
Bufw += 64;
}
}

25% не обещаю, но 15 точно должно быть. Buf должен быть выровнен по границе слова.
Только вот процедурка и в исходном виде достаточно короткая (меньше 5мс).
sergeeff
Feb 23 2009, 16:14
Совет. Длительность CS для вывода на дисплей соответствует тому, что минимально необходимо?
axa09
Feb 23 2009, 21:30
Спасибо! как проверю-напишу результаты и приведу асм-листинг обеих вариантов.

времянки дисплея выставлены максимально короткими.
любопытно,что повышение частоты шины не ведёт к увеличению итоговой производительности. а вот оверклочение ядра с 180 на 200 на глаз ощутимо повышением скорости выполнения программы!
axa09
Feb 24 2009, 10:45
Цитата(aaarrr @ Feb 23 2009, 07:41) *
Т.е. не измеряли что ли?

25% не обещаю, но 15 точно должно быть. Buf должен быть выровнен по границе слова.
Только вот процедурка и в исходном виде достаточно короткая (меньше 5мс).


В общем сегодня замерил свой и ваш варианты. Мой 206 FPS, ваш 203 FPS. Я даже расстроился sad.gif
Листинги вложил сюда.

На всякий случай сообщаю настройки компилятора:
Keil Real View v3.3
Code generation: ARM-Mode
Use cross-module optimization

C compiler:
enable arm/thumb intervorking
optimization level 2 (-02)
optimize for time

ASM:
enable ARM/thumb interworking

Дополнительные ключи C компилятора:
--pointer_alignment=8
--min_array_alignment=8
--no_vfe

замерял производительность с двумя вариантами стеков: во внутренней срам и во внешней - тоже самое все.
пробовал PALETTE[] расположить во внутренней срам- тоже ничего не поменялось.

листинги решил вложить, так как вымахали большими.

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

в общем посмотрите плиз.
может что-то лишнее и вредное в настройках включено?
или надо что-то добавить?

если нетрудно, приведите плиз асм-код .
aaarrr
Feb 24 2009, 14:32
Запись во внешний медленный порт сильно портит все дело. Вот что получилось у меня (RVDS 2.2, полная оптимизация по скорости):

1. Без записи в порт, вместо регистра пишем кэшируемую память.
Ваш вариант 334 FPS, мой - 397 FPS. Разница заметна.

2. С записью в порт.
Ваш вариант - 215 FPS, мой - 221 FPS. Практически одинаково.

CODE

BlitScreen
$a
.text
0x00000000: e92d07f0 ..-. PUSH {r4-r10}
0x00000004: e1a03000 .0.. MOV r3,r0
0x00000008: e59f03f4 .... LDR r0,[pc,#1012] ; [.bss$5 = 0x404] = 0
0x0000000c: e3a0a000 .... MOV r10,#0
0x00000010: e3a06202 .b.. MOV r6,#0x20000000
0x00000014: e3a050e0 .P.. MOV r5,#0xe0
0x00000018: e3a0401c .@.. MOV r4,#0x1c
0x0000001c: e3a07000 .p.. MOV r7,#0
0x00000020: e5931000 .... LDR r1,[r3,#0]
0x00000024: e5932100 .!.. LDR r2,[r3,#0x100]
0x00000028: e201c0ff .... AND r12,r1,#0xff
0x0000002c: e2018cff .... AND r8,r1,#0xff00
0x00000030: e08083a8 .... ADD r8,r0,r8,LSR #7
0x00000034: e080c08c .... ADD r12,r0,r12,LSL #1
0x00000038: e1dcc0b0 .... LDRH r12,[r12,#0]
0x0000003c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000040: e088c00c .... ADD r12,r8,r12
0x00000044: e20280ff .... AND r8,r2,#0xff
0x00000048: e0808088 .... ADD r8,r0,r8,LSL #1
0x0000004c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000050: e088c00c .... ADD r12,r8,r12
0x00000054: e2028cff .... AND r8,r2,#0xff00
0x00000058: e08083a8 .... ADD r8,r0,r8,LSR #7
0x0000005c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000060: e088c00c .... ADD r12,r8,r12
0x00000064: e004822c ,... AND r8,r4,r12,LSR #4
0x00000068: e1a09e0c .... LSL r9,r12,#28
0x0000006c: e1888f29 )... ORR r8,r8,r9,LSR #30
0x00000070: e005c32c ,... AND r12,r5,r12,LSR #6
0x00000074: e188c00c .... ORR r12,r8,r12
0x00000078: e5c6c007 .... STRB r12,[r6,#7]
0x0000007c: e201c8ff .... AND r12,r1,#0xff0000
0x00000080: e1a01c21 !... LSR r1,r1,#24
0x00000084: e0801081 .... ADD r1,r0,r1,LSL #1
0x00000088: e080c7ac .... ADD r12,r0,r12,LSR #15
0x0000008c: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000090: e1d110b0 .... LDRH r1,[r1,#0]
0x00000094: e081100c .... ADD r1,r1,r12
0x00000098: e202c8ff .... AND r12,r2,#0xff0000
0x0000009c: e080c7ac .... ADD r12,r0,r12,LSR #15
0x000000a0: e1a02c22 ",.. LSR r2,r2,#24
0x000000a4: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000000a8: e0802082 . .. ADD r2,r0,r2,LSL #1
0x000000ac: e1d220b0 . .. LDRH r2,[r2,#0]
0x000000b0: e08c1001 .... ADD r1,r12,r1
0x000000b4: e0821001 .... ADD r1,r2,r1
0x000000b8: e0042221 !".. AND r2,r4,r1,LSR #4
0x000000bc: e1a0ce01 .... LSL r12,r1,#28
0x000000c0: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x000000c4: e0051321 !... AND r1,r5,r1,LSR #6
0x000000c8: e1821001 .... ORR r1,r2,r1
0x000000cc: e5c61007 .... STRB r1,[r6,#7]
0x000000d0: e5b31004 .... LDR r1,[r3,#4]!
0x000000d4: e5932100 .!.. LDR r2,[r3,#0x100]
0x000000d8: e201c0ff .... AND r12,r1,#0xff
0x000000dc: e2018cff .... AND r8,r1,#0xff00
0x000000e0: e08083a8 .... ADD r8,r0,r8,LSR #7
0x000000e4: e080c08c .... ADD r12,r0,r12,LSL #1
0x000000e8: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000000ec: e1d880b0 .... LDRH r8,[r8,#0]
0x000000f0: e088c00c .... ADD r12,r8,r12
0x000000f4: e20280ff .... AND r8,r2,#0xff
0x000000f8: e0808088 .... ADD r8,r0,r8,LSL #1
0x000000fc: e1d880b0 .... LDRH r8,[r8,#0]
0x00000100: e088c00c .... ADD r12,r8,r12
0x00000104: e2028cff .... AND r8,r2,#0xff00
0x00000108: e08083a8 .... ADD r8,r0,r8,LSR #7
0x0000010c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000110: e088c00c .... ADD r12,r8,r12
0x00000114: e004822c ,... AND r8,r4,r12,LSR #4
0x00000118: e1a09e0c .... LSL r9,r12,#28
0x0000011c: e1888f29 )... ORR r8,r8,r9,LSR #30
0x00000120: e005c32c ,... AND r12,r5,r12,LSR #6
0x00000124: e188c00c .... ORR r12,r8,r12
0x00000128: e5c6c007 .... STRB r12,[r6,#7]
0x0000012c: e201c8ff .... AND r12,r1,#0xff0000
0x00000130: e1a01c21 !... LSR r1,r1,#24
0x00000134: e0801081 .... ADD r1,r0,r1,LSL #1
0x00000138: e080c7ac .... ADD r12,r0,r12,LSR #15
0x0000013c: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000140: e1d110b0 .... LDRH r1,[r1,#0]
0x00000144: e081100c .... ADD r1,r1,r12
0x00000148: e202c8ff .... AND r12,r2,#0xff0000
0x0000014c: e080c7ac .... ADD r12,r0,r12,LSR #15
0x00000150: e1a02c22 ",.. LSR r2,r2,#24
0x00000154: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000158: e0802082 . .. ADD r2,r0,r2,LSL #1
0x0000015c: e1d220b0 . .. LDRH r2,[r2,#0]
0x00000160: e08c1001 .... ADD r1,r12,r1
0x00000164: e0821001 .... ADD r1,r2,r1
0x00000168: e0042221 !".. AND r2,r4,r1,LSR #4
0x0000016c: e1a0ce01 .... LSL r12,r1,#28
0x00000170: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x00000174: e0051321 !... AND r1,r5,r1,LSR #6
0x00000178: e1821001 .... ORR r1,r2,r1
0x0000017c: e5c61007 .... STRB r1,[r6,#7]
0x00000180: e5b31004 .... LDR r1,[r3,#4]!
0x00000184: e5932100 .!.. LDR r2,[r3,#0x100]
0x00000188: e201c0ff .... AND r12,r1,#0xff
0x0000018c: e2018cff .... AND r8,r1,#0xff00
0x00000190: e08083a8 .... ADD r8,r0,r8,LSR #7
0x00000194: e080c08c .... ADD r12,r0,r12,LSL #1
0x00000198: e1dcc0b0 .... LDRH r12,[r12,#0]
0x0000019c: e1d880b0 .... LDRH r8,[r8,#0]
0x000001a0: e088c00c .... ADD r12,r8,r12
0x000001a4: e20280ff .... AND r8,r2,#0xff
0x000001a8: e0808088 .... ADD r8,r0,r8,LSL #1
0x000001ac: e1d880b0 .... LDRH r8,[r8,#0]
0x000001b0: e088c00c .... ADD r12,r8,r12
0x000001b4: e2028cff .... AND r8,r2,#0xff00
0x000001b8: e08083a8 .... ADD r8,r0,r8,LSR #7
0x000001bc: e1d880b0 .... LDRH r8,[r8,#0]
0x000001c0: e088c00c .... ADD r12,r8,r12
0x000001c4: e004822c ,... AND r8,r4,r12,LSR #4
0x000001c8: e1a09e0c .... LSL r9,r12,#28
0x000001cc: e1888f29 )... ORR r8,r8,r9,LSR #30
0x000001d0: e005c32c ,... AND r12,r5,r12,LSR #6
0x000001d4: e188c00c .... ORR r12,r8,r12
0x000001d8: e5c6c007 .... STRB r12,[r6,#7]
0x000001dc: e201c8ff .... AND r12,r1,#0xff0000
0x000001e0: e1a01c21 !... LSR r1,r1,#24
0x000001e4: e0801081 .... ADD r1,r0,r1,LSL #1
0x000001e8: e080c7ac .... ADD r12,r0,r12,LSR #15
0x000001ec: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000001f0: e1d110b0 .... LDRH r1,[r1,#0]
0x000001f4: e081100c .... ADD r1,r1,r12
0x000001f8: e202c8ff .... AND r12,r2,#0xff0000
0x000001fc: e080c7ac .... ADD r12,r0,r12,LSR #15
0x00000200: e1a02c22 ",.. LSR r2,r2,#24
0x00000204: e1dcc0b0 .... LDRH r12,[r12,#0]
0x00000208: e0802082 . .. ADD r2,r0,r2,LSL #1
0x0000020c: e1d220b0 . .. LDRH r2,[r2,#0]
0x00000210: e08c1001 .... ADD r1,r12,r1
0x00000214: e0821001 .... ADD r1,r2,r1
0x00000218: e0042221 !".. AND r2,r4,r1,LSR #4
0x0000021c: e1a0ce01 .... LSL r12,r1,#28
0x00000220: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x00000224: e0051321 !... AND r1,r5,r1,LSR #6
0x00000228: e1821001 .... ORR r1,r2,r1
0x0000022c: e5c61007 .... STRB r1,[r6,#7]
0x00000230: e5b31004 .... LDR r1,[r3,#4]!
0x00000234: e5932100 .!.. LDR r2,[r3,#0x100]
0x00000238: e201c0ff .... AND r12,r1,#0xff
0x0000023c: e2018cff .... AND r8,r1,#0xff00
0x00000240: e08083a8 .... ADD r8,r0,r8,LSR #7
0x00000244: e080c08c .... ADD r12,r0,r12,LSL #1
0x00000248: e1dcc0b0 .... LDRH r12,[r12,#0]
0x0000024c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000250: e088c00c .... ADD r12,r8,r12
0x00000254: e20280ff .... AND r8,r2,#0xff
0x00000258: e0808088 .... ADD r8,r0,r8,LSL #1
0x0000025c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000260: e088c00c .... ADD r12,r8,r12
0x00000264: e2028cff .... AND r8,r2,#0xff00
0x00000268: e08083a8 .... ADD r8,r0,r8,LSR #7
0x0000026c: e1d880b0 .... LDRH r8,[r8,#0]
0x00000270: e088c00c .... ADD r12,r8,r12
0x00000274: e004822c ,... AND r8,r4,r12,LSR #4
0x00000278: e1a09e0c .... LSL r9,r12,#28
0x0000027c: e1888f29 )... ORR r8,r8,r9,LSR #30
0x00000280: e005c32c ,... AND r12,r5,r12,LSR #6
0x00000284: e188c00c .... ORR r12,r8,r12
0x00000288: e5c6c007 .... STRB r12,[r6,#7]
0x0000028c: e201c8ff .... AND r12,r1,#0xff0000
0x00000290: e1a01c21 !... LSR r1,r1,#24
0x00000294: e0801081 .... ADD r1,r0,r1,LSL #1
0x00000298: e080c7ac .... ADD r12,r0,r12,LSR #15
0x0000029c: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000002a0: e1d110b0 .... LDRH r1,[r1,#0]
0x000002a4: e081100c .... ADD r1,r1,r12
0x000002a8: e202c8ff .... AND r12,r2,#0xff0000
0x000002ac: e080c7ac .... ADD r12,r0,r12,LSR #15
0x000002b0: e1a02c22 ",.. LSR r2,r2,#24
0x000002b4: e1dcc0b0 .... LDRH r12,[r12,#0]
0x000002b8: e0802082 . .. ADD r2,r0,r2,LSL #1
0x000002bc: e1d220b0 . .. LDRH r2,[r2,#0]
0x000002c0: e08c1001 .... ADD r1,r12,r1
0x000002c4: e0821001 .... ADD r1,r2,r1
0x000002c8: e0042221 !".. AND r2,r4,r1,LSR #4
0x000002cc: e1a0ce01 .... LSL r12,r1,#28
0x000002d0: e1822f2c ,/.. ORR r2,r2,r12,LSR #30
0x000002d4: e0051321 !... AND r1,r5,r1,LSR #6
0x000002d8: e1821001 .... ORR r1,r2,r1
0x000002dc: e5c61007 .... STRB r1,[r6,#7]
0x000002e0: e2877001 .p.. ADD r7,r7,#1
0x000002e4: e3570010 ..W. CMP r7,#0x10
0x000002e8: e2833004 .0.. ADD r3,r3,#4
0x000002ec: 3affff4b K..: BCC {pc} - 0x2cc ; 0x20
0x000002f0: e28aa001 .... ADD r10,r10,#1
0x000002f4: e35a0078 x.Z. CMP r10,#0x78
0x000002f8: e2833c01 .<.. ADD r3,r3,#0x100
0x000002fc: 3affff46 F..: BCC {pc} - 0x2e0 ; 0x1c
0x00000300: e8bd07f0 .... POP {r4-r10}
0x00000304: e12fff1e ../. BX r14


Цитата(axa09 @ Feb 24 2009, 13:45) *
замерял производительность с двумя вариантами стеков: во внутренней срам и во внешней - тоже самое все.
пробовал PALETTE[] расположить во внутренней срам- тоже ничего не поменялось.

Стек не используется, а PALETTE полностью ложится в кэш, так что разницы и не должно быть.
axa09
Feb 24 2009, 15:33
тоесть в моём случае уже ничего не придумать?
aaarrr
Feb 24 2009, 15:50
Ну, можно Write Buffer включить - сразу прибавится производительности.
axa09
Feb 24 2009, 19:50
Он включен(бит buferable-1)
или в другом месте еще надо?
aaarrr
Feb 24 2009, 20:01
Вы же писали:
Цитата
0x00200С00 - периферия(дисплей) не кешируется и не буферизуется
axa09
Feb 24 2009, 21:23
А разве можно буферизовать дисплей(его регистры)?
ведь кадр искривится и будет мусор!
или я чего-то ещё не сделал?
aaarrr
Feb 24 2009, 21:25
Цитата(axa09 @ Feb 25 2009, 00:23) *
ведь кадр искривится и будет мусор!

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

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

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

итого производительность всей программы возросла на 18%
aaarrr
Feb 25 2009, 11:30
Цитата(axa09 @ Feb 25 2009, 06:41) *
для дисплея удалось поставить биты buferable и cachable! регистры внутренней периферии(spi, pio) тоже забуферизовал, а вот закешировать не удалось-повисает.
может я сделал что-то лишнее? или вредное?

Да, пожалуй, Вы немного перестарались. Стоило ограничиться буферизацией записи дисплея (без кэширования, так как толку от него все равно ноль), а вот внутреннюю периферию трогать не нужно.
axa09
Feb 25 2009, 12:48
тоесть оставить только buferable для регистров внешней периферии( на EBI)
и убрать оба (cachable, buferable) у регистров внутреней периферии(spi, pio), так?

кстати,заметил, что один cachable для регистров дисплея тоже ведёт к повышению скорости обмена с индикатором- почему?
aaarrr
Feb 25 2009, 12:51
Цитата(axa09 @ Feb 25 2009, 15:48) *
тоесть оставить только buferable для регистров внешней периферии( на EBI)
и убрать оба (cachable, buferable) у регистров внутреней периферии(spi, pio), так?

Так.

Цитата(axa09 @ Feb 25 2009, 15:48) *
кстати,заметил, что один cachable для регистров дисплея тоже ведёт к повышению скорости обмена с индикатором- почему?

Потому что это режим write-through cache, и буфер записи все равно включен.
axa09
Feb 25 2009, 13:20
Спасибо за ответы!
в целом меня устраивает производительность программы сейчас.
проснулся чисто спортивно-исследовательский интерес- можно ли ещё ускорить процесс фильтра, например написать на ассемблере код фильтра? или лучше, чем сделает Си-компилер,уже не сделать?
или принудительно работать со строками кэша? чтобы уменьшить промахи. кстати, как сделать префетч?
где можно найти внятную инфу про кэши и их управление, с примерами пересылки данных?
aaarrr
Feb 25 2009, 14:01
Цитата(axa09 @ Feb 25 2009, 16:20) *
проснулся чисто спортивно-исследовательский интерес- можно ли ещё ускорить процесс фильтра, например написать на ассемблере код фильтра? или лучше, чем сделает Си-компилер,уже не сделать?

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

Цитата(axa09 @ Feb 25 2009, 16:20) *
или принудительно работать со строками кэша? чтобы уменьшить промахи. кстати, как сделать префетч?
где можно найти внятную инфу про кэши и их управление, с примерами пересылки данных?

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


Это полезно wink.gif

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

Если попиксельно - рассмотрите вопрос о хранении пикселей исходной картинки, например, в виде 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
Feb 25 2009, 23:48
если нетрудно,напишите пожалуйста фрагмент кода на Си для работы с префетчем.
я понял это так:
читаем 8 последовательных 32-битных слов, сделав перед этим префетч с начального адреса где лежат слова, я не напутал?

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

на счёт исходных данных- картинка не статичная- она постоянно рендерится програмно-1 элемент байт-индекс в палитре. увеличивать размер индекса и пользовать цвета напрямую нельзя в силу специфики программы(такое требование)
aaarrr
Feb 26 2009, 00:09
Цитата(axa09 @ Feb 26 2009, 02:48) *
читаем 8 последовательных 32-битных слов, сделав перед этим префетч с начального адреса где лежат слова, я не напутал?

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

Цитата(axa09 @ Feb 26 2009, 02:48) *
напишите плиз ещё асм-код самого префетча.

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

А описание можете прочитать в TRM smile.gif
axa09
Feb 26 2009, 01:35
Спасибо за ответы! smile.gif

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

Есть функция, которая заполняет буфер 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, 02:48
если текущий режим spi не подходит, можно сменить на fixed mode, получив возможность организовывать 8-битный буфер без лишнего.

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

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

p.s. не хочу заводить ТТВ второго уровня (4кб страницы) или гробить 1мб памяти для каких-то 32 байт для ДМА.
можно кэш данных вкл./выкл., но нежелательно из-за потери производительности функции построения буфера
aaarrr
Feb 26 2009, 03:23
Цитата(axa09 @ Feb 26 2009, 05:48) *
Получится ли так использовать внутренюю срам чтоб кешировалась при обращении к ней по первому адресу и не кешировалось по второму?

Получится. Нужно только не смешивать кэшируемые и некэшируемые области при работе.
axa09
Feb 26 2009, 10:48
удалось запустить ДМА.
Фокус с ремэпом прокатл-к той же памяти можно обращаться как к кешируемой и нет,через разные адреса!

кстати для дма-памяти оставлять buferable?
он не нужен,полезен или вреден?

дма также работает на передачу с памятью которая кэширована, но небуферизована- почему?

меня аж заинтересовало wink.gif
aaarrr
Feb 26 2009, 12:04
Цитата(axa09 @ Feb 26 2009, 13:48) *
кстати для дма-памяти оставлять buferable?
он не нужен,полезен или вреден?

Он полезен, но использовать с DMA нужно с осторожностью, т.е. своевременно очищать.

Цитата(axa09 @ Feb 26 2009, 13:48) *
дма также работает на передачу с памятью которая кэширована, но небуферизована- почему?

Во-первых, память не бывает кэширована, но при этом не буферизирована. Во-вторых, почему DMA не должен работать (когерентность данных тут другой вопрос)?
axa09
Feb 26 2009, 12:40
как и когда очищать буферизованый буфер для ДМА?

ЗЫ: ДМА дал свои плоды в приросте производительности!
делаю так:
в обработчике прерывания возобновляю указатель и счётчик передачи. затем строю вторую половину буфера(ёмкий процесс!)
жду окончания пересылки ДМА(почти ничего по времени!)
затем свопаю указатели половин буфера.
выхожу из прерывания
и до следующего раза.
играет быстро и без заиканий!
aaarrr
Feb 26 2009, 12:50
Цитата(axa09 @ Feb 26 2009, 15:40) *
как и когда очищать буферизованый буфер для ДМА?

Очевидно, что очищать надо после записи буфера и до старта DMA. Команда сопроцессора есть в мануале.
axa09
Feb 26 2009, 15:10
Не совсем понял.
команду очистки давать до старта дма, когда уже в буфер(массив в программе) записали данные?

а если я пишу в этот массив через другое адресное пространство(ремэп) которое кэшировано+буферизовано?

где и когда следует выполнять префетч для кода?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.