[Алексей ВМ 0]

8 hours ago, SSerge said:

 

 

Изменено 29 августа, 2019 пользователем Алексей ВМ

[jcxz 182]

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

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

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

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

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

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

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

[mcheb 0]

Здесь так пишут 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.

[jcxz 182]

3 часа назад, mcheb сказал:

Здесь так пишут 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

А какое отношение сей документ имеет к теме топика? В топике указано: 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} о которой я писал раньше - сами догадайтесь  

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

 

[jcxz 182]

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

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

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

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

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

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

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

[SSerge 4]

2 часа назад, jcxz сказал:

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

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

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

[Алексей ВМ 0]

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

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

 

Изменено 30 августа, 2019 пользователем Алексей ВМ

[jcxz 182]

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

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

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

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

[SSerge 4]

В 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.

 

[Алексей ВМ 0]

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 не производится, прерывания от выполнения этой записи не возникает.

Изменено 2 сентября, 2019 пользователем Алексей ВМ

[SSerge 4]

1 час назад, Алексей ВМ сказал:

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

 

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

[Алексей ВМ 0]

18 minutes ago, SSerge said:

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

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

Изменено 2 сентября, 2019 пользователем Алексей ВМ