Jump to content

    

STM32F4 как уменьшить время входа в обработчик прерывания

Добрый день.

STM32F4, DMA непрерывно (двойной буфер) по таймеру выдает данные на пины. Периодически надо менять период таймера (минимум  - 50 нс, максимум - 500), это делается в обработчике прерывания DMA. Прерывание настроено на окончание передачи буфера.

Проблема в том, что когда прога доходит до изменения периода таймера, идет новый цикл выдачи данных, то есть от момента выставления флага ТС до работы обработчика прерывания проходит достаточно большое время - сотни нс.

Как уменьшить время от момента выставления флага ТС до входа в обработчик?

Share this post


Link to post
Share on other sites
1 minute ago, Алексей ВМ said:

STM32F4, DMA непрерывно (двойной буфер) по таймеру выдает данные на пины.

 

1 minute ago, Алексей ВМ said:

Как уменьшить время от момента выставления флага ТС до входа в обработчик?

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

 

 

Share this post


Link to post
Share on other sites
8 minutes ago, Forger said:

 

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

 

 

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

 

Для F4 interrupt latency 12 циклов, это максимум 75 нс. Откуда может набегать доп время?

Interrupt Latency on the Cortex-M processor family

The interrupt latency of all of the Cortex-M processors is extremely low. The latency count is listed in table 1, and is the exact number of cycles from the assertion of the interrupt request up to the cycle where the first instruction of the interrupt handler is ready to be expected, in a system with zero wait state memory systems:

Processors Cycles with zero wait state memory
Cortex-M0 16
Cortex-M0+ 15
Cortex-M3 12
Cortex-M4

12

Edited by Алексей ВМ

Share this post


Link to post
Share on other sites
6 minutes ago, Алексей ВМ said:

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

Остается строчить на голом asm, вырезая все, что можно. Ну и стек прерываний конечно разместить в CCM памяти.

 

Share this post


Link to post
Share on other sites
2 minutes ago, Forger said:

Ну и стек прерываний конечно разместить в CCM памяти. 

 

Не подскажете, куда копать?

Share this post


Link to post
Share on other sites
Just now, Алексей ВМ said:

Не подскажете, куда копать?

В даташит и инструкцию к компилятору, как размещать данные в неких секциях ))

Все зависит от среды и компилятора.

 

Share this post


Link to post
Share on other sites
2 hours ago, Алексей ВМ said:

Cycles with zero wait state memory

 

2 hours ago, Алексей ВМ said:

Cortex-M4

12

У вас явно НЕ zero для выбранного STM32F4, а zero при работе из flash на нормальной тактовой уже не поставить ((

Как еще вариант - соотв. обработчик прерываний запихивать в ОЗУ.

Share this post


Link to post
Share on other sites

А FPU регистры там, случайно, не сохраняются? 

Share this post


Link to post
Share on other sites
5 часов назад, Forger сказал:

У вас явно НЕ zero для выбранного STM32F4, а zero при работе из flash на нормальной тактовой уже не поставить ((

Поставить. У STM32F4 есть кеш. А при такой частоте входов как у ТС, код ISR почти гарантированно будет в кеше.

Тут безальтернативно - ассемблер. И то вряд-ли. Скорее всего - только менять железо.

Кроме входа в ISR, есть ещё и выход. Да плюс - занятость шины работающим DMA и пр. Так что за 50 нс на весь ISR - я бы даже не надеялся. Разве что пустой ISR, вообще без команд, уложится.

И приоритет этого ISR - надеюсь на максимуме?

 

35 минут назад, ViKo сказал:

А FPU регистры там, случайно, не сохраняются? 

Думаете ТС в своём ISR-е перепрограммирования DMA использует FPU?  :biggrin:

Share this post


Link to post
Share on other sites

Думаю, что прерываний у ТС не одно. 

Share this post


Link to post
Share on other sites
7 часов назад, Алексей ВМ сказал:

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

Есть пословица про вас: "Семь раз отмерь, один - отрежь". Видимо вы её не знали перед началом проектирования   :biggrin:

7 часов назад, Алексей ВМ сказал:

Для F4 interrupt latency 12 циклов, это максимум 75 нс. Откуда может набегать доп время?

А у вас всё время работы программы состоит только из одних входов в прерывание?  :shok:

Share this post


Link to post
Share on other sites
32 минуты назад, jcxz сказал:

Думаете ТС в своём ISR-е перепрограммирования DMA использует FPU?

Он не сообщил что отключил сохранение регистров FPU, следовательно они у него сохраняются.

Но это всё не важно. Важно - это смотреть в будущее на один период дальше чем сейчас (и обязательно с оптимизмом!).

 

Регистры таймера ARR и RCR буферизованы и в них можно записать новые значения (для следующего периода) заблаговременно.

Загрузка новых значений из буферных регистров в рабочие регистры произойдёт по событию update event. Сразу после update event можно грузить новые данные.

Самое правильное это по update event запускать второй канал DMA, который за время текущего периода запишет в ARR и RCR данные для следующего. А потом по прерыванию от DMA готовить данные в буфере для следующих периодов.

Только DMA должно писать в регистры таймера не напрямую, а используя регистры TIMx->DCR и TIMx->DMAR.

Share this post


Link to post
Share on other sites
5 минут назад, SSerge сказал:

Он не сообщил что отключил сохранение регистров FPU, следовательно они у него сохраняются.

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

Хотя можно конечно заставить принудительно сохраняться всегда. Но это надо специально постараться.

5 минут назад, SSerge сказал:

Но это всё не важно. Важно - это смотреть в будущее на один период дальше чем сейчас (и обязательно с оптимизмом!).

Это важно, так как если всё-таки используется FPU хоть где-то в проекте, то значит и где-то будут сохранения/восстановления. А значит прерывание может попасть на начало этого процесса. И это время прибавится ко времени входа в ISR.

5 минут назад, SSerge сказал:

Самое правильное это по update event запускать второй канал DMA, который за время текущего периода запишет в ARR и RCR данные для следующего. А потом по прерыванию от DMA готовить данные в буфере для следующих периодов.

Это ничем не поможет если период между двумя прерываниями, как пишет ТС, у него может быть = 50нс. Просто просуммируйте: время_входа_в_ISR + длительность_выполнение_ISR + время_выхода + задержку на прерывание_текущей_фоновой_операции_макс_длительности + макс._длительность_запрета_прерывания_во_всём_коде + задержку_из-за_занятости_шины_работающим_DMA.

Тут скорей всего уже ничего не поможет...  :unknw:

Share this post


Link to post
Share on other sites

Есть ещё возможность ускориться заплатив за это размером буферов.

Последовательность 50нс, 500нс, 50нс, 500нс превращается в 22 раза по 50нс, причём перезагрузку ARR и RCR придётся делать только один раз (а не 4), но в буфере первого DMA будет не 4 порции данных, а 22. И шины будут сильно загружены циклами DMA.

Share this post


Link to post
Share on other sites

Прошу прощения, если я неполно описал проблему.

Заказчик на ходу изменил требования, приходится изворачиваться...

Время между прерываниями - 68 циклов таймера, мин период таймера- 50 нс, получается 3.4 мкс. Вся обработка прерывания занимает 2 мкс.

Приоритет у прерывания DMA наивысший.

 

38 minutes ago, SSerge said:

Важно - это смотреть в будущее на один период дальше чем сейчас (и обязательно с оптимизмом!).

Регистры таймера ARR и RCR буферизованы и в них можно записать новые значения (для следующего периода) заблаговременно.

Загрузка новых значений из буферных регистров в рабочие регистры произойдёт по событию update event. Сразу после update event можно грузить новые данные.

Самое правильное это по update event запускать второй канал DMA, который за время текущего периода запишет в ARR и RCR данные для следующего. А потом по прерыванию от DMA готовить данные в буфере для следующих периодов.

Только DMA должно писать в регистры таймера не напрямую, а используя регистры TIMx->DCR и TIMx->DMAR.

 

Спасибо! Именно это я и хотел услышать - менять параметры таймера не в обработчике прерывания DMA, а по другому событию и в другом месте. Только немного непонятно - у меня таймер используется под DMA. О каком update event идет речь? Или имеется в виду, что можно использовать прерывания от этого же таймера? Так не получится, так как мне надо не каждое событие таймера использовать, а каждое 68.

10 minutes ago, SSerge said:

Есть ещё возможность ускориться заплатив за это размером буферов.

Последовательность 50нс, 500нс, 50нс, 500нс превращается в 22 раза по 50нс, причём перезагрузку ARR и RCR придётся делать только один раз (а не 4), но в буфере первого DMA будет не 4 порции данных, а 22. И шины будут сильно загружены циклами DMA.

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

Edited by Алексей ВМ

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now