[jcxz 235]

22 минуты назад, C2000 сказал:

Как может возникнуть 12 тактов, прошу объяснить с ссылкой на документацию. Это не придирки, просто хочется понять ход Вашей мысли.

Первая: Читайте описание Cortex-M и в частности - процедур stacking-а и unstacking-а.

Вторая (из мануала на STM32F091, описание модуля CRC):

Уже только из этого можно сделать вывод что если CPU выполняет запись в регистр данных CRC и в этот момент он получает сигнал прерывания, то: 4 + 12 тактов занятости шины обеспечена (CPU как правило имеет бОльший приоритет доступа к шине чем DMA). А в реальности - ещё немного больше из-за арбитража и пр.

Цитата

Ну и по поводу дребезга если он "ничтожен" по сравнению с частотой сигнала то можно считать что его нет.

Ну да: У ТС-а частота шины SYSCLK = 16МГц, тут возникает задержка в ~16 тактов (а скорее даже больше) - это всего какая 1 мкс - ерунда!  

15 минут назад, AlexandrY сказал:

А то что в SoC-ах есть отдельные шины для DMA ни о чем не говорит? 

STM32F091 - SoC? Причём тут они? Или Вы опять пытаетесь встрять с рекламой какого-то чудо-чипа? Который ещё и программируется совсем без си  

15 минут назад, C2000 сказал:

Ну расскажите и дайте ссылку на документацию, из которой было бы что то понятно

В гугле забанили? Гугл на запрос "Cortex-M stacking procedure" или "Cortex-M Exception Handling" выдаёт много полезного.

Также есть: https://developer.arm.com

[C2000 3]

7 minutes ago, jcxz said:

Вторая (из мануала на STM32F091, описание модуля CRC):

 

Это означает что на это время блокируется работа DMA? 

[jcxz 235]

3 минуты назад, C2000 сказал:

Это означает что на это время блокируется работа DMA? 

Блокируется шина.

[C2000 3]

Just now, jcxz said:

Блокируется шина.

Это точно, Вы проверяли? Вроде бы написано что вычисляется за 4 такта, о блокировке ничего не сказано.

[jcxz 235]

19 минут назад, C2000 сказал:

Это точно, Вы проверяли? Вроде бы написано что вычисляется за 4 такта, о блокировке ничего не сказано.

В мануале на этот МК не сказано, но в мануале на STM32F4 сказано:

И я сомневаюсь, что в более слабой архитектуре дела обстоят лучше. Скорее будет хуже.

 

Да и не CRC наиболее страшен. А что будет например если CPU завершает выполнение текущего ISR (выполняет unstaking), и только он это закончил - ему приходит новое прерывание и он выполняет stacking. А DMA-запрос приходит в момент начала unstaking-а. А ведь для полной отработаки DMA-запроса нужно сделать две операции: чтение памяти + запись в периферию. Т.е. - два цикла обращения к шине. А CPU - в приоритете. 

А если в это время ещё как раз работал другой DMA-канал. А может он даже гнал данные в CRC! 

[C2000 3]

19 minutes ago, jcxz said:

... А ведь для полной отработаки DMA-запроса нужно сделать две операции: чтение памяти + запись в периферию. Т.е. - два цикла обращения к шине. А CPU - в приоритете. 

Опять голословное утверждение.

Выдержка из документации STM32F03:

The BusMatrix manages the access arbitration between the core system bus and the DMA master bus. The arbitration uses a Round Robin algorithm

 

25 minutes ago, jcxz said:

...А что будет например если CPU завершает выполнение текущего ISR (выполняет unstaking)...

Вы хотите сказать что сохранение контекста при входе в прерывание атомарная операция? Аргументируйте!

[jcxz 235]

7 минут назад, C2000 сказал:

Опять голословное утверждение.

Выдержка из документации STM32F03:

The BusMatrix manages the access arbitration between the core system bus and the DMA master bus. The arbitration uses a Round Robin algorithm

И что? К чему это?

 

PS: Не понимаю - с чем спорите.   Так всё-таки - есть джиттер или нет? Ведь именно с этого начался весь сыр-бор - с моего утверждения, что "строгого тайминга" на связке таймер-DMA-GPIO никак не добиться. С чем Вы не согласились. 

Считаете, что DMA мгновенно телепортирует данные из приёмника в источник мимо всех шин и прочих мешающих сущностей? 

[C2000 3]

30 minutes ago, jcxz said:

В мануале на этот МК не сказано, но в мануале на STM32F4 сказано:

Так это про запись следующих данных для расчёта CRC

Причем тут шина и DMA

3 minutes ago, jcxz said:

И что? К чему это?

К тому что у CPU нет никакого приоритета перед DMA

И изначально речь о существенном или нет влиянии джиттера на передачу данных через DMA

А так он конечно есть причем всегда и везде, речь лишь о том в какой степени он мешает (или нет) работе.

Все в этом мире оценивается относительно и нет ничего идеального

И хочется все же разъяснить что там с этим  стекинг-анстекинг что в нем такого ужасного и страшного? честно слово интересно.

[jcxz 235]

4 минуты назад, C2000 сказал:

Так это про запись следующих данных для расчёта CRC

Причем тут шина и DMA

Это про то, что запись будет длиться столько, сколько будет продолжаться это stalled. А шина при том, что она будет в это время оставаться занятой.

4 минуты назад, C2000 сказал:

К тому что у CPU нет никакого приоритета перед DMA

Во-первых: фраза про "round robin" - вообще никак не говорит о приоритетах. Где явное указание на приоритет? Round robin может выполняться с учётом приоритета некоторых участников.

Во-вторых: нигде не указано, что арбитраж будет выполняться на каждом такте шины. Почему не предположить, что "round robin" будет выполняться каждый N-й такт? есть конкретная ссылка?

В-третьих: Смотрите внимательнее на указанный случай: Имеем случай - выход из ISR и сразу вход. Ранее (до всего этого) DMA выиграл "round robin" и теперь приоритет у CPU, но в начале unstacking-а не было ещё DMA-запроса (он появился на такт позднее), поэтому розыгрыш арбитража не проводился (и всё осталось по-старому), в при процедуре stacking-а выиграл CPU, так как у него приоритет.

[C2000 3]

Ладно, спор бессмыслен без реализации в железе. Можно тут долго друг другу что то доказывать, но только топик стартеру похоже это вообще не нужно 

[jcxz 235]

7 минут назад, C2000 сказал:

Ладно, спор бессмыслен без реализации в железе. Можно тут долго друг другу что то доказывать, но только топик стартеру похоже это вообще не нужно 

Спор быссмысленен уже потому, что Вы не имели реального опыта работы с Cortex-M.

А вот я уже неоднократно сталкивался с тем, что DMA-запросы не обрабатываются мгновенно. Как и другие участники здесь. О чём и писал.

[C2000 3]

4 minutes ago, jcxz said:

Спор быссмысленен уже потому, что Вы не имели реального опыта работы с Cortex-M.

И снова голословное утверждение

Это кстати тоже хороший повод прекратить дискуссию.

Зачем спорить с человеком который руководствуется своим воображением а не фактами.

[Plain 199]

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

От WS2812B думаю уже давно все отказались.
Теперь на APA102 c SPI подобным интерфейсом все делают. Они  гораздо более надежные и цветопередача лучше. 
У меня с ними работает по DMA на 10 МГц

 

Этим APA102 уже столько лет, а от WS2812 до сих пор не отказываются. К тому же, из SPI совсем несложно сделать нужный сигнал:

 

 

Триггер SN74LVC1G175, диодная сборка BAT54A, BAS40-06 и т.п.

[Eddy_Em 1]

2 hours ago, jcxz said:

И что будет делать DMA-контроллер?

Вот никогда не задумывался... У меня всегда есть активные DMA: отсылка данных по USART, измерение нескольких каналов АЦП, работа с SPI и т.п.

И ни разу не замечал проблем. Внешне кажется, что все каналы DMA одновременно работают и друг другу не мешают! Главное - не сажать разную нагрузку на один канал, тогда действительно фигня будет: сможет работать лишь кто-то один.

А если есть два DMA, да еще и по куче каналов на каждом, то это просто шикарно!

[jcxz 235]

6 минут назад, Eddy_Em сказал:

Вот никогда не задумывался... У меня всегда есть активные DMA: отсылка данных по USART, измерение нескольких каналов АЦП, работа с SPI и т.п.

А теперь попробуйте вывести сигнал на GPIO. И посмотреть на его джиттер. 

8 минут назад, Eddy_Em сказал:

И ни разу не замечал проблем.

Потому что у всех перечисленных есть FIFO. Того или иного размера. Потому и работает.