Ну да ядро тут не при чем, это от реализации STM32 зависит. В более поздних видать добавили.
В STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and
STM32F107xx референсе ее нету.

По ссылке на ресурс easyelectronics там использовался STM32L152RBT6 в котором есть.

Дело в том что топикстартер тестировал F103, соответственно ремапа у него нет. Вы этого не знали. Покапавшись узнали что не во всех есть он (зависит от реализации периферии у вендора).

Однако, как я уже несколько раз говорил, мною на разных кодах были получены разные результаты. На одном форуме видел утверждение, что код из CCMRAM не выполняется на одних камнях, только как хранилище, а на других уже можно. Сам не знаю.

Сейчас народ рассосется и в рабочее время тихонько попробую еще один тестик. Посмотрим совпадут ли мои ожидания с результатом...

У меня еще есть 030, можно еще и его попробовать будет, я его даже не распаковывал. Тут cortex-m0, шины проще. Согласно пикче у ядра нет отдельной шины ICode. Все идет через системную шину. Может вечером попробую, ожидаю на нем самый быстрый код из ОЗУ.

Да у Cortex M0 одна системная шина.
single 32-bit AMBA-3 AHB-Lite system interface that provides simple
integration to all system peripherals and memory

Касаемо Cortex M3 4 шины.

Информация по кортексам извлекается из документов на архитектуры от ARM.
По реализации периферии смотрите у вендора на конкретный МК.

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

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

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

Я проверял на F3, там из CCM выполняется так же быстро, как из флеша при нулевых тактах ожидания, только флеш с 0WS сильно не разгонишь... А на F4 у меня стек в CCM, это тоже дает заметное увеличение производительности.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

В рабочее время не удалось, сделал в обед.
МК f103

Контроль скорости так же по частоте на порте.
Массив на 256 32битных элементов, инициализирован некими числами.
Зацикленная функция.

Спойлер

Код:

void foo(void)
{
      volatile uint32_t a = -1;
       while(1)
       {
          GPIOA->ODR^=1;//Инвертируем выход A0
         uint8_t i=255;
          uint32_t buf=0;

          while(i--)
          {
             buf+=Mass[i];
          }
          a=buf;
       }
};

Оптимизация включена.

Четыре варианта теста. Массив в ОЗУ и во Флеш. Функция в ОЗУ и во Флеш.

Первая половина теста. Массив в ОЗУ.
Частота порта
foo из флеша 12.788 кГц
foo из ОЗУ 11.710 кГц

Собственно - это повторение вчерашнего результата.

Теперь массив во Флеш.
foo из флеша 10.050 кГц
foo из ОЗУ 10.050 кГц

Хотя я ожидал не совсем такого результата. Ожидал что скорость понизится во флеш, а что понизится и в ОЗУ не ожидал. Да еще и скорость стала одинаковая.

----------
Сейчас кое-что дотестирую и допишу еще одним постом. Тоже на мой взгляд интересная вещь.

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

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

Подробнее>>

Reflector, а к чему эти гонки ?
Вновь софтовый ногодрыг покоя не дает?

Вы еще этот массив при помощи DMA выводите куда-нибудь в порт, вот тогда и станет понятно, кто виноват и что делать.

В функции foo была объявлена локальная переменная а, хотя и как volatile.
Убрал и объявил глобально. И все перевернулось. Теперь ОЗУ нагибает флеш. Да еще как и во всех случаях расположения массива.

Первая половина теста. Массив в ОЗУ.
Частота порта
foo из флеша 12.723 кГц
foo из ОЗУ 14.025 кГц

Теперь массив во Флеш.
foo из флеша 7.418 кГц
foo из ОЗУ 11.710 кГц

Так что, мутно тут усё и однозначно что-то утверждать нельзя видимо.

Добавлено after 9 minutes 2 seconds:
Понятно что эти не те камни, на которых можно считать количество команд, чтобы точно дернуть ногой. Однако в этих изысканиях может быть и практическое значение. Существуют же математические очень затратные операции и почему бы не поразмышлять как можно их ускорить?
Думаю будет только еще не понятнее. . Каналов DMA не один, модулей DMA тоже может быть не один. У них свои приоритеты переназначаемые, и еще будут драться за шину(ы) между собой и ядром. Полнейший арбитраж одним словом.

Кстати, как я понял, память CCM избавлена от домогательств со стороны DMA. Тут может быть свой минус.

Z_h_e, F103 на какой частоте работает?

72
Думаете имеет значение? Хотя если понизить может уменьшится простой из флеша и относительаня картина поменяется.

Нет, просто для 72MHz достаточно 1WS и тогда твой пример из флеша у меня выполняется чуть быстрее, а при 2WS уже заметно медленнее. Но это F1, у F2 уже есть ART, а L1 относительно медленные и 2WS для них бесполезны. И пример достаточно специфичный, в цикле складываются данные и все, а я проверял на реальных приложениях и там всегда флеш был быстрее...

Что это?
специфичный он или нет, не столь важно. Сам факт, что скорость выполнения там или там оказывается вещь не очень определенная. При том что, самый первый раз я сравнивал дизассеблерный код и он был идентичный для обоих расположений кода. В других разах тоже стоило так сделать конечно, но крайне лень.

Флеш медленный, на больших частотах приходится вводить такты ожидания. Хотя для 72MHz рекомендуется 2 такта, но реально с двумя уже можно мк и на 144 запустить В общем ищи в доках FLASH->ACR, там LATENCY.

Залез в startup, да, устанавливается 2ws, согласно PM. Можно и тут поиграться конечно. Выключить буфер предвыборки и поглядеть что он дает в цифрах. Или устанвить 1ws. Да и разгон с одной стороны хорошо, но все же плохо .
Еще какой доступ за пол такта есть ко флеш HLFCYA: Flash half cycle access enable.

Попробуй обьявить так че по скорости будет?
register uint32_t a __asm("r12");
a = -1;

Переменная а в принципе не использовалась. Смысл исполнения кода из флеш и хранения массива во флеш был как можно больше занять шину ICode, но не занимать остальные системные шины. И затем сравнить исполнение кода из озу, при том же массиве констант во флеше.

Для этого в foo была введена переменная buf не волатайл (чтобы не занимала системную шину), наверняка она была регистром, а чтобы оптимизатор не выкинул вычисления, результат сохранялся в переменную а. Но по всей видимости он ее все равно выкинул каким-то образом. Переменная а была объявлена только в области видимости функции, переменная а нигде не использовалась (варнинг был об этом). Однозначно, а нигде не могла использоваться(что четко видно компилятору) и видимо это дало повод компилятору все оптимизировать не смотря на то, что она волатайл. Т.е. первый эксперимент с foo, был неудачный, т.е. не вышло то что я хотел.

Объявив же a глобально, код заработал именно так, как и был написан. Т.е. уже понадобились данные из флеш, что и сильно понизило скорость выполнения кода из флеш.

Я думаю, что определение а в регистр эффекта не должно дать. Наверное сейчас попробую.

Дизассемблер листинг прикладывай увидим тогда что там было, иначе вангование на кофейной гуще.
Ну смотри сам я просто увидел код с твоей переменной подумал что если...измениться что нет
Можешь по шагам пройтись в отладке и посмотреть где лежит переменная в ОЗУ или регистре.

foo при volatile uint32_t a ;

Спойлер

Код:

          foo:
080006c9:   push {r4, r5}
080006cb:   ldr r0, [pc, #36]       ; (0x80006f0 <foo+40>)
080006cd:   ldr r5, [pc, #36]       ; (0x80006f4 <foo+44>)
57                  GPIOA->ODR^=1;//Инвертируем выход A0
080006ce:   ldr r4, [pc, #40]       ; (0x80006f8 <foo+48>)
080006d0:   ldr r2, [r4, #12]
62                  while(i--)
080006d2:   movs r3, #254   ; 0xfe
57                  GPIOA->ODR^=1;//Инвертируем выход A0
080006d4:   eor.w r2, r2, #1
080006d8:   str r2, [r4, #12]
60                  uint32_t buf=0;
080006da:   movs r2, #0
64                     buf+=Mass[i];
080006dc:   ldr.w r1, [r0, r3, lsl #2]
62                  while(i--)
080006e0:   subs r3, #1
080006e2:   uxtb r3, r3
080006e4:   cmp r3, #255    ; 0xff
64                     buf+=Mass[i];
080006e6:   add r2, r1
62                  while(i--)
080006e8:   bne.n 0x80006dc <foo+20>
66                  a=buf;
080006ea:   str r2, [r5, #0]
67               }
080006ec:   b.n 0x80006d0 <foo+8>

при volatile register uint32_t a __asm("r12");

Спойлер

Цитата:

foo:
080006c9: push {r4}
080006cb: ldr r0, [pc, #32] ; (0x80006ec <foo+36>)
080006cd: ldr r4, [pc, #32] ; (0x80006f0 <foo+40>)
080006cf: ldr r2, [r4, #12]
080006d1: movs r3, #254 ; 0xfe
080006d3: eor.w r2, r2, #1
080006d7: str r2, [r4, #12]
080006d9: movs r2, #0
080006db: ldr.w r1, [r0, r3, lsl #2]
080006df: subs r3, #1
080006e1: uxtb r3, r3
080006e3: cmp r3, #255 ; 0xff
080006e5: add r2, r1
080006e7: bne.n 0x80006da <foo+18>
080006e9: mov r12, r2
080006eb: b.n 0x80006ce <foo+6>

Коды практически идентичны. Но частота все-таки поднялась. С 7,418кГц до 10,050кГц.
Сейчас попробую код с переменной в регистре из ОЗУ запустить.

Добавлено after 4 minutes 37 seconds:
Код из ОЗУ при volatile register uint32_t a __asm("r12");
Частота 10,050

Спойлер

Цитата:

foo:
20000000: push {r4}
20000002: ldr r0, [pc, #32] ; (0x20000024 <foo+36>)
20000004: ldr r4, [pc, #32] ; (0x20000028 <foo+40>)
20000006: ldr r2, [r4, #12]
20000008: movs r3, #254 ; 0xfe
2000000a: eor.w r2, r2, #1
2000000e: str r2, [r4, #12]
20000010: movs r2, #0
20000012: ldr.w r1, [r0, r3, lsl #2]
20000016: subs r3, #1
20000018: uxtb r3, r3
2000001a: cmp r3, #255 ; 0xff
2000001c: add r2, r1
2000001e: bne.n 0x20000012 <foo+18>
20000020: mov r12, r2
20000022: b.n 0x20000006 <foo+6>

Добавлено after 5 minutes 59 seconds:
А теперь код из ОЗУ, но переменная обратно volatile uint32_t a ;

Спойлер

Цитата:

foo:
20000000: push {r4, r5}
20000002: ldr r0, [pc, #36] ; (0x20000028 <foo+40>)
20000004: ldr r5, [pc, #36] ; (0x2000002c <foo+44>)
20000006: ldr r4, [pc, #40] ; (0x20000030 <foo+48>)
20000008: ldr r2, [r4, #12]
2000000a: movs r3, #254 ; 0xfe
2000000c: eor.w r2, r2, #1
20000010: str r2, [r4, #12]
20000012: movs r2, #0
20000014: ldr.w r1, [r0, r3, lsl #2]
20000018: subs r3, #1
2000001a: uxtb r3, r3
2000001c: cmp r3, #255 ; 0xff
2000001e: add r2, r1
20000020: bne.n 0x20000014 <foo+20>
20000022: str r2, [r5, #0]
20000024: b.n 0x20000008 <foo+8>

Частота 11.7кГц. Я такой уже тест делал, повторил еще раз.

Т.е. быстрее, чем с переменной в регистре (из флеш логично), но и быстрее чем в том же ОЗУ.

----------
Очень-очень все мутно со скоростью выполнения.

Добавлено after 16 minutes 40 seconds:
Запустил код "флеш - флеш", т.е. когда частота 7кГц, но с 1ws, замолотил с более чем 12кГц. С 0WS зависло.

Однако вендер почему-то указал что должен быть 2WS, не просто же так, чтобы замедлить МК.

Оптимизация какая включена?

О2

Добавлено after 43 seconds:
Но основной смысл топика не как ускорить код, а где он быстрее работает.