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

[Proton]

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

[zltigo]

решающим стало наличие DMA у SAM7.

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

До этого работал с DSP и уже с трудом представляю как без него(DMA) обходиться.

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

[aaarrr]

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

DMA в любом завалящем DSP и в SAM7, это "две большие разницы". В SAM7 - это чистой воды маркетинг.

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

[zltigo]

Ну не может 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..

[aaarrr]

Я не говорил, что ядро SAM7 все время стоит колом - только во время работы DMA, как только закончит выполнять текущую команду. А уж сколько там DMA грузят это дело второе.

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

[injen-d]

ну очень необходимая для SAM7 приблуда - стоящее колом ядро не имеющее доступа ни к данным ни к командам во время работы DMA захватившего единственную шину.

DMA в любом завалящем DSP и в SAM7, это "две большие разницы". В SAM7 - это чистой воды маркетинг.

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

[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 и того и другого, да и еще архитектурно правильно организованного и вообще не обсуждается

[Dog Pawlowa]

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

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

[aaarrr]

Во всем

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

...только вот что-то я никогда не писал алгоритмов по заглатыванию 256 байт всякой всячины и возможного мусора и последующем ДОЛГОМ в нем копании. Всякие байт ориентированные интерфейсы я лично всегда в потоке по байтам разбираю - это быстрее, чем постфактум мусор повторно разгребать. Это эффективнее.

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

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

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

[zhevak]

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

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


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

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

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

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

Вопрос.

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

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

[zltigo]

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

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

И UART'ы хуже.

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

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

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

..вопрос об использовании старших сейчас пытаюсь для себя решить.

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

[vik0]

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

[zltigo]

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

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

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

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

[singlskv]

Абсолютно не согласен на счет бесполезности.
Мне, например, на данный момент необходимо принимать и передавать пакеты по UART'у со скоростью 500 кбит/с, максимальная длинна пакета 256 байт. По второму байту пакета определяю оставшееся кол-во байт в пакете и "заряжаю" на него DMA. при отправке все еще проще. Так вот, вопрос - 256 входов в прерывание для обработки одного пакета лучше чем 2 ? При передаче и того проще.

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

А уж если сбой какой, то тут уже и пляски с бубном - где начало, где конец, выбросить битый фрейм, переслать огрызок потенциально целого по месту, DMA препрограммировать нештатно.... Короче где экономия от того, что у меня с небольшими затратами в памяти что-то потенциально НЕПОНЯТНОЕ оказалось? Для идеальных паркетных условий - спору нет - раз DMA и в дамки. Только ведь идеальных условий нет практически никогда.

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

[aaarrr]

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

при попытке переключить на прием без DMA(ну там с подсчетом CRC например)

...и без FIFO...

начинают тереться пакеты.

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

Пакеты длинной до 256байт, FIFO например в 16 байт будет более эфективен ?

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

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

[zltigo]

с 100 Ethernet MAC

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

быстрым SPI...

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

[singlskv]

Справедливости ради:
...и без FIFO...
Ничего удивительного.

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

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

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

Вот я чего-то недопонимаю, почему пример с uart в данном случае не лучший ?

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

Кто б спорил, более того иногда можно совмещать эти 2 варианта.

[zhevak]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[zltigo]

Пакеты длинной до 256байт, FIFO например в 16 байт будет более эфективен ?

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

А каков % таких нештатных ситуаций/битых пакетов ?

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

[aaarrr]

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

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

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

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

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

[zltigo]

Кто б спорил, более того иногда можно совмещать эти 2 варианта.

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

[aaarrr]

Вот я чего-то недопонимаю, почему пример с uart в данном случае не лучший ?

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

Эти варианты ДОЛЖНЫ быть совмещены, ибо что будет делать периферия, если ей канал DMA мгновенно не дадут когда ей приспичит.

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

[singlskv]

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

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

[zltigo]

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

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

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

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

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

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

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

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

[aaarrr]

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

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

[zltigo]

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

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

Если нормально распорядиться.

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

[DpInRock]

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

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

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

[aaarrr]

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

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

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

• One Master Clock Cycle Needed for a Transfer from Memory to Peripheral
• Two Master Clock Cycles Needed for a Transfer from Peripheral to Memory

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

[zltigo]

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

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

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

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

[aaarrr]

Это именно про "Low bus arbitration overhead"
плюс сама пересылка..

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

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

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

[zltigo]

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

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

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

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

[aaarrr]

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

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

А я что?А я ничего Так,DBGU - это плюс. А какие среды его поддерживают?

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

[zltigo]

и тормозов периферийной шины, о которых мы ничего не знаем по большому счету?

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

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

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

[aaarrr]

Ну встречал какртинку в PDF на которой доступ к APB в два такта рисовался.

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

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

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

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

[vik0]

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

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

[singlskv]

Кстати, еще о шине Flash ведь не оаботает на 55MHz/18ns - там еще пару waitstates - ой что с пропускной способностью становится....

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

[aaarrr]

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

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

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

Код

ошибка

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

Мысли вслух- а с какой скоростью можно ножками шевелить,а?

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

[zltigo]

Еще не готов, шину не захватывает...

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

[aaarrr]

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

Код

ошибка

0WS:

Код

ошибка

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

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

[zltigo]

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

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

Программа выполнялась из RAM, это простой цикл из кучи NOP'ов. Т.е. процессор только выбирал команды из памяти, не обращаесь к ней за чем-либо еще.

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

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

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

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

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

[singlskv]

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

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

[zltigo]

Мы вроде как говорили об обмене между SRAM и переферией по DMA ?

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

[aaarrr]

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

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

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

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

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

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

[zltigo]

0WS:

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

[aaarrr]

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

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

[zltigo]

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

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

[aaarrr]

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

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

[singlskv]

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

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

[zltigo]

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

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

То есть Вы согласны что ДМА лишнего не отожрет...

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

[aaarrr]

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

[zltigo]

правда в разы..., это как-то слишком громко было
сказанно )

Именно в разы +1 WS - в два раза +2WS в три раза...

[aaarrr]

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

Вам код выложить для проверки?

Именно в разы +1 WS - в два раза +2WS в три раза...

2WS не используются никогда.

[zltigo]

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

Это я ведь о Вашем выводе "Похоже, что Flash сидит на отдельной шине."

Вам код выложить для проверки?

Проверить не начем, но почитать могу...

2WS не используются никогда.

Возможно. У Atmel 36ns Flash??? Крутовато несколько, но не невозможно. При более ширпотребно-реальных 55ns в акурат 3WS.

[singlskv]

Именно в разы +1 WS - в два раза +2WS в три раза...

Выкладывайте тест когда будет как минимум в 3 раза, протестирую...

[aaarrr]

Это я ведь о Вашем выводе "Похоже, что Flash сидит на отдельной шине."

Да, т.е. никто не мешает процессору читать Flash, в то время, как DMA окучивает RAM.

Проверить не начем, но почитать могу...

CODE

u_int spi_buff[5000];

void test(void)
{
u_int b;
u_short a;

AT91C_BASE_PMC->PMC_PCER = (0x01 << AT91C_ID_TC0);

// Wave mode, MCK/8, UP mode with automatic trigger on RC Compare
AT91C_BASE_TCB->TCB_TC0.TC_CMR = AT91C_TC_CLKS_TIMER_DIV2_CLOCK | AT91C_TC_WAVESEL_UP | AT91C_TC_CPCSTOP | AT91C_TC_WAVE;
AT91C_BASE_TCB->TCB_TC0.TC_RC = 0xffff;
AT91C_BASE_TCB->TCB_TC0.TC_CCR = AT91C_TC_CLKEN;
AT91C_BASE_TCB->TCB_TC0.TC_CCR = AT91C_TC_SWTRG;

spi0_ini();
for(b = 0; b < 5000; b++)
spi_buff[b] = (0x07 << 0x10) | 0x55;
AT91C_BASE_SPI0->SPI_TPR = (u_int)spi_buff;
AT91C_BASE_SPI0->SPI_TCR = 5000;
AT91C_BASE_SPI0->SPI_RPR = (u_int)spi_buff;
AT91C_BASE_SPI0->SPI_RCR = 5000;

dprintf("bla-bla\r\n");

AT91C_BASE_SPI0->SPI_PTCR = AT91C_PDC_TXTEN | AT91C_PDC_RXTEN;

a = AT91C_BASE_TCB->TCB_TC0.TC_CV;
b = 0x100;
do
{
__asm
{
nop; nop; nop; nop; nop; nop; nop; nop;
nop; nop; nop; nop; nop; nop; nop; nop;
nop; nop; nop; nop; nop; nop; nop; nop;
nop; nop; nop; nop; nop; nop; nop; nop;
nop; nop; nop; nop; nop; nop; nop; nop;
nop; nop; nop; nop; nop; nop; nop; nop;
nop; nop; nop; nop; nop; nop; nop; nop;
nop; nop; nop; nop; nop; nop; nop; nop;
}
} while(--b );
a = AT91C_BASE_TCB->TCB_TC0.TC_CV - a;
dprintf("t=%d\r\n", a);

while(0x01);
}

void spi0_ini(void)
{
AT91C_BASE_SYS->PIOA_BSR = SPI0_CS1 | SPI0_CS2 | SPI0_CS3;
AT91C_BASE_SYS->PIOA_ASR = SPI0_CS0 | SPI0_MISO | SPI0_MOSI | SPI0_SPCK;
AT91C_BASE_SYS->PIOA_PDR = SPI0_CS1 | SPI0_CS2 | SPI0_CS3 | SPI0_CS0 | SPI0_MISO | SPI0_MOSI | SPI0_SPCK;

AT91C_BASE_PMC->PMC_PCER = (0x01 << AT91C_ID_SPI0);

AT91C_BASE_SPI0->SPI_CR = AT91C_SPI_SPIEN;
AT91C_BASE_SPI0->SPI_MR = AT91C_SPI_MODFDIS | AT91C_SPI_PS | AT91C_SPI_MSTR; // Master, Variable mode

AT91C_BASE_SPI0->SPI_CSR[0x03] = (0x01 << 0x08) | (0x00 << 0x04)
| AT91C_SPI_NCPHA | AT91C_SPI_CPOL; // Dummy: SPI Mode 2, MCK, 8 bits
}

Возможно. У Atmel 36ns Flash??? Крутовато несколько, но не невозможно. При более ширпотребно-реальных 55ns в акурат 3WS.

В документации написано:

Single Cycle Access at Up to 30 MHz in Worst Case Conditions

[singlskv]

Возможно. У Atmel 36ns Flash??? Крутовато несколько, но не невозможно. При более ширпотребно-реальных 55ns в акурат 3WS.

zltigo я уже приводил пример в другой ветке когда доступ к флеш
у Renesas 12,5ns , сейчас у них уже 10ns, так что 36ns не есть что-то особенное,
на самом деле там вобще скорее всего ~30ns по максимуму, по крайней мере
у меня на SAM7A3 и на 65Мгц все работает(была ошибка в задании PLL , предыдущего
программера )

[zltigo]

Выкладывайте тест когда будет как минимум в 3 раза, протестирую...

Тестировать незачем. Это физическая сущность . Нужны WS - стоим и ждем.

В документации написано:
Single Cycle Access at Up to 30 MHz in Worst Case Conditions

Радует! LPC только за счет своей 128битности вытягивает скорость. Только интерсно тогда отчего они на числе 55MHz остановились?

CODE...

Я тестику реализма прибавлю самую малость. Проверите?

zltigo я уже приводил пример в другой ветке когда доступ к флеш
у Renesas 12,5ns , сейчас у них уже 10ns, так что 36ns не есть что-то особенное,

Верю, верю, просто SAM7 совершенно массовый дешевый контролер, а массовая Flash нынче отнюдь не 10-12-30ns.

[aaarrr]

Радует! LPC только за счет своей 128битности вытягивает скорость. Только интерсно тогда отчего они на числе 55MHz остановились?

Мне тоже не понятно. Где-то случился затык, и отнюдь не во флеш. Предыдущие ARM7 у них были и на 66MHz.

Я тестику реализма прибавлю самую малость. Проверите?

Пожалуйста.

[singlskv]

Верю, верю, просто SAM7 совершенно массовый дешевый контролер, а массовая Flash нынче отнюдь не 10-12-30ns.

Дык вроде как и Xmega у Atmel теперь ~30ns доступ к флеш...
30Мгц для доступа к флеш у Atmel уже давно...
И вот меня это совсем не удивляет, возможно за это они и берут свой "лишний" бакс к цене...

[aaarrr]

Легко. Посмотрю на дальнейшее развитие и разделю тему.

ИМХО, имеет смысл отделить бенчмарки и кинуть в раздел ARM. Тема сама по себе интересная получается.

[zltigo]

Пожалуйста.

Как скучно оказывается всухую писать . Просьба для начала заменить nop-овский цикл на такое:

Код

volatile u_int b = 0x800;
volatile u_int c = 0;
volatile u_int d = 0;
    do
    {
        c = AT91C_BASE_TCB->TCB_TC0.TC_CV;
        d += c;
        
    } while(--b );
    a = AT91C_BASE_TCB->TCB_TC0.TC_CV - a;
    dprintf("t=%d\r\n", a);
    d = d;

Интересен Flash, 55MHz, ARM mode.

Тема сама по себе интересная получается.

Естественно!

[aaarrr]

Как скучно оказывается всухую писать . Просьба для начала заменить nop-овский цикл на такое:
Интересен Flash, 55MHz, ARM mode.

Сделано.

Flash 1WS:

Код

ошибка

RAM 0WS:

Код

ошибка

Числа - это количество тактов на выполнение (выход * 8).
Время симулятора для случая RAM 0WS PDC Idle: 16382

[zltigo]

Сделано.

Очень интересный результат! Похоже сегмент шины с Flash как-то изолируем, что позволяет по хозяйски распоряжаться неизбежным 50% простоем ядра при доступе к Flash для доступа DMA к RAM.
А 30MHz и 0WS из Flash еще пожалуйста!

[aaarrr]

Результат еще интереснее. Как я уже писал, очень похоже, что шина Flash отделена.

Flash 0WS:

Код

ошибка

Незначительное ускорение не случайное, повторяется стабильно.

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

[singlskv]

Очень интересный результат! Похоже сегмент шины с Flash как-то изолируем, что позволяет по хозяйски распоряжаться неизбежным 50% простоем ядра при доступе к Flash для доступа DMA к RAM.
А 30MHz и 0WS из Flash еще пожалуйста!

То есть 3 раза это уже фантазия ?(ну это про разы...)

Результат еще интереснее. Как я уже писал, очень похоже, что шина Flash отделена.

Мне вобще кажется что это почти всегда на современных мк.
Нет никагого смысла располагать флеш на той же шине...

[zltigo]

Результат еще интереснее. Как я уже писал, очень похоже, что шина Flash отделена.

Странее! Не покидает мысль, что что-то не то. А разделить буфера приема передачи и организовать в тесте хоть какую-то рекцию(обработку) на окончание цикла работы DMA? И вообще, при исполнении IDLE из RAM на 55MHz получаем скорость РАВНУЮ до такта! скорости исполнения из FLASH на 30MHz. Что это c тестом?

Нет никагого смысла располагать флеш на той же шине...

Это понятно, что слова Нейман/Гарвард почти пустой звук по нынешнмм временам, но предполагал, что это все-же пока не для достаточно простых ARM7 ядер.

То есть 3 раза это уже фантазия ?(ну это про разы...)

50% это замедление в ДВА раза при ОДНОМ WS.Чего непонятного? Никаких фантазий.

[aaarrr]

Странее! Не покидает мысль, что что-то не то. А разделить буфера приема передачи и организовать в тесте хоть какую-то рекцию(обработку) на окончание цикла работы DMA?

Тогда нужно время теста укорачивать, у меня нет столько свободной памяти. Попробую.
Могу еще проконтролировать время окончания цикла DMA.

И вообще, при исполнении IDLE из RAM на 55MHz получаем скорость РАВНУЮ до такта! скорости исполнения из FLASH на 30MHz. Что это c тестом?

Я и считаю такты. А они одинаковые, хоть на 30, хоть на 55MHz.


С более скоростым доступом к периферии со стороны DMA все понятно - процессор имеет доступ через медленную APB, в то время как DMA подключен с одной стороны к ASB, а с другой напрямую к периферийным модулям.

[singlskv]

Это понятно, что слова Нейман/Гарвард почти пустой звук по нынешнмм временам, но предполагал, что это все-же пока не для достаточно простых ARM7 ядер.
50% это замедление в ДВА раза при ОДНОМ WS.Чего непонятного? Никаих фантазий.

в 2 раза в худшем случае - согласен ! (в реальности, когда еще иногда
встречаются регистр-регистр, намного лучше...)

Это понятно, что слова Нейман/Гарвард почти пустой звук по нынешнмм временам, но предполагал, что это все-же пока не для достаточно простых ARM7 ядер.

Дык видать основная борьба и проходит в данный момент по этому флангу...(у производителей)

[zltigo]

Я и считаю такты.

Тьфу, привычка по другому организовывать тесты

...а с другой напрямую к периферийным модулям.

Как-бы да, в действительности каналы DMA у SAM7 не общего назначения разделяемые ресурсы, а исключительно интимные узлы периферии.

[singlskv]

Как-бы да, в действительности каналы DMA у SAM7 не общего назначения разделяемые ресурсы, а исключительно интимные узлы периферии.

А у SAM9 или AVR32 они что, что-то совсем обособленное ?
конечно они нифига не разделяймые ресурсы, а очень было надо ?

[aaarrr]

Не покидает мысль, что что-то не то.

Вы правы, что-то не то при работе из flash. Разбираюсь сейчас.

[zltigo]

...конечно они нифига не разделяймые ресурсы, а очень было надо ?

На Atmel свет клином не сошелся . Cуществуют оба варианта Dedicated/General, обычно вместе. Кроме жестких и относительно простых каналов DMA заточенных под переферийное железо, используются и "общего назначения" более сложные DMA с наворотами, например, типа организации обслуживания кольцевых буферов, burst, fifo, big/little endian трансляцией... Они подключаются к периферийным устройствам по необходимости, в том числе и не к у устройствам, а для пересылки память-память. И между устройствами.
Надо.

[singlskv]

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

Согласен, про память-память не подумал, просто для ARM7 это вроде как не актуально...
Для АРМ9 итд. может быть действительно актуально...

[zltigo]

Согласен, про память-память не подумал, просто для ARM7 это вроде как не актуально...

Актуально, у ARM7 LPC23/24 кроме локальной еще 2 AHB шины со своми банками памяти.

[singlskv]

Актуально, у LPC23/24 кроме локальной еще 2 AHB шины со своми банками памяти.

Не знаю толком этих семейств, но это("еще 2 AHB шины со своми банками памяти")
уже не очень похоже на ARM7, подходы совсем другие,
вероятно нечто промежуточное между ARM7 и ARM9.

[aaarrr]

Друзья мои, я опечален ©

Во-первых, из-за ошибки в скрипте линкера у меня клинило DMA при работе из Flash;
а во-вторых, SPI как-то криво работает на частоте MCK/1
Поток SPI пришлось сократить в 2 раза.

RAM 0WS

Код

PDC Idle:  9224
PDC TX:    9832
PDC TX+RX: 11472

FLASH 0WS

Код

PDC Idle:  9216
PDC TX:    9840
PDC TX+RX: 11472

FLASH 1WS

Код

PDC Idle:  15368
PDC TX:    16392
PDC TX+RX: 16400

Тем не менее, можно видеть, что не так уж все и плохо

Дополнительно попробовал запустить 2xMCK/2 SPI. Не тянет уже.

RAM 0WS

Код

PDC Idle:  9224
PDC TX:    10928
PDC TX+RX: 12136 (DMA передача не уложилась по времени - 141%)

FLASH 0WS

Код

PDC Idle:  9216
PDC TX:    10928
PDC TX+RX: 12136 (DMA передача не уложилась по времени - 141%)

FLASH 1WS

Код

PDC Idle:  15368
PDC TX:    16392
PDC TX+RX: 19120 (DMA передача не уложилась по времени - 149%)

Такие вот пирожки с котятами.

[zltigo]

уже не очень похоже на ARM7, подходы совсем другие,

Отнюдь, какая разница на одну или две шины дешифрировать адресное пространство - ядро знать не знает. Все достаточно архитектурно просто. В приложении простенькая картинка.

Такие вот пирожки с котятами.

Тем неменее внесена определенная ясность, и это уже хорошо, ибо даже если не все радужно, то praemonitus praemunitus!

Эскизы прикрепленных изображений

 

[aaarrr]

Итого:
С одной стороны нас никто не обманывает, и запись/чтение периферии через DMA занимает 1/2 такта соответственно, ядро не тормозится.
Но с другой стороны, от шины получилось отгрызть без последствий только 1/8 полосы (что не так уж и плохо - 27.5Мбайт/с).
Очень неприятен момент с торможением DMA-передачи, лучше бы вставало ядро.

[zltigo]

ядро

существенно

не тормозится.

[aaarrr]

Тем неменее внесена определенная ясность, и это уже хорошо, ибо даже если не все радужно, то praemonitus praemunitus!

Ну да, не все радужно, конечно Но пользоваться вполне можно. Тем более, что перелопатить такой поток, на котором встал DMA, процессор все равно не сможет.

существенно

По мне так лучше бы оно вставало совсем - у меня процессор стоит в качестве дешевой замены FPGA, думать ему особо не приходится

[zltigo]

Тем более, что перелопатить такой поток, на котором встал DMA, процессор все равно не сможет.

Ну и последний эксперимент увеличить число DMA каналов с 4x до 6-8, какой предел пропускной способности одного канала?

Тем более, что перелопатить такой поток, на котором встал DMA, процессор все равно не сможет.

Ну насколько я понял, у Вас, как и у меня, одна из задач пропускать поток частично и мимо контроллера, просто используя его MAC? У меня это, правда, задача вспомогательно-опциональная, но и потоки потоньше - 64Kbit, хотя их побольше - до 16.

[aaarrr]

Ну и последний эксперимент увеличить число DMA каналов с 4x до 6-8, какой предел пропускной способности одного канала?

Попробуем, но уже не сегодня.

Ну насколько я понял, у Вас, как и у меня, одна из задач пропускать поток частично и мимо контроллера, просто используя его MAC? У меня это, правда, задача вспомогательно-опциональная, но и потоки потоньше - 64Kbit, хотя их побольше - до 16.

Не совсем так. У меня постоянно передаются один или два потока по 20Мбит/с, но данные для них меняются только при смене фрейма раз в 13мс. Процессору за это время нужно перепаковать и откорректировать (через LUT) данные, полученные из Ethernet'а, и его производительности хватает почти в любом случае.

[Shuuura]

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

Можно поподробнее про глюки STM32? А то уж слишком красиво на новый проект ложатся. Кардинальные отличия между версиями Cortex-M3 есть?

[zltigo]

Можно поподробнее про глюки STM32?

Errata для начала. Дальше - дальше хуже часто натыкался просто на невозможность использовать чего-либо удобным способом, хотя по логике вещей вроде и не должно было-бы быть проблем. Может это и не баги, а неописаные ограничения .
Вместо документации, блин, "библиотеки". Если свобода творчества в пределах ограниченных "библиотеками" устравивает, то наверное и проблем особых вообще не будет.

А то уж слишком красиво на новый проект ложатся.

Пользуйте, как-нибудь обойдете.

Кардинальные отличия между версиями Cortex-M3 есть?

Есть Где-то 5 багов в ядре постепенно от подверсии к подверсии исправлявниеся, но все известное исправленно во второй версии (но это будет только в LPC + несколько новых команд). Компиляторы латают.
По Corteх есть отдельная ветка - продолжите там.

[defunct]

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

Насчет заглатывания UART'a - поддерживаю. Байт-ориентед удобнее побайтово принимать и разгребать.

А вот такая задачка: оцифровка с последущим анализом (FFT) и воспроизведение звука с минимальным джиттером между семплами, скажем так Fd= 44.1kHz, mono. С SAM'овским DMA задача решается на ура без интервенции процессора, получаем сразу подготовленные для FFT выборки требуемого размера. Жрет на SAM'е эта задачка процентов 10 ресурсов проца. Будет ли такая же эффективность на LPC без DMA? И вообще можно ли ее решить на LPC, если учесть что эта задача - не самоцель, а есть еще и другие функции выполяемые МК (FIQ то только один)?

[aaarrr]

Будет ли такая же эффективность на LPC без DMA?

Дык на новых LPC есть DMA.


Посмотрел Atmel'овские статейки. Очень мило пишут про PDC, типа:

The device easily supports 25 Mbps SPI or TWI transfers, and still has 96% of it resources available to execute embedded control functions.

Всюду они эти 25Мбит суют. А TWI приплетен вообще непонятно каким боком, ибо к PDC подключения не имеет, а 25Мбит передавать не может по определению.

Easily, блин. А за easily сразу кирдык

[defunct]

Дык на новых LPC есть DMA.

Это в новых, а в тех что нет? Задачка в защиту "полной непотребности" SAM7 DMA.

А TWI приплетен вообще непонятно каким боком, ибо к PDC подключения не имеет, а 25Мбит передавать не может по определению.

опечатка вестимо. доки пишут иногда люди далекие от все этого.

[aaarrr]

Это в новых, а в тех что нет?

Вместо старого NXP лучше взять новый NXP, а не старый Atmel. О чем спорить-то?

Задачка в защиту "полной непотребности" SAM7 DMA.

Ну, о полной непотребности говорить уже не приходится. Хотя некоторая непотребность/недодокументированность есть.

опечатка вестимо. доки пишут иногда люди далекие от все этого.

Это из статьи. Опечатка забавная - вспомнили самый глючный модуль, которому этого PDC весьма, кстати, не хватает.

[VslavX]

джиттером между семплами, скажем так Fd= 44.1kHz, mono. С SAM'овским DMA задача решается на ура без интервенции процессора, получаем сразу подготовленные для FFT выборки требуемого размера. Жрет на

+1 - использую я PDC для АЦП на SAM7 - _очень_ удобно. На LPC пришлось для тех же целей все "ручками" делать.
+1 - еще PDC использую для SPI - у меня второй абонент более 4мбит не жрет, так что ни о какой блокировке шины речи не идет.
-1 - для MMC/SD по SPI PDC не очень хорошо подходит - удобнее побайтно, параллельно считая CRC
-1 - еще пытался использовать PDC для USARTа (протоколы на RS-485) - не понравилось, код распух, хотя ресурсов немного меньше от процессора отожралось. В итоге вернулся к "побайтовому" разбору - SAM-овский UART очень рулит - не понадобился допонительный таймер.
P.S. А вообще потихоньку переходим с SAM7A3/S/X/SE на LPC214x/23x8/24x8 - быстрее, честные RTC, номенклатура больше (есть 144-ногие). И по большому счету - уже пофиг LPC или SAM - HAL-ы под наши задачи понаписаны на оба семейства, все максимально абстрагировано получается. Как "партия" (рыночная коньюнктура) прикажет - такой проц и заложим , нефиг из LPC или SAM религию устраивать.

[aaarrr]

-1 - еще пытался использовать PDC для USARTа (протоколы на RS-485) - не понравилось, код распух, хотя ресурсов немного меньше от процессора отожралось. В итоге вернулся к "побайтовому" разбору - SAM-овский UART очень рулит - не понадобился допонительный таймер.

А необходимость мгновенной реакции на прерывание не напрягает? ИМХО, для UART'а как раз он очень удобен.

[Dron_Gus]

Раз уж пошел оффтопик полный. Предлагаю высказаться по поводу реализации DMA (да и FIFO) в STR912FAW**. На мой скромный взгляд, очень качественно и гибко. Это, конечно, уже ARM9...

[VslavX]

А необходимость мгновенной реакции на прерывание не напрягает? ИМХО, для UART'а как раз он очень удобен.

"Мгновенность" критична только на приеме. У меня максималка 115200 -~100мкс (пользую два стопа почти всегда) примерно в запасе есть, чтобы забрать байт. В 99.9999% байты успешно забираются, а если какие-то проблемы - это все решается протоколом на канальном уровне - ретрансмитты и прочее.
Без таких "решающих" протоколов вылазить на RS-485 бессмысленно, ну и заодно они "решат" проблему если кто-то "не успел".
Вообще я иногда тестирую свои системы на realtime - как правило время реакции на прерывание - не хуже 15-20мкс на TNKernel на 48МГц SAM7. На LPC-ях пока не гонял, должно быть еще веселее.
И даже взял моду "сложные" прерывания (типа USB, EMAC) обрабатывать в отдельном высокоприоритетном потоке - время переключения считанные мкс, а структура программы становится линейной и упрощается чуть ли не в разы, на синхронизацию доступа к регистрам оборудования можно вообще забить.

[defunct]

ИМХО, для UART'а как раз он очень удобен.

+1 для TX бесспорно.
для RX куда приятнее побайтово, будь-то пакетный протокол или консоль с упр. символами.

А необходимость мгновенной реакции на прерывание не напрягает?

А зачем мгновенная реакция? Проц 55Mhz, частота прерываний uart'a at max - 11.52kHz (на 115200).

Вместо старого NXP лучше взять новый NXP, а не старый Atmel. О чем спорить-то?

В таком ключе пожалуй не о чем ;>

А вместо старого SAM'a, стоит ли брать новый NXP?

[VslavX]

+1 для TX бесспорно.

Не-а, для сколько-нибудь сложных протоколов для TX тоже приятнее побайтово - не надо заводить отдельный буфер, копировать туда куски разных полей, потом вычислять сумму пакета за один проход.
А "побайтово" - генерируешь многие куски пакета "на лету" и вычисление суммы "размазывается" по времени. Реализация "моего" протокола без PDC мне больше понравилась. Хотя - "случаи - они разные бывают".

[aaarrr]

А зачем мгновенная реакция? Проц 55Mhz, частота прерываний uart'a at max - 11.52kHz (на 115200).

Ну, в основном их заводят на 48MHz. И UART бывает не только на 115200, особенно если это RS-485.

А вместо старого SAM'a, стоит ли брать новый NXP?

ИМХО, стоит.

[defunct]

Не-а, для сколько-нибудь сложных протоколов для TX тоже приятнее побайтово - не надо заводить отдельный буфер, копировать туда куски разных полей, потом вычислять сумму пакета за один проход.

У меня обычно любой протокол сводится к
xx_SendPacket( U8 *pData, int size);
Просто и дубово, считать CS удобнее.
Заводить отдельный буфер не надо, можно использовать буфер принятого пакета для формирования отправляемого.

И UART бывает не только на 115200, особенно если это RS-485.

Угу, бывает и 9600 особенно 485.
Насчет же скоростей выше 115200, есть и более подходящие для этого интерфейсы (eth/usb)

[zltigo]

А вместо старого SAM'a, стоит ли брать новый NXP?

Без вариантов. На самом старом семействе типа LPC211x/22xx/210x там выбор может быть очень труден, для LPC213x/4x - ну только если чего-то типа I2S требуется, или совсем в масть что-то ложится. А на LPC23xx/24xx просто без вариантов. Тем более,что новые семейства дешевле и старых, и SAM7. http://mt-system.ru/index.php?store_search=lpc2&id=5