[axa09 0]

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

обработчики прерываний в этой памяти.

 

вопрос-

если обработчики разместить во внутренней sram контроллера,будет ли выигрыш в производительности?

или с кешами это не принципиально?

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

 

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

[aaarrr 69]

вопрос-

если обработчики разместить во внутренней sram контроллера,будет ли выигрыш в производительности?

или с кешами это не принципиально?

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

 

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

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

 

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

Значит, в вашей программе не так уж часто нужен стек.

[sergeeff 1]

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

обработчики прерываний в этой памяти.

 

вопрос-

если обработчики разместить во внутренней sram контроллера,будет ли выигрыш в производительности?

или с кешами это не принципиально?

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

 

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

 

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

[axa09 0]

За ответы спасибо!

с праздником!

 

можно повысить производительность системы путём манипуляций с кешами?

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

подскажите дальнейшие пути повышения производительности:

1)при выполнении кода

2)при блочном чтении из памяти

3)при блочной записи в память

слышал, что перед передачей данных надо втыкать prefetch. можно по-подробнее?

есть ещё invalidate,flush и др. как их пользовать?

 

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

[aaarrr 69]

можно повысить производительность системы путём манипуляций с кешами?

Можно, но не в разы. Судя по описанию, ваша система и так правильно настроена.

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

 

сейчас таблица трансляции адресов(по 1мб) находится в кешируемой области внешней памяти.

Напрасно.

 

кеш асинхронный

Режим тактирования имеется в виду?

[axa09 0]

Надо хотябы на 25% повысить.

почему напрасно?

как правильно и на что влияет?

 

ДА! режим тактирования имел ввиду.

[aaarrr 69]

Надо хотябы на 25% повысить.

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

Просто повысить производительность системы на 25% невозможно.

 

почему напрасно?

Потому что выборки из таблицы трансляции не идут через кэш. Расположение таблицы ни на что не влияет.

[sergeeff 1]

За ответы спасибо!

с праздником!

 

можно повысить производительность системы путём манипуляций с кешами?

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

подскажите дальнейшие пути повышения производительности:

1)при выполнении кода

2)при блочном чтении из памяти

3)при блочной записи в память

слышал, что перед передачей данных надо втыкать prefetch. можно по-подробнее?

есть ещё invalidate,flush и др. как их пользовать?

 

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

 

Да уж конечно надо смотреть в сторону собственно обработчика прерываний. Что за скорость то нужна, если 180 МГц rm9200 не хватает?

[axa09 0]

Нужно ускорить переброс видеобуфера в дисплейную память(шина 8 бит, на ebi, i80).

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

и доступ к таблице будет медленным?

нужно ли кешировать внутреннюю память-срам 16кб?

где правильнее расположить таблицу трансляции?

[aaarrr 69]

Нужно ускорить переброс видеобуфера в дисплейную память(шина 8 бит, на ebi, i80).

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

 

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

и доступ к таблице будет медленным?

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

 

нужно ли кешировать внутреннюю память-срам 16кб?

Нужно.

 

где правильнее расположить таблицу трансляции?

В наиболее скоростной памяти. Но гробить под нее всю внутреннюю SRAM не стоит.

[axa09 0]

Пришла в голову мысль расположить таблицу во внутренней sram.

затрутся только reset, undef и swint.

irq, fiq останутся!

таблица у меня сильно фрагментирована.

тоесть во внутренней срам будут вектора прерываний, стек и таблица трансляции адресов!

отпишусь когда сделаю!

я- великий извращенец! ;)

[andrewn 0]

таблица трансляции адресов (по 1мб)

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

можно посмотреть какой-нибудь примерчик.

 

За ответы спасибо.

С праздником.

[axa09 0]

В общем удалось ради эксперимента таблицу запихать во внутреннюю срам.

прироста в скорости не дало :(

по ходу больше никак не выжать.

 

вот собственно задача:

есть буфер MxN байт- индексов другого массива(палитра).

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

как можно сделать быстрее?

буфера во внешней памяти

[sergeeff 1]

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

можно посмотреть какой-нибудь примерчик.

 

За ответы спасибо.

С праздником.

 

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

 

Смотри http://electronix.ru/forum/index.php?showt...&hl=d-cache

[aaarrr 69]

прироста в скорости не дало :(

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

 

вот собственно задача:

Можно поподробнее? Чему равны M и N, что из себя представляет палитра, какие требования к скорости?