Здравствуйте!
Есть проект в котором критична производительность и большое количество прерываний, так же есть камень - stm32f103. Для того что бы не тратить драгоценные такты на ожидание чтения из флеш-памяти есть желание записать несколько самых важных обработчиков в ОЗУ и оттуда их выполнять. Но поскольку я только начинаю изучать этот проц, не совсем понимаю как это сделать ни на асме, ни на си. Примеров в сети никаких не нашел*(
Если подскажите пару примеров для Keilа будет вообще замечательно.

Спасибо!

В хелпе Кейла или у него на сайте поищите директиву, которая размещает обработчик в ОЗУ. Я такое делал, но сходу не вспомню ...
А, вспомнил, вот ответ, в первых же сообщениях:
http://electronix.ru/forum/lofiversion/ind...hp/t108182.html

А вот статья:
http://infocenter.arm.com/help/index.jsp?t...qs/ka11306.html

Выносите обработчик в отдельный Си - файл. Дальше все просто.
Директива - это для CARM. Для RealView см. ссылки ...

есть мнение что методика проканывающая на arm7tdmi не проканает на cortex-m. дело вот в чем. в новых мк приянято много мер на выравнивание скорости выборки команд из флеша и их выполнения. ну типа сразу 128 или более бит выбирать и покрывать латентность флеша. тоесть для f103 на шьатной максимальной тактовой 72мгц флеш успевает. с другой стороны в силу гарвардовости кортексов чтение команд и обмен с озу идет по разным шинам - если все записать в озу и код и данные то они будут по одной шине тупить.
мой прогноз - быстрее работать не будет, может даже чуток медленнее или также. едиственное что можно в этом ключе попробывать - сделать обработчик бкз команд обмена с озу с одновременным разгоном тактовой.

попробуете напишите результаты пожалуйста.

Тоже склоняюсь к такому мнению...

"...The CortexM3 processor has a total of 4 GB of address space. Program code can be located in the code region, the Static Random Access Memory (SRAM) region, or the external RAM region. However, it is best to put the program code in the code region because with this arrangement, the instruction
fetches and data accesses are carried out simultaneously on two separate bus interfaces (I-Code, D-Code). "

Еще цитата:
"В процессоре CortexM3 при условии, что память имеет нулевую латентность, и учитывая, что архитектура шин позволяет одновременно ocyществлять
выборку вектора и сохранение контекста проrраммы, минимальная величина задержки обработки прерывания составляет 12 тактов. Это время yxoдит на сохранение реrистров в стеке, выборку вектора и выборку первых команд обработчика прерывания. В то же время указанная величина зависит от наличия циклов ожидания при обращении к памяти и ряда друrих факторов. "

3-х уровневый конвеер "выборки-декодирования-выполнения" команд тоже оптимизирован под код из Flash.

Кроме того, при наступлении прерывания (то же относится и к возврату из обработчика), в SRAM сохраняется контекст - стековый фрейм (8 регистров) одновременно с выборкой вектора и первой исполняемой команды оброботчика. Эта "одновременность" может быть достигнута если код обработчика будет во флэш! Иначе весь обмен будет по системной шине ч/з которую подключено SRAM. Что приведет к задержкам.
Если в обработчике идет интенсивный обмен данными с SRAM, то используйте выравнивание данных иначе будут лишние такты шины.

Cortex-M3 оптимизирован для обработки прерываний с маленькой задержкой (latenсy).
Поэтому для быстрого обработчика с минимальной latency все же лучше подходит Flash, чем SRAM.

Присоединяюсь к предыдущим ораторам.
В семействах STM32F2xx, STM32F4xx имеется Multilayer Bus Matrix, куда подключены все шины процессора и разные блоки памяти. Там можно попытаться распределить код и данные так, чтобы код выполнялся из ОЗУ с максимальной скоростью, но это ещё проверять надо. В семействе STM32F1xx шинный коммутатор гораздо проще, там нет такой возможности.

А ещё лучше подходит ARM7/ARM9

У ARM7 всего одно FIQ, а ТС нужно много прерываний. С учетом "тамошнего" VIC и выигрыш не очевиден.
Только если нет вложенных прерываний и обработчики пользуются только теневыми регистрами.

т.е. как я понял на Cortex M3 смысла в ОЗУшном обработчике нет...

а к примеру если заменить stm32 на Altera с Сortex M1 в моем посте... будет смысл записи обработчика в ОЗУ?

Неправильно поняли. Например, в семействе STM32F2xx блок ОЗУ размером 112 Кбайт подключен к шинам I-Code, D-Code процессора Cortex-M3. Есть шансы, что оттуда будет выполняться быстрее, чем из флэш. Но надо проверять.

Лучше сначала определиться с целью.
Если для stm32f103 нужна минимальная задержка при обработке прерывания , то лучше подходит Flash.
Если же цель - найти смысл размещения обработчика в SRAM, то это может понадобиться для динамичекого изменения самого обработчика в процессе работы.
Окончательное же решение должно приниматься с учетом конкретных характеристик проекта!

цель ясна и понятна - озвучена в первом посте - минимальная задержка при обработке прерывания, есть пара вариантов камней на которых требуемая задача может быть решена, все эти камни я знаю не очень глубоко по этому прошу помощи у форума. Я высказал предположение что на stm32f103 обработчик быстрее выполниться из ОЗУ - оно оказалось ошибочно. Теперь уточняю Altera Cyclone III с Cortex M1.

Вообще-то это совсем не так делается. Для начала нужно измерить, где именно и сколько именно процессорного времени не хватает. А потом уже думать, что с этим делать.
А так вы ставите телегу впереди лошади. Ничего толкового из этого не выйдет.