Эффективность DMA в SAM7, Выделено из "ARM много,..." Опции

[Proton]

В своё время стоял перед выбором между SAM7 и LPC, решающим стало наличие DMA у SAM7. До этого работал с DSP и уже с трудом представляю как без него(DMA) обходиться.

[Dog Pawlowa]

Направьте на верный путь, товарищи!

Сейчас одновременно осваиваю STM32 Cortex и LPC2478 jn NXP.
Первое семейство намного дружественнее. Библиотеки от производителя.
Конечно, полно глюков в старых ревизиях, но вышли новые кристаллы. Это как у всех
Так что для целей "попробовать" советую STM32.
А в игрушке STM32 primer оболочка от Raisonance для gcc удивительно похожа на IAR.

[zltigo]

Первое семейство намного дружественнее. Библиотеки от производителя.
Конечно, полно глюков в старых ревизиях, но вышли новые кристаллы. Это как у всех

Да нет, не как у всех - c STM32 работаю. Глюков чрезмерно много - в стиле ST (традиция в ряду STR7/9xx)и само ядро V1 с багами, кривыми усеченными "библиотеками" латается отсутствие внятной документации и неполность erratа... Но с точки зрения использования малоногих и шустрых (кому еще и малопотребляющих) чипов альтернатив им нет. Буду использовать, ибо LPC1300 уже не дождусь, а LPC210x не вытянут желаемого. Если и начинать с Cortex-M3, то уже почти доступны LPC1700. Там и ядро V2, и периферия от LPC23xx отлаженная и цену на ..дцать процентов меньше обещают.
А вот LPC24xx действительно вылизанная до блеска серия. Очень порадовала.

Ну да, есть у SAM7 недостатки, как и у других, и во многом он проигрывает более новым LPC,

Во всем

но заявления по поводу полной бесполезности DMA у SAM7, на мой взгляд, чистая религия.

Если быть точным, то я писал:

Оно, конечно, лучше такое DMA, чем совсем ничего, но в большинстве случаев на простеньких ARM7 уровня старых LPC21/22 и нынешних SAM7 банальное FIFO эффективнее работать позволяет.

Вы мне пытаетесь объяснить, что без DMA совсем труба? - согласен. Для помянутого тупого заглатывания по UART 256 байтовых пакетов формально DMA типа меньше ресурсов потребит, нежели 16байтовое FIFO у LPC, только вот что-то я никогда не писал алгоритмов по заглатыванию 256 байт всякой всячины и возможного мусора и последующем ДОЛГОМ в нем копании. Всякие байт ориентированные интерфейсы я лично всегда в потоке по байтам разбираю (FIFO пики сглаживает)- это быстрее, чем постфактум мусор повторно разгребать. Как только у LPC появились пакетные интерфейсы, у LPC появились и ГРАМОТНО огранизованные DMA в дополнение к FIFO. До этого они просто при наличии FIFO бесполезны для простых ARM7 практически всегда.

PDC предназначен для обслуживания медленной периферии, и с этой задачей справляется отлично.

Столь-же отлично, как и FIFO у младших LPC. Посему вопрос "ах как можно жить без DMA" просто не стоит. А при наличии у свежих LPC и того и другого, да и еще архитектурно правильно организованного и вообще не обсуждается

[zhevak]

Для помянутого тупого заглатывания по UART 256 байтовых пакетов формально DMA типа меньше ресурсов потребит, нежели 16байтовое FIFO у LPC, только вот что-то я никогда не писал алгоритмов по заглатыванию 256 байт всякой всячины и возможного мусора и последующем ДОЛГОМ в нем копании. Всякие байт ориентированные интерфейсы я лично всегда в потоке по байтам разбираю (FIFO пики сглаживает)- это быстрее, чем постфактум мусор повторно разгребать.

Извините за то, что увожу дискуссию в сторону. (Надеюсь, потом веренемся обратно.)
По высказанной методике у меня имеется вопрос к уважаемему zltigo. При всем своем почтении, я отнюдь никак не хочу загнать zltigo в угол. Тем более при народно. Тем более, что это бесполезно. Это чисто вопрос, без признаков какой-либо борьбы.


Описываю ситуацию.

Предположим, имеются два устройства, которые одно другому пересылают поток какой-то инфы. Поток достаточно большой. Допустим, пересылаем какой-то файл. (Хотя изначально, файл -- это и есть поток батов. Ну разве что еще поименованный и обремененный еще кое-какими аттрибутами. Не важно.)

Допустим, линия связи работает на пределе своих возможностей (Дальность умноженная на Скорость), и поэтому иногда случаются искажения при передаче инфы. Разумеется, для таких видов передач удобнее будет выбрать не по-байтовый режим пересылки, а блочный. Т.е. группируем байты в кучку (пакет), снабжаем CRC и пересылаем.

На другом конце мы не можем (по понятным причинам) начать обработку принятого пакета до тех пор, пока не убедимься в валидности пакета. Иначе говоря, прежде чем с пакетом работать, нам по любому придется его принимать целиком в память.

Вопрос.

- Означает ли описанная выше ситуация, что прием пакета -- это есть "заглатывание всякой всячины и возможного мусора" ?
- Пожалуйста, покажите, как бы Вы "всегда в потоке по байтам разбирали" и обрабатывали принятую информацию?
- Возможно, у Вас есть другое видение ситуации, которое я не улавливаю. Как бы Вы решили такую задачу?

(Если нужны пояснения или детали -- предоставлю.)

[zltigo]

- Возможно, у Вас есть другое видение ситуации, которое я не улавливаю. Как бы Вы решили такую задачу?

Решаю постоянно - фреймы переменой длинны, протоколы SLIP-образные. Могу еще на лету подпаковывать немного....Забрасывание непонятно какой порции в память с последующем ползанием по памяти (где фрейм-то? Сумму считаем, ошибки постфактум разгребаем)крайне неэффективно. В потоке слегка буферизированным 16-32 байтовым FIFO ищется начало фрейма, считается контрольная сумма распаковывается, до получения конца фрейма кладется в нужный буфер. По получению конца фрейма контроль, принятие решение по сдвигу указателя и ждем фрейма.
Даже если начинаем рассуждать о вырожденных вариантах - фреймы фиксированной длинны, пропаданий/мусора почти нет, тем не менее, по действительно с минимальными затратами ресурсов оказавшимуся в памяти фрейму надо пробежаться, посчитать сумму это, простите, ВРЕМЯ (хорошо, если квитирование есть и канал ждет, а если нет - ой!). А уж если сбой какой, то тут уже и пляски с бубном - где начало, где конец, выбросить битый фрейм, переслать огрызок потенциально целого по месту, DMA препрограммировать нештатно.... Короче где экономия от того, что у меня с небольшими затратами в памяти что-то потенциально НЕПОНЯТНОЕ оказалось? Для идеальных паркетных условий - спору нет - раз DMA и в дамки. Только ведь идеальных условий нет практически никогда.

...я отнюдь никак не хочу загнать zltigo в угол. Тем более при народно.

Я старый, битый и многоопытный - туда, где в угол загнать могут не суюсь. Шутка

[zhevak]

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

Как Вы определяете конец фрейма?
1) по количеству байт или
2) признаком конца является какой-то особый байт

Если первое, то это работа чисто для ДМА. Зарядили ему количество, он тупр забирает их у периферии и кладет нерассматривая в памать. Но ведь Вы говорили, что

байт ориентированные интерфейсы я лично всегда в потоке по байтам разбираю

Значит, получается -- второе. Т.е. в самом прерывании (от периферии) забираете принятый байт, оцениваете его на предмет маркера конца фрейма и кладете (или не кладете) его в память, подсчитываете CRC, занимаетесь задачами байт-стаффинга ... ну и т.д. Но ведь это-то как раз не эффективно получается. Или я что-то не понял.

тем не менее, по действительно с минимальными затратами ресурсов оказавшимуся в памяти фрейму надо пробежаться, посчитать сумму это, простите, ВРЕМЯ (хорошо, если квитирование есть и канал ждет, а если нет - ой!).

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

Причем здесь бубен? Битый фрейм выкидываем без разговоров ("немножко мертвый" -- нет такого понятия!) и полностью -- никаких "огрызков".

Короче где экономия от того, что у меня с небольшими затратами в памяти что-то потенциально НЕПОНЯТНОЕ оказалось?

Вы спрашиваете? Я Вам отвечу!
Экономия в том, что процессы получения и обработки становятся независимы друг от друга. Другими словами, процесс обработки мы можем выполнить тогда, когда высвободится процессор, в то же время, процесс получения потока в памать ресурсы проца вообще никак не занимает.

Правда тут есть накладные расходы, нужно иметь в памяти два буфера, которые работают по-переменно. (Но, как мне кажется, потери памяти не велики -- всего пол-кило байт!)

Как это выглядит. Принимаем заголовок пакета, где (помимо еще чего-нибудь) находится длина пакета.
Длину пакета засылаем в ДМА. И, собственно все! Ждем прерывания об окончании ДМА-операции. В это время решаем свои насущние задачи. Приходит прерывание от ДМА, переключаемся на второй буфер и ставим флаг готовности первого буфера. Выходим из прерывания. Где-то там в процессе бесконечного цикла должна быть проверка этого флага. Если флаг стоит, то вызываем функцию подсчета CRC и т.д. В это время могут возникать отдельные прерывания по приему байтов заголовка следующего пакета, которые не влияют на подсчет CRC и последущую обработку пакета.

Тут может быть имеет смысл признаться, что реальные устройства занимаются помимо описанных выше действий занимаются еще и другой работой: мониторят кнопочи, моргают светодиодиками, рисуют на экране... Вот про кнопочки -- это очень актуально. Если окажется, что система будет реагировать на нажатия с запаздыванием (если вообще сможет, гы-гы!), то такой девай вряд ли кому-то будет нужен.

Теоретически, интегральное время обработки всего и всех должно быть меньше, чем обшее время работы проца. В противном случае нужно выбирать другой более быстрый проц или решать задачу с привлечением нескольких камней. Одно дело математическое суммирование времен выполнения процессов без оглядки на то, что процессы несинхронны, и другое дело -- реальное рапределение занятости проца. Я говорю о том, когда процу "приспичит" делать одновременно сразу несколько дел: обработать пакет, нарисовать что-то на экране и успеть вякнуть на нажатие кнопки. Поэтому следует четко осознавать приоритеты задач, продолжительность выполнения задач и время, на какое можно отложить их выполнение (поставить в очередь).

Не скрою, мне тоже приходится решать уникальные трудные (== интересные) задачи. Боюсь, что поднятый мной вопрос об эффективности по-байтовой обработке потока очень многословен. На столько многословен, что обсуждение его в форуме становится практически невозможно. Поэтому, если нет возражений, то я снимаю его.

[zltigo]

Как Вы определяете конец фрейма?
1) по количеству байт или
2) признаком конца является какой-то особый байт

конечно второй вариант - я же говорил волшебное слово SLIP. По "количеству", волшебным заголовкам это менее универсально и надежно.

Если первое, то это работа чисто для ДМА. Зарядили ему количество, он тупр забирает их у периферии и кладет нерассматривая в памать.

И даже в этом случае у Вас,например, банально в канале пропал байт во фрейме. Дальше сами расскажите, как будете вылезать из ситуевины?

Причем здесь бубен? Битый фрейм выкидываем без разговоров ("немножко мертвый" -- нет такого понятия!) и полностью -- никаких "огрызков".

Для определения битости фрейма нужно по нему всему пробежаться-прочитать-просуммировать, даже если он целый пришел. А если в конце вместо последнего байта начало следующего фрейма прибежало.... разборки начались, извлечение целого фрейма, восстановление синхронизации фреймов, скоее всего в Вашем простешем случае уже и потеря втрого фрейма... время, время, время... Я уже писал, что не вчера и не сразу умным родился, контроллеров разных и DMA и без пользовал для разных задач... В результае я начинаю рассматривать для байтовых (нефреймовых) интерфейсов прежде всего работу в FIFO, даже если есть выбор.
Далее, а буфер-то у нас какой? Кольцевой? А как с поддержкой кольцевых буферов? У всех DMA контроллеров с этим хорошо? У нориальных DSP - хорошо, а у SAM7 просто никак. Заодно и расход памяти минимум на две целых полочки для макимальных фреймов не радует совсем. Минималистичный, прямо скажем, DMA

А кто же ему запретит-то? И уж на одно слово FIFO присутствует всегда.

Другой, DMA, например, захватил шину. Разруливать по слову будем, и при этом рассуждать об эффективности DMA?
На одно слово, это не FIFO.

[aaarrr]

Другой, DMA, например, захватил шину. Разруливать по слову будем, и при этом рассуждать об эффективности DMA?
На одно слово, это не FIFO.

Другой DMA (если это PDC) захватить шину может на время передачи одного слова, EMAC - на 4-х. Никаких затыков при таких условиях не будет.