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).


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