Мне надоело пробовать уже. Первые разы были с выключенной оптимизацией. Результаты выложены.
Скорее всего, если понадобится ускорять код, то придется пробовать и так и сяк. Ибо разные коды, ведут себя по разному. Один работатет быстрее во флеш, другой в ОЗУ и наоборот.
Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Лучше всего конечно это поправить файл линковщика. Но мне было лень, я не очень с ним на "ты" и надо тихонько скрипеть мозгами.
Делал так.
Атрибуты массива закоментарьте, не сработали. Но мой компилятор массив констант (const) сам определяет во флеш без дополнительного указания. Убрав const - массив перебирается в ОЗУ.
Чтобы зарядить foo в озу в прототип добавлял атрибут __attribute__((section(".data")));.
В коде что я Вам скинул он закоментарен, что означает фу во флеше.
Перед тестом обязательно запускал отладку и проверял кто куда попал на случай "вдруг затупил" и только после этого перезапускал МК и считывал частоту.
Добавлено after 2 minutes 13 seconds:
Компилятор GCC. У Вас может как-то по другому.
Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Попробуйте прошивки потестить, я скомпилировал разные. с приставкой data это с .data. Остальной код как вы скинули. Оптимизация указана в имени файла. Отпишитесь какие частоты выводятся, что-нибудь изменилось нет.
Вывод из всего выше проведенного:
1. Таракан без ног не слышит.
2. Для f103, а может и для остальных STM32, нельзя однозначно утверждать что код будет быстрее выполняться в той или иной памяти.
3. Даже использование сверхоперативной памяти (регистров) не гарантирует ускорения и в некоторых случаях даже замедляет.
4. Для ускорения кода нужно оптимизировать код именно под ту память или пробовать различные комбинации размещения кода и выбрать оптимальное, учитывая частоту тактирования.
5. Возможно это справедливо для МК ARM других производителей.
Повторю свой вывод, по-скольку на текущий момент считаю его ключевым: нельзя однозначно утверждать что код выполняется быстрее в одной памяти, чем в другой.
Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Ну память если и влияет то процентов 5 от силы. Все остальное это работа с регистрами периферии, исполнение инструкций, набор команд. Каждая инструкция занимает время, их количество. DMA например не зря есть. Ускоряет намного работу с периферией.
Инженер R@D
Telegram чат: https://t.me/radiowolf или в поиске приложения @radiowolf. Личка:@cncoxford
В этом тесте максимальная частота 14.025 кГц , минимальная 7.418 кГц. Соотношение почти в два раза при выполнении одного и того же кода и обработки массива с одними и теми же данными. При том что самый медленный код - это код из флеш, с массивом констант во флеш (т.е. самое классическое решение).
Добро всегда побеждает зло. Поэтому кто победил - тот и добрый.
Да все во флеш тоже пихать смысла нет, если ОЗУ имеет свободное место, то конечно из ОЗУ быстрее выборка.
Дело в том что ICODE шина подключена к флешу, а DCODE к ОЗУ. Инструкции быстрее идут из флеш, а данные из ОЗУ.
[uquote="Z_h_e",url="/forum/viewtopic.php?p=3271444#p3271444"]Код и должен разным компилится.
5. Возможно это справедливо для МК ARM других производителей.
... нельзя однозначно утверждать что код выполняется быстрее в одной памяти, чем в другой.[/uquote]
Это справедливо для всех МК. И чем сложнее и навороченнее МК (чем больше в нём кешей, типов памяти и сложной матрицы шин работающих на разных частотах и т.п.) и чем сложнее алгоритм работы МК - тем справедливее.
Добавлено after 4 minutes 51 second:
[uquote="Oxford",url="/forum/viewtopic.php?p=3271535#p3271535"]Да все во флеш тоже пихать смысла нет, если ОЗУ имеет свободное место, то конечно из ОЗУ быстрее выборка.[/uquote]
Не факт. А если шина к флешь шириной 256 бит? А если с ОЗУ одновременно работает ещё и несколько DMA-каналов? Всё бывает очень по-разному...