Если кому-то интересно, вот результаты небольшого теста скорости LPC2148 с включеным MAM и с выключеным.

Пояснения: DSBL - MAM выключен, FULL - включен, PART - только для последовательного доступа к коду. Проценты - проценты занятости процессора. Число - коэффициент "тормознутости" относительно работы из RAM.
Частота ядра 60МГц, переферия 15МГц.
Выполняется ядро ОС, 5 пользовательских потоков, 1 idle-поток. Переключение потоков раз в 1мс. Еще работает таймер, который прерывает программу раз в 62.5мкс и выполняет немножко кода.
В одном потоке выводится анимация на LCD через I2C (30 кадров/c), другие два суют в фифо данные примерно 25 раз в сек., четвертый эти данные вынимает (10 раз в сек.) и пишет в файл на MMC через SSP, пятый 20 раз в сек. мониторит стек (следит за переполнениями). Все они выводят отладку в UART. IDLE-поток заводит ядро в powersave.
Вот результат:



Интересно посмотреть на результаты AT91SAM7 (на какую производителность стоит расчитывать?).

Интересно, почему есть разница при разном количестве циклов при отключенном MAM...
И как получилось запустить программу с 2clk при 60MHz? При времени доступа к флэшке ~50ns надо минимум 3 такта на 60 MHz (~17ns = 1 такт).

Информация полезная и нужная, но есть вопросы .
1. Присоединяюсь к Dmitry V.
2. Интересует последняя колонка и формулы, по которым производится расчет.

Интересно было-бы если разницы не было.

Для справок - частота почти 60MHz, исполнение из Flash 3ws. ARM Mode. Попугаемер обычный - Dhrystones 2.1. Компилятор IAR 5.10 оптимизация тупо (никаких подгонок под тест) максимальная по производительности.

Результаты при выключенном полностью МАМ как то очень оптимистичны.
По моим прикидкам при отключенном МАМ производительность снижается до 5 раз.

Что измерилось, то измерилось. Тест достаточно комплексный и, естественно, максимально плохой результат на некотором куске линейного кода будет хуже. Провал более, чем в два раза тоже не в радость.

Проверить влияние MAM это вообще святое дело.
Поскольку от него сильно зависит сбоеустойчивость.
Но советовал бы тестировать на более однородных кусках кода, тогда лучше проявляются интересные моменты, как например то, что режим ARM по скрости начинает проигрывать THUMB при больших установках MAMTIM
http://aly.projektas.lt/Tests/LPC/ARM-comp...s%20tests.htm#4

MAMTIM=5,6,7 - это гипотетические случаи. Я бы их в рассмотрение не брал.

Тем не менее работает. Наверное есть запас производительности у флэшки. На 1clk не заработало.


Последняя колонка - это те-же проценты, только приведено к скорости на RAM. Это я посчитал для удобства оценки.

Забыл сказать, что весь код ARM. C THUMB у GCC есть глюк, который до сих пор не исправили (двойное уменьшение LR при вызове функции из прерывания).

Спасибо. Действительно, запас по флешке есть, но не уверен, что надо выходить за предельные параметры.
У меня сложилось устойчивое субъективное мнение, что без оптимизации по скорости (с подстановкой) эффекта от MAM почти не ощущается.
Конечно, на длинных прямых дистанциях великан обгоняет коротышку. Шутка.

Только что наблюдал тот же глюк и при компиляции в системе команд ARM (GCC 4.1.1). При объявлении функции как обработчика прерывания на уровне оптимизации O2 регистр LR уменьшается на 4 дважды - в начале обработчика и в конце. На уровне оптимизации O1 у меня было все в порядке, но, правда, там и LR в стеке не сохранялся.

Этот глюк возникает c опцией -mthumb-interwork. А обработчики прерываний по любому компилятся в ARM.