STM32F407 + прерывание + время реакции, Меняется время реакции на внешнее событие Опции

[ШСА]

Дорогие коллеги!
Сталкивался ли кто нибудь с такой тонкой и непонятной мне проблемой - значительным изменением времени входа в обработчик прерывания по внешнему событию в зависимости от команд, выполняемых в этот момент в основной программе?
Конкретная ситуация: В микроконтроллере STM32F407 в main-е крутится некая большая программа. Когда наступает внешнее событие, а именно - отрицательный фронт на EXTI_Line1, вызывается обработчик прерывания void EXTI1_IRQHandler(void). В нём обнуляется таймер TIM6, тактируемый частотой 84 МГц, и начинается вывод информации в виде набора импульсов, привязанных к значениям TIM6. Когда вывод закончен - выходим из обработчика (TIM6 оставляем молотить впустую).
Замечено следующее: Время от момента внешнего события до появления первого импульса на выходе нестабильно и меняется (по осциллографу) более чем на 0,2 мкс при тактировании ядра 168 МГц. Иными словами, время вызова обработчика может увеличиваться (или уменьшаться) аж на 34 такта! Причём меняется оно в зависимости от кода, выполняемого в данный момент в main-е. Самое большое изменение этого времени (в сторону уменьшения) происходит при выполнении (в main-е) цикла очистки области памяти:
for(i = 0; i < 60768; i++) *j++ = Сonst;

А согласно описанию на Cortex-3 время вызова обработчика прерывания составляет от 6 до 11 тактов ядра. И уж никак не должно зависеть от содержания прерываемой программы (DMA не используется)!

В чём причина этого явления и как с ним бороться?
Буду признателен за любые идеи или информацию.

[Golikov A.]

Флаги очищаются в конце обработчика, так что вложенные прерывания исключены.

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

Опять же ускоритель флешь, если вы попадаете не на 16 на 32 битные команды то ему больше 4 команд не выбрать, а частота выборки команд у него в почти 8 раз меньше, так что скакнув прерыванием в не закишированную область, да еще и попав на 32 битную команду, у вас все здорово притормозится, а в след раз вы можете попасть уже в область выбранную и сохраненную в ускорителе, а потом вы ее можете почистить и так по кругу, так что у вас там есть где набрать нестабильность ИМХО...

ремя входа в прерывание можно сократить, если использовать FIQ, а не IRQ, но его на большинстве кортексов нет.

Я могу ошибаться, но вроде как в кортексах уже NVIC, и потому деления на быстрое и медленное уже нет ни в большинстве, а во всех кортексах...

[ШСА]

[quote name='Golikov A.' date='Jul 27 2015, 10:49' post='1354043']
Вроде это как раз гарантия создания повторного прерывания Вложенные прерывания у вас исключает NVIC, а вот очищенный в конце флаг может вызвать прерывание повторно из-за конвейеров,

Это для меня новость. NVIC не будет вызывать прерывания, пока я в обработчике не сброшу флаг своего вектора. А я это делаю в конце. Как может быть вложенный вызов?

Опять же ускоритель флешь, если вы попадаете не на 16 на 32 битные команды то ему больше 4 команд не выбрать, а частота выборки команд у него в почти 8 раз меньше, так что скакнув прерыванием в не закишированную область, да еще и попав на 32 битную команду, у вас все здорово притормозится,

Так прерывание, как непредсказуемое событие, в принципе не может быть закэшировано. Так что конвейер должен быть перезагружен. Потому у STM32F4 время реакции = 6-12 тактов. Вернее должно быть, а вот у меня бывает более 34-х!

[scifi]

Так прерывание, как непредсказуемое событие, в принципе не может быть закэшировано.

Неправда. Если между двумя прерываниями процессор крутится в маленьком цикле (как у вас при очистке памяти), то он может не успеть выбросить из кэша код обработчика прерывания. Тогда вход в обработчик прерывания будет быстрее. Кстати, это легко проверить: на выходе из прерывания нужно сбрасывать кэш, есть для этого соответствующий регистр.

[ШСА]

Неправда. Если между двумя прерываниями процессор крутится в маленьком цикле (как у вас при очистке памяти), то он может не успеть выбросить из кэша код обработчика прерывания. Тогда вход в обработчик прерывания будет быстрее. Кстати, это легко проверить: на выходе из прерывания нужно сбрасывать кэш, есть для этого соответствующий регистр.

Интересная мысль!!! А ведь у меня при очистке памяти время реакции именно уменьшается!
Чтобы мне не копаться, подскажите, как очистить кэш (желательно на языке СИ).

[jcxz]

Выключите сохранение контекста FPU при стэкинге (и резервирование места для него): FPCCR = 0;

Интересная мысль!!! А ведь у меня при очистке памяти время реакции именно уменьшается!
Чтобы мне не копаться, подскажите, как очистить кэш (желательно на языке СИ).

Зачем его чистить? Перенесите ISR в ОЗУ как уже советовали. Причём начало его выровняйте на адрес, кратный размеру строки выборки команд CPU
(вроде STM407 выбирает команды строками по 128байт). И таблицу векторов - тоже в ОЗУ. Лучше - в CCM.

Но самое правильное решение - конечно использовать DMA, выставив ему приоритет доступа к шине выше чем CPU.

[ШСА]

Выключите сохранение контекста FPU при стэкинге (и резервирование места для него): FPCCR = 0;

Зачем его чистить? Перенесите ISR в ОЗУ как уже советовали. Причём начало его выровняйте на адрес, кратный размеру строки выборки команд CPU
(вроде STM407 выбирает команды строками по 128байт). И таблицу векторов - тоже в ОЗУ. Лучше - в CCM.

Но самое правильное решение - конечно использовать DMA, выставив ему приоритет доступа к шине выше чем CPU.

Вы меня своим заявлением слегка контузили.
Я не знаю что такое контекст FPU и стэкинг. Аппаратный FPU (Floating Point Unit) у меня включён, и выключать его нельзя. Это всё, что я знаю про FPU.
Использовать DMA - что я выиграю, и главное - сколько? Ведь фаза выходного импульса плавает аж на 34 такта!
Перенести ISR в ОЗУ мне кажется здравой идеей, сейчас я продумываю как её осуществить, чтобы себе не сильно напортить.

Ребята! Давайте договоримся - если у кого есть идея, излагайте в таком порядке:
1. Гипотеза, объясняющая природу этого явления, а именно - каким образом фоновая программа может влиять на время реакции на внешнее событие, да ещё в таких масштабах;
2. Способ или механизм исключения или компенсации этих задержек;
3. Конкретные рекомендации;
В противном случае я вынужден по вашим рекомендациям гадать, в чём же заключается идея. А это плохо потому, что я не настолько глубоко знаю STM32F4, чтобы по намёку понять всё, что имелось в виду.
Кстати, если есть примеры как оформить ISR в ОЗУ, а тем более таблицу векторов в CCM, дайте ссылочку, чтобы мне поменьше пришлось наступать на грабли.

[jcxz]

Я не знаю что такое контекст FPU и стэкинг. Аппаратный FPU (Floating Point Unit) у меня включён, и выключать его нельзя. Это всё, что я знаю про FPU.

Откройте мануал на CortexM, там есть описание что такое stacking. Это собственно - сохранение некоторых регистров CPU при входе в прерывание.
M4, в отличие от M3, умеет сохранять (или резервировать место для сохранения) также регистры FPU. Если у Вас выключено Lazy context save или МК посчитает что по каким-то причинам контекст
FPU тоже надо сохранить, то в стек вместо 8 слов запишется гораздо больше.
Т.е. - если как я понимаю Вы где-то в фоне использовали FPU, то это и произойдёт.

Использовать DMA - что я выиграю, и главное - сколько? Ведь фаза выходного импульса плавает аж на 34 такта!

Не знаю какой выходной импульс Вы имеете в виду, но Вашу задачу - прерывание на входной импульс и сброс таймера в обработчике этого прерывания, может сделать DMA:
делаете запуск DMA-транзакции по этому самому импульсу, этой транзакцией обнуляете таймер. Задержка запуска DMA-транзакции будет неизмеримо меньше времени реакции на прерывание.
Не знаю правда - поддерживает ли такое DMA-контроллер STM32F407? Но в LPC17xx такое возможно. STM32F407 думаю тоже должен уметь.

Мой обработчик, сообразуясь со таймером, пересылает данные на выходной порт. Так что дёрганья ног здесь более чем достаточно. Таймер сбрасывается в самом начале прерывания, чтобы "синхронизироваться" с внешним событием (в этом-то и ахиллесова пята алгоритма). До следующего события таймер перезагрузиться не успеет, а если это случилось, значит входной сигнал исчез, и можно "уснуть". Так что во время работы таймер никогда не может перезагружаться сам.

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

[ШСА]

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

Интересная идея, но её надо обсчитать: вывод должен происходить каждые 20 тактов ( для таймера от 84 МГц - 10 тактов). Но выводиться должна только половина байта по очереди старший - младший, или младший - старший.
Т.о. за двадцать тактов нужно успеть: "достать" нужный байт, "перевернуть" его как надо, выделить нужную половинку и отправить на выходной порт. Да, ещё следить, когда включить-выключить таймер.

А вот ваша идея насчёт FPU меня потрясла. Действительно, во время короткого цикла очистки памяти в фоне FPU не используется и время реакции на прерывание уменьшается. А в остальных местах программы FPU занято на всю катушку, и время реакции увеличивается. Я посмотрю свои настройки, надеюсь, уж если не решить проблему, то хотя бы уменьшить.

[SasaVitebsk]

вывод должен происходить каждые 20 тактов ( для таймера от 84 МГц - 10 тактов).

Любопытно конечно послушать продолжение, так как многие сообщают подробности, которых в мануале сразу и не заметишь. Такие вещи выясняются, когда конкретную задачу решаешь. ))

Но если по теме, то раз речь идёт о 20 тактах, то всё же задачу требуется решать аппаратно. То есть фоновая задача может отсчитываться процессором, а, этот Ваш вывод, должен выполняться аппаратно. Аппаратно либо средствами процессора, либо внешними аппаратными средствами.

На мой взгляд, это очевидно. Данный процессор, как раз не предназначен для формирования временных диаграмм. Для этих целей требуются процессора с чётко определённым временем выполнения команд, то есть без кэш, без механизмов предвыборки и так далее. Типа AVR, PIC, а так как они по быстродействию не укладываются, то плисину какую-нибудь применить. А процессор должен выполнять свою задачу асинхронно к данному событию. Чем раньше Вы это осмыслите, переделаете железо, тем быстрее решите задачу. Иначе всё равно к этому вернётесь. Моё мнение.

[Сергей Борщ]

На мой взгляд, это очевидно. Данный процессор, как раз не предназначен для формирования временных диаграмм.

Ой, не смешите. Завести массив в ОЗУ, неспешно прописать в него состояния порта через одинаковые промежутки времени, таймер настроить на эти промежутки и пусть DMA от этого таймера циклически пихает этот массив в порт (или через bitband в ногу/несколько соседних ног порта). Прекрасные времянки получаются.

[ШСА]

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

Конечно! Если удастся уменьшить флуктуации до 4 тактов, их уже никто не заметит при 168 МГц. А вот с ОЗУ напряжёнка: Там две страницы видеополя находятся - формируемая и отображаемая. Так что особо не разбежишься.

[jcxz]

А вот с ОЗУ напряжёнка: Там две страницы видеополя находятся - формируемая и отображаемая. Так что особо не разбежишься.

Советую всё-таки открыть мануал на используемый процессор и поискать там что-нить типа Quad-SPI или SDIO. Они позволяют до 4 линий параллельно выводить.
Тогда возможно каждый байт памяти будет использоваться полностью, а не одна тетрада. Да и загрузка шины при DMA-передаче на такой интерфейс
будет ниже чем при передаче DMA->GPIO.
По крайней мере на Tiva (TM4C129), который я сейчас использую, связка Quad-SSI+DMA идеальна для Вашей задачи.
Даже если Вы не будете использовать DMA, то лучше использовать Quad-SPI чем тот ногодрыг, что Вы сейчас пытаетесь сделать.
О ногодрыге вообще стоит забывать сразу после перехода на ARM. Оставить его AVR-щикам.
SPI Вам жёстко даст ту времянку, которую Вы запрограммируете ему, вместо болтанки с программным таймером и ногодрыгом.

[ШСА]

Наконец сегодня дошли руки проверить хоть какие-то гипотезы. Собственно, рабочих гипотез осталось две.
Начну с первой. jcxz предположил, что причиной влияния фоновой программы на время реакции обработчика и является сохранение в стеке регистров FPU и предложил его запретить. Такой запрет не помешал бы работе системы, поскольку FPU в обработчиках прерываний не используется, а значит и состояние FPU от прерывания не изменилось бы.
В STM32F4 это делается просто: FPU->FPCCR &= ~((1U << FPU_FPCCR_ASPEN_Pos) | (1U << FPU_FPCCR_LSPEN_Pos));
В результате явление не исчезло, ну существенно уменьшилось. Т.е влияние фоновой программы на прерывания осталось, но флуктуации времени запуска обработчика прерываний снизились не менее чем в два раза.
Мораль: Количество сохраняемых в стеке регистров ЦП при прерывании зависит не от того, выполняло или нет в этот момент FPU какую нибудь команду, а от того, что записано в регистре CONTROL с помощью FPU->FPCCR.
Поэтому запрещая сохранение регистров FPU можно изменить среднее время реакции обработчиков на внешние события и изменить интенсивность использования стека. Но к флуктуациям времени вызова обработчика в зависимости от команды, выполняемой в этот момент фоновой программой, это не имеет отношения.

Осталась вторая гипотеза. scifi полагал, что время реакции обработчика зависит от длины кэша команд МК. Т.е. механизм такой: если фоновая программа выполняет длительный короткий цикл, в течение которого происходит несколько прерываний, то после первого прерывания из кэша не вытесняется начало обработчика прерывания и все последующие прерывания происходят быстрее.
Чтобы проверить эту идею нужно было очистить кэш команд перед выходом из обработчика.
Я не нашёл (да пока и не искал) такой команды, но чтобы проверить эту идею в фоновой программе внутри короткого цикла вставил вызов небольшой функции, которая ничего полезного не делала, но и ничего не портила. Фактически, цикл перестал быть коротким. Результат - эти флуктуации исчезли!
Мораль сногсшибательная: кэш команд в STM32F4, который так здорово "разгоняет" ЦП, может быть причиной непредсказуемых флуктуаций времени реакции обработчиков на внешние события. Причём флуктуаций весьма чувствительных - до 400 нс, когда используется FPU и включено сохранение его регистров в стеке (это происходит по умолчанию при включении FPU), и когда различные прерывания конкурируют между собой. А управлять этой непредсказуемостью будет фоновая программа!

Так что мой обработчик придётся выбросить.
Всем, кто принял участие в этом мозговом штурме ОГРОМНОЕ СПАСИБО!
И, конечно, jcxz и scifi от меня особая благодарность, за активизацию моих мозгов.

Советую поискать там что-нить типа Quad-SPI или SDIO. Они позволяют до 4 линий параллельно выводить.

У STM32F407 есть одна неприятная особенность - пины SDIO пересекаются с пинами видеокамеры DCMI. Придётся выбирать. А Quad-SPI там нет.

Сообщение отредактировал ШСА - Jul 30 2015, 19:02

[SasaVitebsk]

Мораль: Количество сохраняемых в стеке регистров ЦП при прерывании зависит не от того, выполняло или нет в этот момент FPU какую нибудь команду, а от того, что записано в регистре CONTROL с помощью FPU->FPCCR.

Вы хотя бы задумались. А как может быть по другому?!
Какая разница где именно в фоновой задече используется FPU? Если имеется шанс запортить используемые регистры, то их надо сохранять!
Здесь на крайняк, может компилятор грамотно обсчитывать имеется ли в Ваших прерываниях работа с FPU. Но учитывая как работает компилятор, и этого не получается.
Например Вы можете вызвать из прерывания ф-цию, которая использует FPU. Или Вы можете написать обработчик на ассемблере и компилятор даже знать не будет о том, что Вы в прерывании используете FPU. Поэтому действия разработчиков процессора единственно верны.

Мораль сногсшибательная: кэш команд в STM32F4, который так здорово "разгоняет" ЦП, может быть причиной непредсказуемых флуктуаций времени реакции обработчиков на внешние события. Причём флуктуаций весьма чувствительных - до 400 нс, когда используется FPU и включено сохранение его регистров в стеке (это происходит по умолчанию при включении FPU), и когда различные прерывания конкурируют между собой. А управлять этой непредсказуемостью будет фоновая программа!

А здесь Вы просто капитан очевидность!
Именно за счёт этого и получен выигрыш в быстродействии. Я вообще не понимаю что Вас удивляет? Так работают все процы CISC, в частности. И совершенно очевидно, что в Cortex-M7 джитер будет ещё выше.
Он будет в любом процессоре. В процах без кэша он будет меняться на разницу в времени исполнения команд, которые Вы используете в фоновой задаче. Например в AVR, при применении умножения +1 такт.

Поэтому Вам несколько раз настойчиво советуют использовать аппаратные средства либо самого процессора либо внешнего устройства.

[ШСА]

Поэтому действия разработчиков процессора единственно верны.
Именно за счёт этого и получен выигрыш в быстродействии. Я вообще не понимаю что Вас удивляет?

А кто говорит, что разработчики из ST что-то сделали неправильно? STM32F4 - серия шикарных микроконтроллеров! Но, как всё шикарное, требуют аккуратного обращения.
А удивляет меня не задержка вызова прерываний, и не джиттер при разборках обработчиков между собой. Это всё общеизвестно. А вот то, что на время вызова обработчика может влиять содержимое фоновой программы - для меня открытие. Я с таким никогда не встречался и не читал о таком. Результат проведённого исследования - понимание механизма взаимовлияния фона на реактивность системы, которое позволит осознаннее выбирать программные средства. Правильно заметил jcxz, что от AVR-ные подходы для ARM-ов не всегда годятся.
И понять это явление помогло именно включённое FPU, которое на порядок увеличило этот эффект, и заставило разбираться до конца.