А там таймер не может запускать DMA по capture?

Может, но нужно DMA пнуть 16 раз.

почему 16 раз?
нельзя сказать чтобы ДМА забрало 16 байт по готовности каждого?

Канал таймера выставляет запрос на DMA. По этому запросу DMA совершает одну транзакцию.

Если настроить DMA на готовность источника данных, то как только источник (в данном случае SPI_TX) будет готов, тут же полетят транзакции, и таймером их не запустить не остановить. Единственный вариант - натравить DMA транзакцию от таймера на запись управляющего слова в CR-регистр другого DMA для старта его от SPI_TX.

тема распалась на два вопроса:

1) можно ли решить задачу используя два DMA и один таймер?
2) не понятно как именно осуществляется транзакция нескольких байт последовательно в SPI_TX через DMA. Я понимаю так: как только DMA получает сигнал о готовности данных (от таймера или от флага, установленного в обработчике прерывания GPIO) то, в соответствии с настройками, DMA отправляет последовательно 16-байт в SPI_TX. Не понятно как именно DMA узнает что байт улетел наружу и можно кидать следующий байт в SPI_TX. если ниак, то получается что DMA тупо перезапишет регистр 16-раз.

В LPC ДМА следит как за флагом готовности данных если оно читает их, так и за флагом готовности передатчика если передает.
Задаете куда и сколько байт заслать, запускаете процесс, наслаждаитесь.

Не думаю что в STM настолько тупо сделано, что ДМА будет просто тупой писалкой из адреса в адрес. Наверняка там можно выбрать что будет приемником адрес или периферия, а если так, то оно должно само справиться с этой задаче.

Потому с вероятностью 90% (или я буду еще хуже думать об СТМ) задача решается запуском ДМА записи и чтения, я бы запускал по прерыванию, но можно ножкой запустить таймер, а от таймера запустить ДМА, но какая то это долбанная матрешка....

Можно с использованием EXTI. Т.е. прерывание по каждому сигналу готовности.


О готовности данных он узнает по запросам на DMA-транзакцию. Например, SPI_TX. Не от таймера или флага GPIO, а именно от SPI_TX.
Однако, ничто не мешает копировать в SPI_DR по запросам от таймера или GPIO, но в этом случае программист должен гарантировать, что не будет перезаписи, а ранее записанные данные уже обработаны.

Вопрос в том, как заставить таймер сказать DMA, что можно начинать передавать данные в SPI_DR по запросам от SPI_TX?

запрос на транзакцию от SPI_TX для DMA может быть только по готовности данных в SPI_TX. Т.е. появился байт в SPI_TX - возникает событие для DMA.
У меня два DMA: один передает "тупые" данные, другой принимает валидные. Так вот первый должен как-то узнать о том что отправлять надо не сразу 16 байт один за другим, а только когда один отправился - -отправлять другой, при этом запрос на транзакцию он принимает от флага GPIO(или таймера). Вы предлагаете третий DMA завести, который будет принимать запрос от SPI_TX? но как это поможет первому DMA узнать когда нужно отправить слудующий байт из 16ти...

не понимаю логику...

P.S. или существует механизм(наличие флага?), позволяющий определить что SPI_TX пуст?

Допустим мы используем SPI1.
SPI1_TX можно найти на канале 3 в DMA2_Stream3, SPI1_RX можно найти на канале 3 в DMA2_Stream2.
Настраиваем DMA2_Stream3 на копирование данных из памяти, в которой лежит 0xFF, в SPI1->DR. Длина 16 транзакций.
Настраиваем DMA2_Stream2 на копирование данных из SPI1->DR в буфер приема. Длина 16 транзакций.
Устанавливаем в SPI1 TXDMAEN и RXDMAEN. В SPI будет отправлено 16 раз 0xFF и принято 16 байт в буфер приема.

Весьма доходчиво. Спасибо.

Я б добавил, что DMA для SPI1_TX нужно настроить без инкремента, а SPI1_RX, наоборот, с автоинкрементом памяти.

Ну, не преувеличивайте Основной-то обмен всё же будет по DMA.
Насчёт расхода процессорного времени я бы не был так уверен. DMA тоже выполняется процессором. И, боюсь, что 2(или даже 3 - ещё возможно надо будет записывать TXDMAEN в SPI_CR2) дополнительных канала DMA могут нагрузить процессор больше, чем ма-а-аленькая процедурка прерывания с тремя командами внутри.
Ещё одно соображение: каналов DMA не так уж много, и это может быть более ценный ресурс, чем процессорное время.

Полностью согласен.

Если нужно реагировать на каждый принимаемый пакет, то прерывание EXTI + DMA x 2.
Если можно на каждый принимаемый пакет не обращать внимания, а обрабатывать сразу сотню принятых пакетов, то TIMER + DMA x 4.

Вот это открытие так открытие! Кто-ж знал-то???
Я-то по скудости ума всегда думал, что DMA - это такой периферийный узел, главное назначение которого - разгрузить CPU от тупого перетаскивания байтов по шине. А значит - это совершенно разные узлы.
Ан нет, он оказывается тоже какая-то часть CPU... левая задняя нога наверное..


Маленькая процедурка с сохранением контекста на входе и выходе в ISR, десятком команд, с выборкой их из памяти (заполнение как минимум 2-3 prefetch-буферов по 128/256бит каждый),
+несколько обращений по шине для чтения/записи данных, и опять заполнение prefetch-буферов командами после возврата из ISR.
И Вы утверждаете, что это быстрее чем заранее настроенному каналу DMA активироваться и сделать 2-3 пересылки по шине для записи управляющих регистров таймера или другого канала DMA
для запуска пакета из 16 операций обмена с SPI???
Ню-ню....


Это уже разработчику решать - что ему важнее: потратить несколько DMA-каналов или по всему коду программы вводить жёсткие ограничения на длительность запретов прерываний,
понижать приоритеты других ISR (в которых тоже время реакции может оказаться критичным).
Если речь идёт о периоде событий порядка 10 мкс (и это только период стартовых импульсов, а время реакции на них значит ещё в разы меньше), то требования к времени реакции на прерывание
(если делать по прерыванию) весьма жёсткие. При таких требованиях имхо надо всё делать максимально без-процессорно, всё свалив на DMA.
Для того он и нужен.
А более медленную периферию можно и программно обслужить, если каналов DMA не хватит.

PS: Кстати - ТС указал период стартовых событий (10мкс), но забыл указать более важное - максимальное время реакции на стартовый импульс. Оно будет зависеть ещё от частоты SPI и необходимого
запаса времени между последней SPI-пересылкой и новым импульсом.

Я бы предостерег от категоричных высказываний)

1. DMA и CPU разделяют общие шины.
2. Инициализация DMA тоже занимает ресурс CPU.
3. Пересылка крошечными блоками не эффективна.
4. DMA транзакция может выполняться с задержкой, считая от момента возникновения запроса (больше 12 тактов).

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