STM32F0 Время реакции и выполнения прерывания Опции

[Влад Р.]

Добрый день!

Имеется МК STM32F0. Работает на частоте 48 МГц. Фоновая программа представляет собой пустой бесконечный цикл. По фронту сигнала на выводе МК настроено внешнее прерывание. В обработчике прерывания только операции с портами ввода/вывода и логические операции. Все задействованные выводы сконфигурированы на работу на максимальной скорости.
Согласно статье "A Beginner’s Guide on Interrupt Latency - and Interrupt Latency of the ARM® Cortex®-M processors" время реакции на прерывание для ядра Cortex-M0 составляет 16 машинных циклов. Первой командой после входа в обработчик я считываю один из портов в/в, затем на одном из выводов другого порта устанавливаю высокий уровень. Время между фронтом внешнего сигнала, вызвавшим внешнее прерывание, и установкой высокого уровня на выводе, указанном выше, составляет 800 нс. Почему такое большое время и как можно его сократить?
В той же статье говорится о джиттере времени реакции, но неясно от каких факторов он может зависеть?
Время выполнения обработчика прерывания составило 1,5 мкс, что тоже неожиданно много. Также буду рад советам как уменьшить.

Используется Keil 5.17. Пробовал различные уровни оптимизации компилируемого кода, оптимизацию по времени/объему. Не давало положительных результатов. Размещение обработчика прерывания в ОЗУ позволило сократить время его выполнения на 0,2 мкс, но не повлияло на время реакции на прерывание.

[SasaVitebsk]

В статье указано, что 16 машинных циклов пройдёт от прерывания, до выполнения 1 команды прерывания. То есть до входа в прерывание. Сама п/п прерывания, должна сначала сохранить текущий контекст в стеке (текущие регистры) ну и возможно что-то проинициализировать (смотря как вы программу написали), после чего она приступит к выполнению программы пользователя. Учитывая, что 16 тактов это уже 333 нс, то 800 в целом неплохо. Не совсем понятно откуда у вас существенный выигрыш при размещении прерывания в ОЗУ. По моему у вас должно бы 0 циклов ожидания, при такой тактовой.
Ну и 1.5 мкс на выполнение тоже неплохо... )) всё относительно. Еще недавно это было совершенно недостижимо. )))
А в целом если у вас критическое исполнение, причём масштабы на микросекунды, то необходимо использовать аппаратные ресурсы.
Джитер образуется, за счёт того, что некоторые комманды выполняются > одного такта, а также за счёт работы конвеера, на сколько я понимаю.

[jcxz]

существенный выигрыш при размещении прерывания в ОЗУ. По моему у вас должно бы 0 циклов ожидания, при такой тактовой.

Обычно флеш в МК типа Cortex-M работает на частотах около 20МГц, так что 0-wait-states уже не получается.
Плюс ещё - какая ширина шины предвыборки в этом МК? Можно кстати выровнять начало ISR на границу 128бит - может помочь предвыборке.

[SasaVitebsk]

Обычно флеш в МК типа Cortex-M работает на частотах около 20МГц, так что 0-wait-states уже не получается.
Плюс ещё - какая ширина шины предвыборки в этом МК? Можно кстати выровнять начало ISR на границу 128бит - может помочь предвыборке.

Да посмотрел, там 0 ws до 24МГц и 1ws выше. Ширина шины флэш 32 бита всего, правда есть prefetch bufer небольшой... В целом достаточно убого, по ускорению выборки.

[jcxz]

Да посмотрел, там 0 ws до 24МГц и 1ws выше. Ширина шины флэш 32 бита всего, правда есть prefetch bufer небольшой... В целом достаточно убого, по ускорению выборки.

Ну вот, а это означает, что хоть и установлена 48МГц, но код, состоящий из последовательности 4-байтовых команд, будет выполняться со скоростью 24MIPS. Так что перенос в ОЗУ должен помочь.
Если будет поток из одних 4-байтовых команд, то prefetch buffer никак не поможет. Хотя у ТС в данном случае команды в основном 2-байтные.

Прошу прощения. Установка пина выполнялась исключительно для того, чтобы понять сколько времени занимает вход в прерывание и первое считывание порта. В выложенном листинге ее нет. Было примерно uint16_t db = GPIOC->IDR & 0x1FFF;
uint8_t data;
GPIOB->BSRR = GPIO_BSRR_BS_12;
data = db;

А теперь посмотрите листинг - сколько там команд, просуммируйте со временем стекинга и прочими временами. Как раз и получите, что имеете.
Как уже Вам советовали - не стоит использовать 8-и и 16-битные переменные где ни попадя на 32-битном CPU. Это приводит к лишним командам в коде.

[ViKo]

Хотя у ТС в данном случае команды в основном 2-байтные.

Ага. Все! И неспроста.