В своё время стоял перед выбором между 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 - тогда появляется возможность выбора.