Перейти к содержанию
    

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

Добрый день.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Изменено пользователем Алексей ВМ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 minutes ago, Алексей ВМ said:

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, Forger said:

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, Алексей ВМ said:

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Cycles with zero wait state memory

 

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

Cortex-M4

12

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 часов назад, Forger сказал:

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

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

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

32 минуты назад, jcxz сказал:

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

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Время между прерываниями - 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 нс, от и менять ничего не надо. Пусть себе шлепает с постоянной частотой...

Изменено пользователем Алексей ВМ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...