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

почти нахрен не нужного при отсутствии у SAM7 кэшей, отдельных шин, банков памяти и неймановской архитектуре - пока DMA работает - процессор стоит. Практически голый маркетинговый ход для развода ....
У LPC DMA наряду с FIFO присутствует в более современных LPC214/23/24/17, где появилось две периферийных шины или матрица с отдельными банками памяти - вот тут уже DMA во всей красе эффективно работает в определенных условиях.

ну очень необходимая для SAM7 приблуда - стоящее колом ядро не имеющее доступа ни к данным ни к командам во время работы DMA захватившего единственную шину. Когда, например, DMA в сходой ситуации используется например, MSP430 для снижения энергопотребления это понятно...
Оно, конечно, лучше такое DMA, чем совсем ничего, но в большинстве случаев на простеньких ARM7 уровня старых LPC21/22 и нынешних SAM7 банальное FIFO эффективнее работать позволяет.

Господа! Ну не может DMA, обслуживающий даже несколько потоков на пару десятков мегабит (что для ARM7 скорее исключение) "поставить колом" ядро. Не может.
Если не верите, то возьмите калькулятор и посчитайте потоки.

Я не говорил, что ядро SAM7 все время стоит колом - только во время работы DMA, как только закончит выполнять текущую команду. А уж сколько там DMA грузят это дело второе. Суть в том, что паралельно с ядром они у SAM7 не фурычат и соответственно радостного эффекта аля-пентиум, когда ядро работает с многомегабайтовыми и многоуровневыми кешами пока DMA льет чего-то в память нет. У современных LPC, а не 4-5 летней давности LPC210x/211x/22xx при наличии нескольких шин и банков DMA появилось и РЕАЛЬНО ЭФФЕКТИВНО РАБОТАЕТ. В отличии от любых SAM7. При этом у всех LPC есть хотя-бы четырех/восьми словная предвыборка команд из 128bit Flash. Предмета для обсуждения выбора по критерию DMA просто нет. Лет пять назад в эпоху LPC210x и LPC211x проблема выбора действительно в общем-то по некоторым вторичным параметрам стояла - сам до последнего момента выбирал с чего начать LPC2000/SAM7.. Теперь не стоит. Atmel на данный момент лидер в ARM9 c внешней шиной, но не в ARM7. Тему ARM7 закрыл NXP. Сейчас еще добьет их своими pin-to-pin совмстимыми LPC1700, в следующем году мелкие LPC1300 и.... и хоть и запоздало, глядя с моей колокольни , в этом и следующем году развернет наступление на ARM9..

Нет, не второе. Или для Вас является критичным замедление выполнения программы на 0.5%?
PDC предназначен для обслуживания медленной периферии, и с этой задачей справляется отлично. Для скоростных - Ethernet, LCDC - есть свои DMA с FIFO.

Абсолютно не согласен на счет бесполезности.
Мне, например, на данный момент необходимо принимать и передавать пакеты по UART'у со скоростью 500 кбит/с, максимальная длинна пакета 256 байт. По второму байту пакета определяю оставшееся кол-во байт в пакете и "заряжаю" на него DMA. при отправке все еще проще. Так вот, вопрос - 256 входов в прерывание для обработки одного пакета лучше чем 2 ? При передаче и того проще.
На этом фоне работают прерывания от PIO(примерно от 16 ног порта), PIT, TC1, SPI, UART1, и DMA сдесь как нельзя кстати.
Не, ну если передавать изредка по одному, два байта - вопросов нет - бесполезная штука. Если скорость обмена с выбранным модулем сопоставима со скоростью работы ядра, то так же эффективность DMA у SAM7 стремится к нулю из-за постоянного захвата шины. Но это два крайних варианта.
Ну да, есть у SAM7 недостатки, как и у других, и во многом он проигрывает более новым LPC,
но заявления по поводу полной бесполезности DMA у SAM7, на мой взгляд, чистая религия.

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


Во всем

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

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


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

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

Не во всем: SSP проигрывает атмеловскому SSC. И UART'ы хуже.


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


У меня вот регулярно в задачах нужно формировать и принимать ~20Мбит потоки через SPI и SSC. На младших LPC я бы просто удавился, вопрос об использовании старших сейчас пытаюсь для себя решить.

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


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

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

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

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

Вопрос.

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

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

А конкретизировать?

А да-да любители простых RS485 решений жалуются... Как-то я тут уже подрооообно обсуждал это. В обще-то ничего страшного-то и не оказалось.

Спокойствие и время затраченное на обработку зависят от протокола. Во всех моих случах за десятки лет я удовлетворен FIFO, причем у одного из максимально много и долго мною используемых ранее контроллеров AM186CC и с DMA и с FIFO все в полном порядке - полная свобода выбора. Посему я совсем не не зазобравшись и не вкусив прелестей DMA все это пишу.

"Присоединяйтесь барон" начинал c LPC2114, LPC2294,.... Сейчас LPC2138/48, LPC2378, LPC2468...
Младшие LPC213x заменят вскоре на pin-to-pin Cortex-M3 V2 - попугаев поболе, прерывания шустрые, красотулечки типа атомизации последовательности команд. Цены... Не вопрос, короче!

2 injen-d и iaaarrr:
Ок, насчет полной бесполезности я пожалуй таки [слегка] погарячился. Но, надеюсь, никто не будет спорить что польза от DMA в DSP в разы больше чем в SAM7.

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

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

+1
Аналогично, у меня 3 uart одновременно на 115200 непрерывно + всякие рассчеты в float
при попытке переключить на прием без DMA(ну там с подсчетом CRC например) начинают
тереться пакеты.
Пакеты длинной до 256байт, FIFO например в 16 байт будет более эфективен ?


А каков % таких нештатных ситуаций/битых пакетов ?
Если 0,01% то DMA неэфективен ?
А если 0,1% ?
А если 1% ?

Справедливости ради:


...и без FIFO...

Ничего удивительного.



UART - не самый удачный пример в данном случае. Вот скоростной SPI - другое дело.

Но лучше иметь и DMA и FIFO - тогда появляется возможность выбора.

MAC-ом от LPC на данный момент доволен как слон . Благодаря отдельной шине+16K банк+DMA большое количество мелких пакетов летают почти даром.

SPI/SSP обычно себя ведут, вроде , ибо у меня только AT45 на штатном SPI. SPI+аппаратная поддержка протокола для связи с внешними миром в FPGA уползла, а на FPGA хоть и на 8bit шине, по скорости тоже пожаловаться не могу. Хотя, конечно, внешнюю шину втихаря (в старых PDF диаграммы были - в новых выбросили) тормознули (зато работает ) и теперь в ней все по тактам ядра.

Конечно, но согласитесь что в данном случае ДМА лучший вариант чем FIFO.

Вот я чего-то недопонимаю, почему пример с uart в данном случае не лучший ?
Кто б спорил, более того иногда можно совмещать эти 2 варианта.

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

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

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




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


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

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

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

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

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

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

Фреймы до где-то 386 байт, два потока по 115K в качестве вспомогательных задач. FIFO 16. Никаких проблем и близко не наблюдается.

В моих условиях может быть до 100% - надо жить и когда вместо даннных вдруг полный мусор пошел. Дело ведь не в том, что нельзя найти часный случай, когда голое FIFO или голое DMA на ARM7 не будет на сколько-то там проценов эффективнее, а в том, что это для поростых ARM совершенно сопоставимые по эффективности решения, и говорить "ах, как жить без DMA" совершенно необъективно.

К SAM'у тоже претензий нет. Немного раздражает только фиксированный размер приемных буферов - 128 байт.


Мне на SPI придется 20Мбит выплевывать, возможно одновременно через два канала. Поэтому делитель SSP не вызвал восторга.

А внешние шины - это, похоже, вечная проблема Philips/NXP - на своих USB-контроллерах они их тоже замедляли потихоньку

Эти варианты ДОЛЖНЫ быть совмещены, ибо что будет делать периферия, если ей канал DMA мгновенно не дадут когда ей приспичит. В нормально организованной системе (все уже поняли о чем это я ) должно быть и то и другое FIFO или FIFO+DMA. Голый DMA череват для сколь-нибудь скоростных вещей.

Потому что он слишком медленный, и при наличии FIFO серьёзную нагрузку на процессор дать не может.


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

В таких условиях конечно FIFO+разбор пакетов на лету лучший вариант.
Я говорю о случаях когда и 0,1% пакетов уже очень плохо.

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

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

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


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

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

Не об этом речь, а об ЭФФЕКТИВНОСТИ работы DMA в режиме захватил(сколько тактов), одно слово передал, освободил(сколько тактов)... Вылезли все, помнится, 18 каналов (ну крутой контроллер - 18 штук целых!) SAM7 с желанием поработать, через сколько тактов крайний разгрузится? На MAC/USB ведь FIFO поставили А как Вы там будете 2x20Mbit из SPIев на голых DMA дерущихся за шину тянуть, это уже тоскливо становится.

Вы уже умеете "нормально распоряжаться", дабы никому не мешать? Или, полагаете, что это знание придет после оплаты 200USD за многослойку ? Про умелое обращение с ARM9 (кэши, MMU, SDRAM....) можно еще много больше поговорить .

И чего нервничать? Человеку интересно совсем не то, что вы обсуждаете, то бишь флудите. См. заглавную статью топика.

А за умелое обращение не переживайте. Не только вы иностранные буковки выучили.

Все это не так сложно, Семен. Тем более, все это добро АРМ9 никто не заставляет использовать сразу.

Во-первых, все -дцать каналов одновременно не вылезут, ибо даже приложение такое придумать трудно.

Единственное, что известно от Atmel'а:


А 2x20Mbit с параллельно работающим EMAC я и сейчас тяну без особых проблем.

Смешно . Товарщ захотел сделать буквально на коленке плату уровня ARM7 - логично (не то, что на коленке, а то, что ARM7), самый, что ни наетсь сегодняшний mainstream. Рассуждаем о выборе производителя, ну подробно рассуждаем, углубленно, так сказать... А тут некто периодически встревает за многслойки за сотни баксов, ARM9, навеске на него всекой вячины типа LCD на "вырост". А сейчас еще и о флуде разговор завел. Не сочтите за наезд, но пыл умерьте, пожалуйста. Можете очередную тему создать типа "ARM9 для начинающих" и подробнейшим образом высказаться о путях и методах. С удовольствием поучаствую, или помолчу - как скажите....


Это именно про "Low bus arbitration overhead"
плюс сама пересылка..
Итого не менее трех тактов на пословную пересылку из переферии + тормоза собственно периферийной шины...

Да нет, это всего (я смотрел описание IP Core, а не DS).


Все равно полоса внутренней шины многократно покрывает способности периферии, как ни крути.

Чудес в 21 веке не бывает, ну не отрабатывает AHB и APB шина (с какой частотой SAM7 PIO машет?) и DMA арбитраж за 0 тактов...

Сугубо внутренняя локальная на которой память висит это одно, AMBA AHB это другое, периферийная APB это третье и еще тормознее. Все определяет слабейший и некая полоса занимается и вопрос в том, хватает-ли остатков пропускной способности ядру, дабы дорваться до памяти и выполнить нужную работу.

Остатков? У ядра 32бит * 55MHz = 1.76Гбит/с - сколько нужно вычесть UART'ов и SPI'ев, чтобы стало "не хватать"? Даже с учетом арбитража и тормозов периферийной шины, о которых мы ничего не знаем по большому счету?


Никакие. Это просто обкоцанный UART.

Ну встречал какртинку в SAM7 PDF на которой доступ к APB в два такта рисовался. Полагаю, что суммарная очень оптимистичная оценка по пересылке из периферии не менее 5 тактов. Если тот-же SPI байтовый, то на 20 мегабитах это 12,5 тактов из 55 уходит на пресылку. Уже очень заметная величина особенно еcли SPI две штуки да еще и MAC (там по невнятной ATmel картинки вроде мимо APB есть канал, но тем не менее) DMA пользует.




Ну вот всю малину обломали. Я ждал ответа от DpInRock. Такое красивое маркетинговое слово DBGU - ну прямо "чернила для шестого класса". У Вас есть "чернила для шестого класса"? нет А у Atmel есть - "это плюс" ...

Да, 2 такта. Тоже видел картинку, правда не у Атмела.


При 5-и тактах на слово и 20Мбит скорости будет занято 5.7% полосы шины. MAC висит на AHB.

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

Давайте. Интересно будет посмотреть на результаты. Серьезно.

А это-то как повлияет ?
Еще не готов, шину не захватывает...

Итак, результаты тестов готовы

Программа выполнялась из RAM, это простой цикл из кучи NOP'ов. Т.е. процессор только выбирал команды из памяти, не обращаесь к ней за чем-либо еще.
Затем был запущен 8-bit SPI-поток на частоте MCK - это самые худшие условия: PDC вычитывает и записывает слово каждые 8 тактов процессора.

Что получилось (время выполнения тестового куска в тактах):


Как можно видеть, шина действительно занимается на 1 такт для записи в периферию и на 2 - для чтения из неё.


3 такта MCLK на одну запись в порт. Т.е. частота дрыганья = MCLK/6.

Причем тут захватывает? Пропускная полоса шины в разы падает при обращении к Flash.

И еще более интересные результаты при работе из Flash (1WS):



0WS:


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

Бумажки, граждане, настоящие! (С)

Что за результаты без методики?

Прелестые условия - чтоб я так работал

Ну ну..
И чуть ниже про обращение к PIO висящем на той-же APB:

Ну прямо чудо какое-то. Поскольку чудес не бывает, то методика "того"...

Пропускная полоса чего падает в разы ?
Мы вроде как говорили об обмене между SRAM и переферией по DMA ?
При чем здесь доступ к флеш ?

Говорим о том сколько остается от пропускной способности шины.

Я в своей методике вполне уверен. Если имеете что предложить - предлагайте.


Процессор честно считывает команды из памяти каждый такт, что не устраивает для измерений?


2 такта выполняется STR, еще один на доступ к шине.

Прелестно, ну а давайте не играть в поддавки и на полных 55MHz.

Похоже, что Flash сидит на отдельной шине.

А я ее просто не вижу, посему уверенным быть ну никак не могу.

Для 1WS я результаты уже написал.

То есть Вы согласны что ДМА лишнего не отожрет, и разговор только о
том что у SAM7 флеш не слишком быстрая(правда в разы..., это как-то слишком громко было
сказанно )

А как-же c ARM7 Нойманом быть?



Разумеется нет.

А какое дело DMA до Неймана?