[jcxz 184]

20 минут назад, Алексей ВМ сказал:

Нет, минимальный период таймера 50 нс, период клока на пине - 100 нс - это 10 МГц. STM32F4 вполне справляется. Затык с переинициализацией таймера на ходу.

Ну да, ну да.... 

Задумайтесь немного: Вот пришло время DMA что-то отправить в GPIO чтобы изменить состояние пинов, а в этот момент CPU решил сохранить контекст FPU на стек, и стек оказался в той же памяти, из которой DMA выполняет пересылку в GPIO. Вопрос: сколько тактов будет ждать DMA освобождения шины при условии того что размер контекста FPU == 16 слов? А если сразу все 33 слова сохраняются? А если ещё целочисленный контекст туда-же - до кучи сохраняется? 

[Forger 17]

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

Платы уже вовсю клепают...

Текущую сборку останавливать, а на что успели спаять сделайте вторую плату и клейте ее сверху основной. Это нормально. Делать срочно новые правильные платы.

Это в итоге гораздо дешевле, чем потом переделывать и возвращать груду уже готовых изделий и платить неустойку заказчику.

 

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

12 minutes ago, jcxz said:

Ну да, ну да.... 

Задумайтесь немного: Вот пришло время DMA что-то отправить в GPIO чтобы изменить состояние пинов, а в этот момент CPU решил сохранить контекст FPU на стек, и стек оказался в той же памяти, из которой DMA выполняет пересылку в GPIO. Вопрос: сколько тактов будет ждать DMA освобождения шины при условии того что размер контекста FPU == 16 слов? А если сразу все 33 слова сохраняются? А если ещё целочисленный контекст туда-же - до кучи сохраняется? 

Перерыв в несколько десятков или даже сотен мкс не критичен, главное, чтобы он был не чаще одного раза в неск сотен мс. Потери данных, я понимаю, не произойдет?

 

8 minutes ago, Forger said:

Текущую сборку останавливать, а на что успели спаять сделайте вторую плату и клейте ее сверху основной. Это нормально. Делать срочно новые правильные платы.

Это в итоге гораздо дешевле, чем потом переделывать и возвращать груду уже готовых изделий и платить неустойку заказчику.

  

Не вариант, заказчик за каждый цент удавится

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

[jcxz 184]

6 минут назад, Алексей ВМ сказал:

Точность +- 10 нс для наименьшего периода 50 нс, меньше не нужна. По сути, это параллельная шина с 10 сигналами, один из которых клок.

А частота CPU какая? 180МГц? Если проц например решит выполнить команду VSTMDB Rx!, {S0-S31} то это убьёт вашу систему. Так как выполнять он её будет ~183нс заняв шину. И у него (проца) есть ещё много подобных чудесных команд.  

Можно попробовать вынести DMA-буфер в отдельный регион памяти, для которого в матрице шин есть свой канал, не пересекающийся с другими. Но не знаю - поможет ли....

6 минут назад, Алексей ВМ сказал:

ШИМ, к сожалению, здесь не прокатит...

Прокатит. Если МК выбирать соответствующий задаче. У XMC4700 например 32 отдельных таймера с ШИМ-ами, которые могут работать синхронно, генеря сигналы с точностью до 1 клока своей тактовой частоты (144МГц). И без всяких завязок на работу шины.

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

3 minutes ago, jcxz said:

Прокатит. Если МК выбирать соответствующий задаче. У XMC4700 например 32 отдельных таймера с ШИМ-ами, которые могут работать синхронно, генеря сигналы с точностью до 1 клока своей тактовой частоты (144МГц). И без всяких завязок на работу шины. 

Частота  168 МГц .

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

 

[jcxz 184]

2 минуты назад, Алексей ВМ сказал:

Перерыв в несколько десятков или даже сотен мкс не критичен, главное, чтобы он был не чаще одного раза в неск сотен мс.

Хммм.... странное условие.... Если так, то может ещё не всё потеряно. Вынести в отдельный регион памяти DMA-буфер, добиться от компилятора отсутствия длинных команд сохранения/восстановления в/из памяти в циклическом коде (чтобы не было постоянных циклических попаданий работ DMA на эти команды). Может и будет работать.....

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

3 minutes ago, jcxz said:

Хммм.... странное условие.... Если так, то может ещё не всё потеряно. Вынести в отдельный регион памяти DMA-буфер, добиться от компилятора отсутствия длинных команд сохранения/восстановления в/из памяти в циклическом коде (чтобы не было постоянных циклических попаданий работ DMA на эти команды). Может и будет работать.....

Уже работает. Но заказчик решил изменить возможности, отсюда все эти пляски с бубном...

[jcxz 184]

8 минут назад, Алексей ВМ сказал:

Частота  168 МГц .

Учтите, что даже простое сохранение контекста на входе в ISR (и восстановление на выходе из него) займёт: 1/0.168*8 = 47.6 нс. Если это попадёт на время пересылки DMA по шине, то будет соответствующая задержка. FPU на вашем месте в этом проекте я вообще бы не использовал (компилил код для Cortex-M3).

 

PS: Ещё можно вообще класть CPU в сон на время работы DMA. Чтоб не мешал.

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

6 minutes ago, jcxz said:

Учтите, что даже простое сохранение контекста на входе в ISR (и восстановление на выходе из него) займёт: 1/0.168*8 = 47.6 нс. Если это попадёт на время пересылки DMA по шине, то будет соответствующая задержка. FPU на вашем месте в этом проекте я вообще бы не использовал (компилил код для Cortex-M3).

Если удастся менять период таймера аппаратно, то задержки до единиц мкс до входа в обработчик прерывания ни на что не влияют. За FPU благодарю, постараюсь избавиться от него.

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

[jcxz 184]

2 минуты назад, Алексей ВМ сказал:

Если удастся менять период таймера аппаратно, то задержки до 100 нс до входа в обработчик прерывания ни на что не влияют. За FPU благодарю, постараюсь избавиться от него.

Cortex-M можно заставить работать в таком режиме, чтобы сразу после выхода из ISR CPU сразу уходил в сон. И просыпался только при входе в другое прерывание. Тогда он не будет мешать работе DMA. Всю работу будет делать только в ISR-ах.

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

9 minutes ago, jcxz said:

Cortex-M можно заставить работать в таком режиме, чтобы сразу после выхода из ISR CPU сразу уходил в сон. И просыпался только при входе в другое прерывание. Тогда он не будет мешать работе DMA. Всю работу будет делать только в ISR-ах.

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

 

 

 

Немного не ясно с RCR:

 

Each time the REP_CNT related downcounter reaches zero, an update event is generated

 

Это какой-то особый update event, или он заведен на TIM1_UP?

 

Дальше по тексту упоминается repetition update event U_RC:

As REP_CNT is reloaded with REP value only at
the repetition update event U_RC, any write to the TIMx_RCR register is not taken in
account until the next repetition update event.

 

но кроме этого отрывка нигде не находится поиском.

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

[dimka76 42]

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

Немного не ясно с RCR:

 

Есть картинка поясняющая работу RCR

[SSerge 4]

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

Ну да, ну да.... 

Задумайтесь немного: Вот пришло время DMA что-то отправить в GPIO чтобы изменить состояние пинов, а в этот момент CPU решил сохранить контекст FPU на стек, и стек оказался в той же памяти, из которой DMA выполняет пересылку в GPIO. Вопрос: сколько тактов будет ждать DMA освобождения шины при условии того что размер контекста FPU == 16 слов? А если сразу все 33 слова сохраняются? А если ещё целочисленный контекст туда-же - до кучи сохраняется? 

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

Цитата

The BusMatrix manages the access arbitration between masters. The arbitration uses a
round-robin algorithm.

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

Более того, DMA в режиме память->периферия может делать предварительное чтение данных из памяти и сохранять у себя. Тогда при поступлении запроса на DMA остаётся только провести цикл записи в периферийное устройство.

Вот только чтобы всё это правильно запрограммировать придётся добрую половину реф. мануала прочитать.

[Forger 17]

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

Не вариант, заказчик за каждый цент удавится

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

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

Quote

A general purpose or an advanced timer (that's all of them except TIM6 and TIM7) can trigger a DMA transfer when the counter reaches the reload value (update event) and when the counter equals any of the compare values (capture/compare event).

Немного модифицированное предложение ув. SSerge

 

8 hours ago, SSerge said:

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

 

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

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

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

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

 

Пины дергать не по update event, а по capture/compare event. Соответственно, update event возникает при окончании передачи всего пакета (68 импульсов), по нему производится DMA запись регистра ARR новым значение периода.

Два обработчика прерываний -  один старый для формирования буфера передачи, новый для изменения периода таймера.

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