Я вас чем-то обидел? Что вы всё пытаетесь на меня нападать, уличить в чём-то?
Может быть вас задела фраза "не болтайте ерундой"? Так фраза-то была по делу.
Если вы не в теме, то зачем лезть со своими глупостями? Причём так уверенно, безапелляционно. Вы же так не помогаете топикстартеру, а наоборот, мешаете.
Вот и сейчас: вы, похоже, нервничали, и опять понаписали кучу глупостей. Не надо так всё близко к сердцу принимать, это же всего лишь буковки в интернете.
Я вам не враг, я здесь с той же целью, что и вы - пытаюсь делиться знаниями, заодно узнаю что-то и сам.
Поэтому давайте общаться спокойно, дружески.

По теме: попробуйте загрузить процессор непрерывной DMA-пересылкой и прогоните какой-нибудь бенчмарк. Потом сравните результаты с результатами этого же бенчмарка, но без DMA.

И что? USB тоже использует внутреннюю шину (да и прочая периферия), это тоже CPU?
Функционирование DMA (после инициализации) и выполнение команд CPU - совершенно разные и асинхронные вещи.
То что они разделяют общий ресурс к делу не относится.
Откройте reference manual или user manual или как там и найдите что такое Core Cortex-M3/M4 и что такое DMA/GPDMA/uDMA или как там в конкретном МК. Везде одинаково.


В задаче ТС этот этап делается один раз - при старте ПО (если делать как хочет ТС). Так что - тоже к делу не относится.


Пересылка малыми блоками в любом случае неэффективна.
Дёрганье в ISR и такая пересылка CPU - ещё менее эффективны чем заранее настроенный DMA в режимах flip-flop, связные списки и т.п.


Как ни странно - вход в ISR тоже выполняется с задержкой + ещё и шину грузит.


Это можно сказать о любом методе пересылки любым bus master-ом. Это общее свойство.


Вы сейчас говорите о себе? Где это я обижался?
У Вас ни в одном сообщении ни капли полезной информации. Вам по делу нечего сказать.
И не пытался я Вас оскорбить, просто написал, что несёте полную чушь.

До сих пор не ясно нужно ли обрабатывать пришедшие данные тут же?
Или их нужно буферизировать, а потом обрабатывать группой?

В моей задаче нужно записывать данные в буфер. В моей задаче глубина буфера 16кБ. т.е. данные подлежат обработке после прихода каждой 1000-й транзакции по 16 байт.

Нет, я говорю о вас. Ведь это именно вы, в первом же вашем сообщении в этой теме жидко обделались, показав, что совершенно не разбираетесь в STM32 вообще и его DMA в частности. И после того, как я вам на это указал, вы, вместо того, чтобы сидеть и тихо обсыхать, всё пыжитесь и пыжитесь что-то доказать. Получается, если честно, так себе. Зря вы полезли в тему, в которой не разбираетесь.

АНТОХА вы иногда резковаты, иногда не по делу.
jcxz вы тоже иногда слишком уж напористо заявляете некоторые вещи, которые имеют не одно решение.

Но вы оба судя по другим вашим сообщениям не плохие профессионалы, и я думаю стоит вам прекратить пикироваться.

ДМА действительно грузит шину. А загрузка шины тормозит проц, если она ему нужна и занята он притормаживает. Потому и есть арбитраж шины и приоритеты.

Но с другой стороны 2 обмена по ДМА, в которых идет быстрая запись слова и пауза на его последовательную отправку вряд ли парализуют проц. Также думаю запуск начала обмена в прерывании 1 раз на 16 байт, опять же никакой особой погоды не сделает. Не думаю что пока идет сбор данных проц проигрывает веселые мелодии и кино показывает. Опять же сделать так чтобы проц собирал данные вообще в фоне, тоже красиво. Но надо еще контролировать и когда набрали 1000 посылок, то есть все равно надо прерываться и считать.

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

Думаю следующий ход должен сделать ТС, сказав нам работает ли ДМА заряженный на отправку 16 байт через SPI как мы все ждем, отправляя байт за байтом или же попихает все сразу и надо что-то мутить. Принимающий ДМА я бы сразу настраивал на прием 16*1000 байт и сразу в общий массив, с прерыванием по сбору всех байт. А порционость данных рулил бы первым ДМА заряжая его на 16 байт, каждый импульс.

Тогда сообщение №13 с N=1024.

Очень похожую задачу (тоже по приходу импульса надо было считать пачку байт с ПЛИС) я решал. Только на LPC176x.
И решил как раз так как описал в первом сообщении. Всё прекрасно работало и это при том, что проц в это время занимался
другими (более тяжёлыми) делами.


Я уже прекратил. Кнопка - "поместить в игнор" очень полезна


Как я писал - дело не в том насколько это загрузит CPU, а в том что требование реакции на прерывание в 1-2 мкс, сильно ужесточит требования ко
всему остальному коду (где могут быть критические секции с запретом прерывания или другие высокоприоритетные прерывания.
Я для себя всегда беру за правило: стараться строить работу системы прерываний так, чтобы она была устойчива к запретам прерывания до
неск. десятков мкс (по возможности конечно).

К тому-же ТС у нас - из мира DSP, тогда он тем более должен понимать чем вредны высокочастотные прерывания (на DSP с несколькими десятками регистров и конвееризацией вычислений).