Я уже Вам приводил ссылку. Там всё есть, и циклы тоже.

Описание команд там есть. По нем и разбираюсь. Но где указана длительность не заметил. Можете тыкнуть носом?

 DDI0432C_cortex_m0_r0p0_trm.pdf ( 461.17 килобайт ) Кол-во скачиваний: 101

Столбец Cycles
раздел 3.3 стр 3-4 и до горизонта

Могу: тут.
Но имейте в виду: задержки флеша и доступа к периферии (GPIO) там не указаны.

http://electronix.ru/forum/index.php?showt...869&hl=IJAR

При текущей частоте задержка флэш составляет 1 Wait State. Это значит что при выполнении кода из флеша к длительности всех команд можно добавить 1 машинный цикл? Как оценить на сколько в такой ситуации ускоряет выполнение буфер предварительной выборки? Задержка доступа к периферии определяется исключительно частотой шины, на которой она сидит, и собственными предделителями конкретной периферии? Или есть еще влияющие факторы?


Спасибо за ссылку! Фейспалм мне, что ненагуглил эту тему раньше.

Написал в отдельном файле простой обработчик, который для начала будет просто устанавливать пин в единицу и сбрасывать флаг прерывания. Среда компилирует файл. Но не могу понять как задействовать его в основной программе?

IARом пользуетесь? Тогда "IAR C/C++ Development Guide" главу "Assembler language interface" курить до просветления

Keil

Прошу прощения за отклонение от темы беседы. Но поправлюсь рядом со своим же постом.

Точнее будет перевод "Т.к. bit-band регион есть опция ARM CM0+...". Но в открытой документации от ARM не было bit-band региона для этих ядер и эта формулировка тоже некорректна. Во многих реализациях ARMv6-M от NXP в регионе 0x200000000 было ОЗУ с дополнительными фичами самого NXP. Например IOHandler, USB буфер и прочее. У Фрискейла там тоже ОЗУ с дополнительной логикой. Похожей на bit-band. Написали бы <опция Кортексов или ARM>, а не так спорно.

На счёт ядра ошибся. SRAM работают с ядром через локальные шины. NVIC, MPU, кэш (которого нет у v6-M) и (какие-то) отладочные узлы встроены в ядро.

Ради эксперимента взял LPC435x, у которого на блок-схеме нарисованы отдельные ядра CM4 и CM0 (без плюса), а вся память и периферия общая. Ядро CM0 при обращении к региону 0x22000000 (bit-band) падает в Hard Fault. Хотя почти без накладных расходов и для удобства юзера логичнее было сделать этот регион общим. Но и тогда bit-banding было бы опцией (любого) процессора, а не архитектуры ARMv6-M или (под)группы.


Можно сказать шире: в инструкциях чтения и записи внеядерного адресного пространства могут быть дополнительные такты задержек. Которые ARM не знает и не может указывать. И сами разработчики кристаллов все нюансы часто не описывают.

Сообщение отредактировал GetSmart - Jun 25 2016, 00:32

Нет. Задержка добавляется при отсутствии следующей для выполнения команды в буфере предвыборки.
Например: после перехода буфер опустошается. Через 2 такта он будет заполнен 4-мя байтами (если верно, что ширина шины выборки команд == 32 бита как тут ранее писали).
Если в этих 4-х байтах 2 команды и нет перехода, то за время пока они выполняются, буфер предвыборки может успеть прочитать ещё 32 бита (если шина к данной области памяти не занята).
Если же в этих 4-байтах команда 4-байтовая и её длительность в циклах ==1 (не знаю - есть-ли такие в M0?), то тогда да - опять будет опустошение предвыборки и приостановка на такт декодера команд.
Или если буфер предвыборки не успел прочитать след. байты из-за занятости шины (если был доступ CPU к данным в этом-же регионе памяти, или был доступ к данному региону другого bus-mastera по этой-же шине).
В общем - на линейном коде без ветвлений и если в данном регионе находится только исполняемый код, скорей всего никаких дополнительных тактов ожидания не будет.
На переходах будут приостановки. Хотя - может в Вашем МК буфер предыворки содержит несколько строк кеша? Но в Вашем вряд-ли. В некоторых МК буфер предвыборки имеет ёмкость в неск. сток кеша (в Tiva например).
Ещё дополнительные приостановки предвыборки могут быть если целевой адрес перехода не кратен 4. Имхо - буфер предвыборки скорей всего работает с выровненными адресами, а значит при невыровненном на 4 целевом адресе перехода, за первый доступ считает только максимум одну 2-байтовую команду, и если её длительность ==1 икл, то опять будет stall на дополнительный цикл на выборку следующих 32 бит.
Хотя всё это я описал для M3/M4, но думаю в M0 - аналогично.

Совет: там где у Вас switch, используйте табличный переход LDR PC,[Rx] - это сделает все ветвления case одинаковой длительности и избавит от необходимости if (!(db & (0x01 << 12))) {.

В Reference manual сказано так: "The prefetch buffer is 3 blocks wide where each block consists of 4 bytes." Видимо как раз те самые 32 бита.


В STM32F0 кэша точно нет.


Тут типа намекают, что адреса переходов лучше делать кратными 8 байтам:
"The implementation of this prefetch buffer makes a faster CPU execution possible as the CPU fetches one word at a time with the next word readily available in the prefetch buffer. This implies that the acceleration ratio will be of the order of 2 assuming that the code is aligned at a 64-bit boundary for the jumps."


ОК, как слеплю окончательный код, выложу на суд.

Пока разобрался как задействовать код из asm-файла. Не хватало всего одной директивы:
EXPORT EXTI4_15_IRQHandler
Очень помогло: Mixing C, C++, and Assembly Language
Вот, целиком в текущем виде:

У СМ0 один канал подгрузки данных (шина), У СМ3 (и старше) две или даже три. СМ0 выполняя инструкцию обращения к памяти будет отнимать эту шину от подгрузки кода.


После сброса периферии, вызвавшей обработчик нужно несколько тактов ожидания. Можно просто NOP-ов. Если после STR выполнить сразу BX lr, то будет сразу же повторный "залёт" в обработчик. Обычно нужно 3-10 тактов ожидания. Сколько конкретно - ведомо разве что разработчику всего чипа. Можно определить тестируя в железе. Лучше делать с запасом. Можно использовать инструкции DSB, т.к. у СМ0 DSB всегда константной длительности. Но инструкция шириной как два NOPa (32 bit).

Сообщение отредактировал GetSmart - Jun 25 2016, 02:08

Что-то я подобного не замечал. Написал то же самое на Си и скомпилировал, никакие дополнительные регистры не стекируются (только те, что автоматом). При этом в полученном коде инструкция BX следует сразу за STR.

Компилятор делает оптимально. Суть не в этом. Если у Вас в асм-коде вторая STR сбрасывает сигнал, идущий от перефирии к NVIC, то в общем случае (хоть в Си хоть в асм) нежелательно это делать в самом конце IRQ. Можно либо нопы вставлять, либо какое-то другое действие обработчика в самый конец перенести, особенно когда на асме (видны все инструкции).

Но за STM32 не берусь утверждать. На NXP (17хх, 13хх) эти дополнительные задержки нужны были точно. Странно, если NXP сделал свою часть чипа так, что от периферии сигнал снятия запроса прерывания доходил до NVIC с большой задержкой, которой нет у STM32. В доках NXP нужность задержек даже не описана. Так что приходилось их использовать для большей безопасности портирования кода. Может они эту граблю специально продемонстрировали чтобы программер был осторожней и сбрасывал запрос чуть раньше выхода из IRQ.

Сообщение отредактировал GetSmart - Jun 26 2016, 04:16

Ну собственно эти "3 blocks" по 32 бита и есть миникеш. Пока из одного блока идёт декодирование команды, другие могут заполняться.
В Tiva так же примерно, только размер блока ==256бит (по ширине шины предвыборки) и их кол-во больше. И в LPC17xx так же.


Хм... похоже что ширина шины предвыборки скорей всего == 64 бита всё-таки. Раз за такт выбирается одно слово + второе слово оказывается уже в буфере предвыборки за тот же такт.


Обычно чтобы символьные имена из асм-файла были видимы в других исходных файлах (си и асм), нужно это символьное имя объявить в директиве PUBLIC.
Ну и, естественно, прописать прототип в си-хидере.
И наоборот: чтобы в асм-файле были видимы имена из других объектных файлов, нужно их указать в директиве EXTERN.
EXPORT я не использую нигде.


Можно это квитирование прерывания просто поставить в начале ISR, сразу после входа. Я так и делаю обычно.