Алексей ВМ 0 28 августа, 2019 Опубликовано 28 августа, 2019 · Жалоба Добрый день. STM32F4, DMA непрерывно (двойной буфер) по таймеру выдает данные на пины. Периодически надо менять период таймера (минимум - 50 нс, максимум - 500), это делается в обработчике прерывания DMA. Прерывание настроено на окончание передачи буфера. Проблема в том, что когда прога доходит до изменения периода таймера, идет новый цикл выдачи данных, то есть от момента выставления флага ТС до работы обработчика прерывания проходит достаточно большое время - сотни нс. Как уменьшить время от момента выставления флага ТС до входа в обработчик? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 28 августа, 2019 Опубликовано 28 августа, 2019 · Жалоба 1 minute ago, Алексей ВМ said: STM32F4, DMA непрерывно (двойной буфер) по таймеру выдает данные на пины. 1 minute ago, Алексей ВМ said: Как уменьшить время от момента выставления флага ТС до входа в обработчик? Переделать железо, для подобных задач - дергать пинами по DMA, имитируя некую шину или типа того, существуют ПЛИС или другие более аппаратные решения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Алексей ВМ 0 28 августа, 2019 Опубликовано 28 августа, 2019 (изменено) · Жалоба 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 Изменено 28 августа, 2019 пользователем Алексей ВМ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 28 августа, 2019 Опубликовано 28 августа, 2019 · Жалоба 6 minutes ago, Алексей ВМ said: Поздняк метаться, платы уже производятся... Остается строчить на голом asm, вырезая все, что можно. Ну и стек прерываний конечно разместить в CCM памяти. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Алексей ВМ 0 28 августа, 2019 Опубликовано 28 августа, 2019 · Жалоба 2 minutes ago, Forger said: Ну и стек прерываний конечно разместить в CCM памяти. Не подскажете, куда копать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 28 августа, 2019 Опубликовано 28 августа, 2019 · Жалоба Just now, Алексей ВМ said: Не подскажете, куда копать? В даташит и инструкцию к компилятору, как размещать данные в неких секциях )) Все зависит от среды и компилятора. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 28 августа, 2019 Опубликовано 28 августа, 2019 · Жалоба 2 hours ago, Алексей ВМ said: Cycles with zero wait state memory 2 hours ago, Алексей ВМ said: Cortex-M4 12 У вас явно НЕ zero для выбранного STM32F4, а zero при работе из flash на нормальной тактовой уже не поставить (( Как еще вариант - соотв. обработчик прерываний запихивать в ОЗУ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 29 августа, 2019 Опубликовано 29 августа, 2019 · Жалоба А FPU регистры там, случайно, не сохраняются? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 29 августа, 2019 Опубликовано 29 августа, 2019 · Жалоба 5 часов назад, Forger сказал: У вас явно НЕ zero для выбранного STM32F4, а zero при работе из flash на нормальной тактовой уже не поставить (( Поставить. У STM32F4 есть кеш. А при такой частоте входов как у ТС, код ISR почти гарантированно будет в кеше. Тут безальтернативно - ассемблер. И то вряд-ли. Скорее всего - только менять железо. Кроме входа в ISR, есть ещё и выход. Да плюс - занятость шины работающим DMA и пр. Так что за 50 нс на весь ISR - я бы даже не надеялся. Разве что пустой ISR, вообще без команд, уложится. И приоритет этого ISR - надеюсь на максимуме? 35 минут назад, ViKo сказал: А FPU регистры там, случайно, не сохраняются? Думаете ТС в своём ISR-е перепрограммирования DMA использует FPU? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 29 августа, 2019 Опубликовано 29 августа, 2019 · Жалоба Думаю, что прерываний у ТС не одно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 29 августа, 2019 Опубликовано 29 августа, 2019 · Жалоба 7 часов назад, Алексей ВМ сказал: Поздняк метаться, платы уже производятся... Есть пословица про вас: "Семь раз отмерь, один - отрежь". Видимо вы её не знали перед началом проектирования 7 часов назад, Алексей ВМ сказал: Для F4 interrupt latency 12 циклов, это максимум 75 нс. Откуда может набегать доп время? А у вас всё время работы программы состоит только из одних входов в прерывание? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 6 29 августа, 2019 Опубликовано 29 августа, 2019 · Жалоба 32 минуты назад, jcxz сказал: Думаете ТС в своём ISR-е перепрограммирования DMA использует FPU? Он не сообщил что отключил сохранение регистров FPU, следовательно они у него сохраняются. Но это всё не важно. Важно - это смотреть в будущее на один период дальше чем сейчас (и обязательно с оптимизмом!). Регистры таймера ARR и RCR буферизованы и в них можно записать новые значения (для следующего периода) заблаговременно. Загрузка новых значений из буферных регистров в рабочие регистры произойдёт по событию update event. Сразу после update event можно грузить новые данные. Самое правильное это по update event запускать второй канал DMA, который за время текущего периода запишет в ARR и RCR данные для следующего. А потом по прерыванию от DMA готовить данные в буфере для следующих периодов. Только DMA должно писать в регистры таймера не напрямую, а используя регистры TIMx->DCR и TIMx->DMAR. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 29 августа, 2019 Опубликовано 29 августа, 2019 · Жалоба 5 минут назад, SSerge сказал: Он не сообщил что отключил сохранение регистров FPU, следовательно они у него сохраняются. Для того, чтобы они сохранялись, они должны ещё и использоваться. Так что - даже если не отключил, но не использует - то не сохраняются. Хотя можно конечно заставить принудительно сохраняться всегда. Но это надо специально постараться. 5 минут назад, SSerge сказал: Но это всё не важно. Важно - это смотреть в будущее на один период дальше чем сейчас (и обязательно с оптимизмом!). Это важно, так как если всё-таки используется FPU хоть где-то в проекте, то значит и где-то будут сохранения/восстановления. А значит прерывание может попасть на начало этого процесса. И это время прибавится ко времени входа в ISR. 5 минут назад, SSerge сказал: Самое правильное это по update event запускать второй канал DMA, который за время текущего периода запишет в ARR и RCR данные для следующего. А потом по прерыванию от DMA готовить данные в буфере для следующих периодов. Это ничем не поможет если период между двумя прерываниями, как пишет ТС, у него может быть = 50нс. Просто просуммируйте: время_входа_в_ISR + длительность_выполнение_ISR + время_выхода + задержку на прерывание_текущей_фоновой_операции_макс_длительности + макс._длительность_запрета_прерывания_во_всём_коде + задержку_из-за_занятости_шины_работающим_DMA. Тут скорей всего уже ничего не поможет... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 6 29 августа, 2019 Опубликовано 29 августа, 2019 · Жалоба Есть ещё возможность ускориться заплатив за это размером буферов. Последовательность 50нс, 500нс, 50нс, 500нс превращается в 22 раза по 50нс, причём перезагрузку ARR и RCR придётся делать только один раз (а не 4), но в буфере первого DMA будет не 4 порции данных, а 22. И шины будут сильно загружены циклами DMA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Алексей ВМ 0 29 августа, 2019 Опубликовано 29 августа, 2019 (изменено) · Жалоба Прошу прощения, если я неполно описал проблему. Заказчик на ходу изменил требования, приходится изворачиваться... Время между прерываниями - 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 нс, от и менять ничего не надо. Пусть себе шлепает с постоянной частотой... Изменено 29 августа, 2019 пользователем Алексей ВМ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться