Стал оптимизировать одну функцию. Время выполнения измеряю таймером типа:
time=0;//инкремент в прерывании таймера
for(n=0;n<100000;n++)
{
my_func();
}
while(1);//тут брейкпоинт

Заметил, что добавление NOP в самом начале, что вызывает просто сдвиг проги в памяти, может приводить к изменению производительности до 3.5%. И ещё :
SPI->DR=data;
while(!(SPI->SR&SPI_TX_FIFO_not_full));
При попадании этого while на определённые адреса проц на нём зацикливается, добавляем в прогу NOP и всё опять работает. Отсюда вопрос - это что работа конвеера??? Может выравнивание какое надо включить в компиляторе, я уже не знаю, поскажите pls.

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

В STR91x очень много чудес возникает если неправильно выставлять частотные режимы работы памяти и периферии.
Внимательно посмотрите какие частоты у MCLK, BCLK, HCLK, PCLK, RCLK и сверьте с допустимыми величинами из даташита.
Также если что не так очень любит отрубаться контроллер прерываний. Поэтому еще раз внимательно проверить во всех ли обработчиках читаются и сбрасываются вектора в VIC0 и VIC1.

NOP в принципе может влиять на прогу которая читает упакованные данные из FLASH. В частности функция memcpy чувствительна к выравниванию перемещаемых данных.

Попробуйте поэкспериментировать на Whetstone, если добавлять просто NOPы в стартап результат начинает прилично меняться,
хотя никаких memcpy там нет.

Да, я зафиксировал такой эффект.
Но именно Dhrystone и Whetstone меняли свои результаты не более чем на 1%
А вот простой цикл (ниже) от простого смещения на 8 байт дает изменение результата на 20% !

;-------------------------------------------------------------------------------------------------------------
; Задержка на (t+1)*10 тактов
;-------------------------------------------------------------------------------------------------------------
us_Delay
MOV R1,#0
B label1

label2
NOP
NOP
NOP
NOP
NOP
ADD R1,R1,#1
label1
CMP R1,R0
BLT label2
BX LR


Причем откдючение Branch cache на полученные пропорции влияния не оказывает.
И именно смещение на 8-ь байт дает худший вариант.
Однозначно что-то с burst FLASH намутили.





А вот с этой проблемой думаю может быть связан нюанс описанный в Errata 09-May-2007 пункт 2.16
И еще, на шине AHB надо обязательно поставить один такт ожидания.

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

Ничего нет тут странного, и то что результат аж 20% это нормально и burst FLASH тут не причем, во всем виноват конвеер , команда BLT label2 и BX очисчает конвеер, и вот в каком месте он очистится, точнеее какие даные уже загружены в конвеере от этого и зависит производительность. Тоесть если вы хотите сделать точную задержку в тактах или посчитать сколько тактов уходит на функцию,на ядрах с конвеером забудьте ! точность приблизительно равна T = кол-во переходов * размер конвеера. вот и получите +- T тактов. Это если несчитать всяких колpий на шинах, особенно когда работает ПДП если он есть .

Эт с кем вы спорите?
Тут как бы всем и так понятно, что прога из FLASH выполняется не по тактам из манула на ARM.
Когда говорите об STR91x всегда уточняете какой конвеер вы имеете ввиду.
Конвеер ядра, конвеер модуля PFQ/BC или че другое.

Моя теория такая:
Когда команда перехода указывает на адрес находящийся вне ближней 16-и байтной зоны выровненной по 16-и байтной границе, то происходит очистка-выборка PFQ и соответственно торможение.
Т.е. PFQ может держать в себе только блоки выровненные по границе 16 (это и понятно к FLASH-и же доступ тоже 16-и байтный). И PFQ не сдвигаеться побайтно как можно понять из диаграмы в мануале, а всегда очищается и переписыватся целиком в случае переходов в проге.

В LPC думаю тоже должен наблюдаться похожий эффект.

Отсюда вывод. Для DSP алгоритмов с длительными циклами из малого количества команд, такие циклы следует принудительно распологать по границе 16 байт и тогда быстродействие во FLASH только на 10% будет отставать от быстродействия в RAM

Все проблемы с прерываниями(я уже писал про конфликт таймера и uart) и тд решились путём установки 3-х циклов ожидания на флешь. Самое интересное, что просто понижение частоты даже до 25МГц ничего не давало.