Jump to content

    

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

8 часов назад, SSerge сказал:

Ждать будет ровно один такт, нагло вклиниваясь между циклами процессора.

Это где такое написано? Можете указать источник?

Обычно у DMA приоритет доступа к шине ниже чем у CPU.

8 часов назад, SSerge сказал:

В пределе DMA способно отбирать у процессора каждый второй цикл шины.

Опять-же - источник?

Share this post


Link to post
Share on other sites

Здесь так пишут https://www.st.com/content/ccc/resource/technical/document/application_note/47/41/32/e8/6f/42/43/bd/CD00160362.pdf/files/CD00160362.pdf/jcr:content/translations/en.CD00160362.pdf

When the CPU initiates a data transfer meanwhile the DMA is transferring a block of data from a source to a destination, the round-robin AHB bus matrix halts the DMA bus access and inserts the CPU access, causing the DMA transfer to have a longer latency.

Share this post


Link to post
Share on other sites
3 часа назад, mcheb сказал:

А какое отношение сей документ имеет к теме топика? В топике указано: STM32F4.

А для STM32F4 есть соответствующий документ: https://www.st.com/content/ccc/resource/technical/document/application_note/27/46/7c/ea/2d/91/40/a9/DM00046011.pdf/files/DM00046011.pdf/jcr:content/translations/en.DM00046011.pdf

в котором в п.2.1.3 явно указано:

If bus access is first granted to the CPU and the CPU is not performing a single data 
load/store, the DMA wait time to gain access to SRAM can expand from one AHB cycle for 
a single data load/store to N AHB cycles, where N is the number of data words in the CPU 
transaction.
The CPU locks the AHB bus to keep ownership and reduces latency during multiple 
load/store operations and interrupts entry. This enhances firmware responsiveness but it 
can result in delays on the DMA transaction.
Delay on DMA1 SRAM access when in concurrency with CPU depends on the type of 
transfer:
• CPU transfer issued by interrupt (context save): 8 AHB cycles
• CPU transfer issued by cache controller (256-bit cache line fill/eviction): 8 AHB 
cycles(a) 
• CPU transfer issued by LDM/STM instructions: 14 AHB cycles(b)
– Transfers of up to 14 registers from/to memory

Итого: LDM/STM команды могут достигать длительности 14 тактов + пару тактов на арбитраж - вот такая будет задержка для DMA.

А сколько тактов задержки потребуется при команде VSTMDB Rx!, {S0-S31} о которой я писал раньше - сами догадайтесь  :wink:

Хотя уже даже просто пересылка контекста при входе/выходе в ISR вылетит за пределы 50нс...

 

Share this post


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

Ждать будет ровно один такт, нагло вклиниваясь между циклами процессора.

В пределе DMA способно отбирать у процессора каждый второй цикл шины.

Как видно - это не так.

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

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

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

Share this post


Link to post
Share on other sites
2 часа назад, jcxz сказал:

Как видно - это не так.

Спасибо. Не ожидал такого, и в реф мануале ни слова.

Самое интересное, что раньше у меня тоже была задача с пересылками по DMA, но не с такими жесткими требованиями по времени. Видимо просто повезло что команд LDM/STM не было, а то бы заметил.

Share this post


Link to post
Share on other sites

Реализовал выдачу данных по событию capture/compare event.  Прерывание ТС записи DMA по update event  возникает только один раз, прерывание ТС записи DMA по capture/compare event генерируются нормально.

Регистры CCR1 = 0, ARR и RCR содержат правильные значения. Как я понимаю update event возникает только один раз. В чем может быть причина?

 

Edited by Алексей ВМ

Share this post


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

Самое интересное, что раньше у меня тоже была задача с пересылками по DMA, но не с такими жесткими требованиями по времени. Видимо просто повезло что команд LDM/STM не было, а то бы заметил.

Это странно. Особенно если учесть что PUSH/POP - это как раз и есть частный случай STM/LDM. Да и при каждом прерывании - 8 слов контекста - как с куста.

Может просто везло и такие процедуры с большим кол-вом (регистров в POSH/POP) не попадали никогда на работу DMA? Если эти процессы циклические и зависимые друг от друга - такое возможно. Ну или в компиляторе стояла опция, ограничивающая количество регистров в PUSH/POP? Или стеки находились в другом регионе ОЗУ, не пересекающемся с DMA?

Share this post


Link to post
Share on other sites
В 30.08.2019 в 20:22, Алексей ВМ сказал:

Реализовал выдачу данных по событию capture/compare event.  Прерывание ТС записи DMA по update event  возникает только один раз, прерывание ТС записи DMA по capture/compare event генерируются нормально.

Регистры CCR1 = 0, ARR и RCR содержат правильные значения. Как я понимаю update event возникает только один раз. В чем может быть причина?

 

 

Не понял. А сколько должно быть?

Если в RCR загружено N-1, то update event возникает один раз на каждые N*(ARR+1) тиков таймера.

Может быть оно так и должно быть?

Ещё один момент: количество пересылок по DMA, которые будут сделаны на каждый update event.

Это устанавливается в поле DBL регистра TIMx->DCR.

 

Share this post


Link to post
Share on other sites
On 9/1/2019 at 1:42 PM, SSerge said:

Не понял. А сколько должно быть? 

Если в RCR загружено N-1, то update event возникает один раз на каждые N*(ARR+1) тиков таймера.

Может быть оно так и должно быть?

 

Вообще один раз, больше не возникает, запись в регистры ARR и RCR (через DMAR) перед этим прерыванием производится правильно. СС1 шлепают нормально, данные выводятся, UIF выставляется, но записи в регистры ARR и RCR не производится, прерывания от выполнения этой записи не возникает.

Edited by Алексей ВМ

Share this post


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

Вообще один раз, больше не возникает, запись в регистры ARR и RCR (через DMAR) перед этим прерыванием производится правильно. СС1 шлепают нормально, данные выводятся, UIF выставляется, но записи в регистры ARR и RCR не производится, прерывания от выполнения этой записи не возникает.

 

У меня так было когда в обработчике прерывания от DMA забывал сбросить запрос в регистрах DMA->LIFCR или DMA->HIFCR.

Share this post


Link to post
Share on other sites
18 minutes ago, SSerge said:

У меня так было когда в обработчике прерывания от DMA забывал сбросить запрос в регистрах DMA->LIFCR или DMA->HIFCR.

TCIF сбрасываю. Если не сбрасывать, будет заходить в обработчик снова и снова по первой записи. Другие флаги не выставляются, то есть ошибок записи тоже нет.

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