Ну, собственно, мой обработчик IRQ это и делает, только без использования capture unit. По наступлении события таймер сбрасываем, а потом, следя за его изменением, пишем в выходной порт данные из ОЗУ. Время между началом события и первым выходным импульсом = 10,5 мкс. За это время я успеваю многое пересчитать и даже запустить АЦП. Во всяком случае две трети времени от этих 10,5 мкс занимает цикл ожидания.

А нельзя ли по событию сделать DMA для сброса таймера и запуск обработки прерывания для вычислений? У DMA джиттер поменьше должен быть.

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

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

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

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

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

Выборка 1 команды из флеш-памяти занимает 6 тактов процессора (для частоты 168МГц). При выполнении линейного куска кода флеш-акселератор скрывает эту задержку (потому что считывает по 128 бит). Когда происходит прерывание, флеш-акселератор помочь ничем не может и вы попадаете на максимальную задержку.
Для начала попробуйте перенести в ОЗУ таблицу векторов - получите экономию 5 тактов минимум.

Сообщение отредактировал LightElf - Jul 27 2015, 08:34

Интересная мысль насчёт DMA. Как-то не думал о таком варианте. Вообще я DMA как-то побаиваюсь, потому что процессор может "уснуть" неизвестно когда. Но впрочем, это мои фобии. А джиттер в реальности слишком велик (34 такта - не кот чихнул), и блохи от DMA здесь не играют роли.
Ведь главное - понять необычность ситуации: фоновая программа влияет на скорость вызова обработчика. Ведь она не привязана к внешним событиям, чего-то там себе считает и считает. А у обработчика при этом плавает время реакции! Да плавает-то как - в три раза превышает допуск!

Мне кажется, что самый здравый совет был вот этот:

Сначала надо уточнить, где именно возникает задержка, а уже потом выяснять её причину.

флеш и кэш
выше правильное предложение - выполнять из озу, работать будет медленнее, но гораздо стабильнее
а ну да, можно загнать тактовую на 24 мгц с нулевым ожиданием и посмотреть на результат


Сообщение отредактировал Огурцов - Jul 27 2015, 08:38

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

Я углядел нужные биты в регистре FLASH_ACR. А дальше сами читайте, там вроде бы понятно написано.

24 МГц можно попробовать, чтобы не переделывать программу. С единственной целью убедиться в исчезновении этого явления. Жаль только, что будет много паяльных работ, т.к. тактовая частота МК в моей системе имеет критическое значение.

1. Можно отключить флэщ акселератор и тогда время будет стабильное, медленное, но стабильное.

2. По поводу Там не только в конвейере дело, а еще в сохранении контекста


3.1 НВИК не будет повторно вызывать прерывание даже если вы сбросите в начале и оно опять случиться, пока не выйдете из этого прерывания повторный вызов того же приоритета не проихойдет
3.2. А вот сбрасывая флаг в конце вы имеете шанс выйти из прерывания до того как флаг реально сброситься, там что-то с конвейерами и перестановкой команд, и выйдя из прерывания НВИК ловит не сброшенный флаг и повторно входит в прерывание.
Так что вложенного вызова не будет, а вот повторный вполне может быть.

Это важно, я это изучу. Спасибо.

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


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

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

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