есть STM32F429. И внешняя SDRAM, подключенная по 16-битной шине.
Нужно часто читать из массива 4-байтные величины (коэффициенты оконной функции). Где лучше разместить этот массив: в SDRAM или во FLASH программ, насколько велика разница?
Всегда ли это однозначно (XX быстрее чем YY), или все-таки нужно считать текущую времянку в соответствии с настройками шин?

Сейчас во флэше и все устраивает, но в будущем хочется просто генерировать массив после включения и класть в SDRAM, мне так удобнее, вот только про быстродействие непонятно.

Зависит от частоты шины к SDRAM, наличия кеша флешь и др.
А в чём проблема просто померить варианты тот и тот? Минутное дело, сюда вопрос дольше писать.

у меня могозадачка и много чего там крутится, запросто могу промахнуться при разовом тесте и измерить необъективно из-за того что оно что-то начало делать более приоритетное и ресурсоемкое. Думал мне просто скажут- все ежи однозначно бегут вот сюда, все уже разжевано и доказано .
Ну и лень, опять же....

И запрещать прерывания тоже не умеете??

Я много чего не умею, чем дольше живу-тем больше всего не умею.

Ладно, понял, спасибо. Раз ответ на мой вопрос не такой однозначный как я думал- буду получать ответ локально.

Я представляю, выбрать константу из памяти - далеко не единственная операция с использованием оконной функции. Вот если бы можно задать выбирать эти константы с упреждением, тогда, вообще было бы все равно, откуда. Можно ли?

Вот смотрите - написал для Вас за 4 минуты нужный Вам тест

Объявляете его как:
extern "C" void f1(void const *);
Вначале вызываете с адресом в SDRAM, потом - во флешь. Смотрите сколько тактов получилось. Сравниваете.
Код выполняет 4000 32-битных последовательных чтений памяти.
Всё!

Уважаемы jcxz, спасибо!
попробую.

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

Хотя, конечно, до уровня ассемблера я не собирался спускаться в данном тесте.
Придется, значит, все-таки подключать железяку и смотреть живьем.

У вас же есть 16 К core coupled memory. Быстрее сложно придумать.

Спасибо всем, кто откликнулся.
Вопрос был неуместный, мне следовало смотреть "ширше", а я в частный буфер уперся.
Когда начал анализировать, что мне собственно нужно с этим делать- получилось, что задача эта будет из самых низкоприоритетных, и общее время выполнения зависит уж совсем не от того, где я этот массив положу.
Профайлинг показал, что общее время вычислений (не только чтение буфера, естественно) скачет от 16 до 69 миллисекунд (зависит от других задач с высокими приоритетами), тут хоть где размещу- разницы не увижу, так как другие задачи могут съесть сильно больше, чем собственно нужная мне обработка.
Но на будущее спасибо, почерпнул кое-что для себя из дискуссии.

Там конечно не RET, а BX LR нужен. Запутался совсем с этим STM8


Профайлинг у Вас неправильный. Нужно встать на начало измеряемого участка; поставить бряк на его конец; запретить прерывания; нажать кнопку Run в отладчике; когда остановится на бряке, посмотреть содержимое счётчика тактов. Вот и всё. А Вы температуру на Марсе меряете...

Я про то и говорю, что именно эта "температура на Марсе" мне и нужна будет в реальности, а не тики изолированной функции в лаборатории на столе. Ну, будет оно на 24микросекунды быстрей или медленней, как это скажется в условиях, когда общее время выполнения в реальных условиях из-за окружающих причин плавает на в 1000 раз бОльшие величины? Потому и написал, что "вопрос неуместный", то есть для меня не актуальный.

Другими словами- информация о том, что при заливке вот этого бензина автомобиль сможет двигаться со скоростью 320 км/ч, а не 250, никак не изменит время моей поездки из А в Б в час пик по центру города. Исследование ради исследования?