[AHTOXA 18]

Вот это открытие так открытие! Кто-ж знал-то???

Я вас чем-то обидел? Что вы всё пытаетесь на меня нападать, уличить в чём-то?

Может быть вас задела фраза "не болтайте ерундой"? Так фраза-то была по делу.

Если вы не в теме, то зачем лезть со своими глупостями? Причём так уверенно, безапелляционно. Вы же так не помогаете топикстартеру, а наоборот, мешаете.

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

Я вам не враг, я здесь с той же целью, что и вы - пытаюсь делиться знаниями, заодно узнаю что-то и сам.

Поэтому давайте общаться спокойно, дружески.

 

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

[jcxz 243]

1. DMA и CPU разделяют общие шины.

И что? USB тоже использует внутреннюю шину (да и прочая периферия), это тоже CPU?

Функционирование DMA (после инициализации) и выполнение команд CPU - совершенно разные и асинхронные вещи.

То что они разделяют общий ресурс к делу не относится.

Откройте reference manual или user manual или как там и найдите что такое Core Cortex-M3/M4 и что такое DMA/GPDMA/uDMA или как там в конкретном МК. Везде одинаково.

 

2. Инициализация DMA тоже занимает ресурс CPU.

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

 

3. Пересылка крошечными блоками не эффективна.

Пересылка малыми блоками в любом случае неэффективна.

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

 

4. DMA транзакция может выполняться с задержкой, считая от момента возникновения запроса (больше 12 тактов).

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

 

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

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

 

Если вы не в теме, то зачем лезть со своими глупостями? Причём так уверенно, безапелляционно. Вы же так не помогаете топикстартеру, а наоборот, мешаете.

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

Вы сейчас говорите о себе? Где это я обижался?

У Вас ни в одном сообщении ни капли полезной информации. Вам по делу нечего сказать.

И не пытался я Вас оскорбить, просто написал, что несёте полную чушь.

[adnega 11]

До сих пор не ясно нужно ли обрабатывать пришедшие данные тут же?

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

[TigerSHARC 0]

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

[AHTOXA 18]

Вы сейчас говорите о себе?

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

[Golikov 0]

АНТОХА вы иногда резковаты, иногда не по делу.

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

 

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

 

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

 

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

 

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

 

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

[adnega 11]

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

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

[jcxz 243]

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

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

И решил как раз так как описал в первом сообщении. Всё прекрасно работало и это при том, что проц в это время занимался

другими (более тяжёлыми) делами.

 

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

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

 

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

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

всему остальному коду (где могут быть критические секции с запретом прерывания или другие высокоприоритетные прерывания.

Я для себя всегда беру за правило: стараться строить работу системы прерываний так, чтобы она была устойчива к запретам прерывания до

неск. десятков мкс (по возможности конечно).

 

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