Эффективность 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 и пересылаем.

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

Вопрос.

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

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