Отключи пока оптимизацию. -O0 и повтори тесты и результаты с листингами покаж
Непомню, KEIL используешь, версия? Какой компилятор выбран.

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

Скорее всего, если понадобится ускорять код, то придется пробовать и так и сяк. Ибо разные коды, ведут себя по разному. Один работатет быстрее во флеш, другой в ОЗУ и наоборот.

Если KEIL, покажи вкладку настройки C/C++

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Кокос.
Вот это поди интересует:


Но какая разница какая оптимизация для сравнения скорости одного и тоже машинного кода при выполнении из разных типов памяти?

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Скиньте проект с тестами.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Там скидывать то вроде нечего.

Z_h_e , в кокосе чего либо вменяемого добиться трудно.

А кокос вроде ничего и не компилирует.
Что тут невменяемого у меня в коде?
Как это связано с выполнением одного и тоже кода в разной памяти?

А как вы задаете откуда код будет исполняться?

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

Делал так.
Атрибуты массива закоментарьте, не сработали. Но мой компилятор массив констант (const) сам определяет во флеш без дополнительного указания. Убрав const - массив перебирается в ОЗУ.

Чтобы зарядить foo в озу в прототип добавлял атрибут __attribute__((section(".data")));.
В коде что я Вам скинул он закоментарен, что означает фу во флеше.

Перед тестом обязательно запускал отладку и проверял кто куда попал на случай "вдруг затупил" и только после этого перезапускал МК и считывал частоту.

Добавлено after 2 minutes 13 seconds:
Компилятор GCC. У Вас может как-то по другому.

Попробуйте прошивки потестить, я скомпилировал разные. с приставкой data это с .data. Остальной код как вы скинули. Оптимизация указана в имени файла. Отпишитесь какие частоты выводятся, что-нибудь изменилось нет.

F103_O0.hex-------------------5,39
F103_O0_data.hex-------------6,36
F103_O1.hex------------------10,05
F103_O2.hex--------------------8,81
F103_O3.hex--------------------8,81
F103_O3_data.hex--------------8,81

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

Ну код немного разный компилится. Многие факторы влияют.

Код и должен разным компилится.

Вывод из всего выше проведенного:
1. Таракан без ног не слышит.
2. Для f103, а может и для остальных STM32, нельзя однозначно утверждать что код будет быстрее выполняться в той или иной памяти.
3. Даже использование сверхоперативной памяти (регистров) не гарантирует ускорения и в некоторых случаях даже замедляет.
4. Для ускорения кода нужно оптимизировать код именно под ту память или пробовать различные комбинации размещения кода и выбрать оптимальное, учитывая частоту тактирования.
5. Возможно это справедливо для МК ARM других производителей.

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

Ну память если и влияет то процентов 5 от силы. Все остальное это работа с регистрами периферии, исполнение инструкций, набор команд. Каждая инструкция занимает время, их количество. DMA например не зря есть. Ускоряет намного работу с периферией.

Несомненно, но вопрос тут был о памяти.

да там особо ускорений нет.

В этом тесте максимальная частота 14.025 кГц , минимальная 7.418 кГц. Соотношение почти в два раза при выполнении одного и того же кода и обработки массива с одними и теми же данными. При том что самый медленный код - это код из флеш, с массивом констант во флеш (т.е. самое классическое решение).

Да все во флеш тоже пихать смысла нет, если ОЗУ имеет свободное место, то конечно из ОЗУ быстрее выборка.
Дело в том что ICODE шина подключена к флешу, а DCODE к ОЗУ. Инструкции быстрее идут из флеш, а данные из ОЗУ.

Это справедливо для всех МК. И чем сложнее и навороченнее МК (чем больше в нём кешей, типов памяти и сложной матрицы шин работающих на разных частотах и т.п.) и чем сложнее алгоритм работы МК - тем справедливее.

Добавлено after 4 minutes 51 second:

Не факт. А если шина к флешь шириной 256 бит? А если с ОЗУ одновременно работает ещё и несколько DMA-каналов? Всё бывает очень по-разному...