ADSP2181 v/s AT91SAM7S64 Опции

[Stas633]

Не имея опыта работы ни с тем ни с другим, хочу узнать ваше мнение.

Насколько сопоставимы (если такое сравнение вообще возможно) эти МП по производительности при обработке "сигналов"? В частности - БПФ.

И вообще почему МП называется "сигнальным"? Если из-за "оптимизации для обработки", то в чём эта оптимизация выражается? (если только (для21хх) в наличии 40 битного регистра для хранения результата умножения 16-битных множителей... )

В общем, помогите утвердится во мнении, что ARM7 "круче" ADSP21хх.

Известно, что при примерно одинаковой стоимости:
ADSP - AT91
16р - 32р(16)
ПДП - ПДП
нет - USB,UART,АЦП....
80kSRAM - 16k...
... ну и д.т.

[Dopler]

И еще в поддержку Stanislav'а и ADSP.

Только что была задача - необходимо принимать SPI на частоте 50 МГЦ и выдавать через второй SPI. ADSP c этим справится легко, достаточно адекватно настроить автобуфферизацию у SPORT. Решили сделать на SAM7x256, используя DMA. Так вот, на такой частоте тактов SAM не работает вообще, при тактах 25 МГЦ работает еле-еле со сбоями.

У BF единственная проблема - довольно трудно поднять разработку с нуля. Отладочные средства стоят дорого, про студию я вообще молчу. Да и корпус BGA в нашем захолустье применять проблематично. Но платиь за ADSP-2188 1500 рублей дороговато.

[mse]

Отладочные средства стоят дорого, про студию я вообще молчу. Да и корпус BGA в нашем захолустье применять проблематично. Но платиь за ADSP-2188 1500 рублей дороговато.

Какое-то у вас захолустное захолустье. 1500р за ДСП. Это если в милитари чтоль? Типичный БФ млачшенький $10-12. Это 800Мгц, кажысь. Или в каких попугаях они их нормируют...

[dxp]

Типичный БФ млачшенький $10-12. Это 800Мгц, кажысь. Или в каких попугаях они их нормируют...

Не, там 400 МГц на ядре (для TQFP), а 800 - это ММАС, соответственно. Максимальная же тактовая у финов - 750 МГц, но это уже глубокое BGA.

Понятно. Т.е. примерно то же, что event-manager у TI.

Нет, насколько мне известно. Event Manager у того же TMS320F28xx - это блок timer-based периферии, способный генерировать множество ШИМ (в том числе и 3-фазный синхронный), работать с квадратурными энкодерами и прочее подобное. У Blackfin'а DMA - это автомат пересылки данных, т.е. это совсем другое.

Чессговоря не понял почему. Т.е. что значит "значительную часть"? Например по прерыванию зарядить DMA, указав ему пойнтер на буфер и сколько слать. Если буфер разумного размера, ну хотя бы 0,5-1 Кслово, то вряд ли можно назвать редкие подёргивания ядра "значительным отъёмом ресурса".

У Blackfin'а DMA позволяет не просто переслать что-то куда-то, а запрограммировать целую цепочку подобных действий. Это так называемый Descriptor-based режим. Т.е. режим работы контроллера DMA можно настроить не только с помощью прямой записи в регистры, но с помощью дескриптора. Дескриптор - это область ОЗУ, где прописаны параметры работы канала DMA: стартовый адрес, количество слов, размер слов, 1-D или 2-D пересылки (для памяти) и т.д., а также адерес следующего дескриптора. Таким образом, можно соорудить целую цепочку дескрипторов и контроллер DMA будет по окончании одной пересылки выполнянять следующюю пока не дойдет до конца цепочки. Можно цепочку закольцевать, тогда он будет работать по кругу. Т.е., хотя прямой пересылки "периферия-периферия" и нет, но можно это организовать через буфер ОЗУ (что, имхо, куда более правильно и гибко)

Кстати, непосредственно по теме ветки. Неплохо бы ещё упомянуть, про средства разработки. Вот уж где АД до АРМа как до луны, каким бы "нехорошим" ни был АРМ.

Что конкретно имеется в виду?

[Tahoe]

Нет, насколько мне известно. Event Manager у того же TMS320F28xx - это блок timer-based периферии, способный генерировать множество ШИМ (в том числе и 3-фазный синхронный), работать с квадратурными энкодерами и прочее подобное. У Blackfin'а DMA - это автомат пересылки данных, т.е. это совсем другое.

Насколько я помню, TI-шный event-manager позволял, например, опрашивать АЦП, с пересылкой сэмпла по DMA в буфер. Сейчас не полезу смотреть точнее. Речь про 24хх / 28хх камни.

У Blackfin'а DMA позволяет не просто переслать что-то куда-то, а запрограммировать целую цепочку подобных действий. Это так называемый Descriptor-based режим. ...

Неплохо. Это действительно помощнее будет.

Что конкретно имеется в виду?

Средства разработки - IDE, компиляторы, e.t.c.
Собсно насколько я знаю, нормальный Си появился только с БФ. До этого, понятие Си для ADSP было скорее для галочки. Но Си-компиллер для АД как был, так и остался только один. В отличии от АРМ.

Ну и куча других "мелочей". Например помню, когда я показал человеку uCOS-плугин, встроеный в IAR, он мне сильно позавидовал. Потому как кроме uCOS-view ему на его BF ничего более не было доступно. Но это лишние телодвижения, причём ещё и аппаратные.

[Stanislav]

Средства разработки - IDE, компиляторы, e.t.c.
Собсно насколько я знаю, нормальный Си появился только с БФ. До этого, понятие Си для ADSP было скорее для галочки. Но Си-компиллер для АД как был, так и остался только один. В отличии от АРМ.

Почему один? Есть Гринхилс и GCC, например. Да и вообще, какое это имеет значение, если компилер хороший?
А "нормальным" С для целочисленных процов стал действительно только после появления BF - семейство ADSP-21хх под ЯВУ просто не заточено (зато на АСМе там писать очень легко ). Для "плывучего" семейства ADSP-21ххх компилер С был всегда приличным, насколько мне известно.

[Tahoe]

семейство ADSP-21хх под ЯВУ просто не заточено (зато на АСМе там писать очень легко )

Да уж, легко. Мне тут третьего дня один умный человек рассказывал, про его му**ханья с банками и ещё кучку любопытностей о 21хх.

А насчёт Гринхиллс, там ихняя вроде только IDE. Сам компиллер всё тот же, АД-шный. Могу ошибаться. Просто в голове отложилось, что для АД реально есть только один компиллер. Как я понял, для реальной работы GCC не особо рассматривается. Т.е. теоретически можно, но это выйдет примерно то же, что попытаться перевести работу целой конторы с ненавистной Винды на Линукс.

[Stanislav]

Да уж, легко. Мне тут третьего дня один умный человек рассказывал, про его му**ханья с банками и ещё кучку любопытностей о 21хх.

Не знаю, отчего умному человеку пришлось м**хаться с банкам (регистров? памяти?) ADSP-21xx, если там нет вообще ничего непонятного уму простого обывателя?
Ограниченность адресного пространства - это, конечно, недостаток процессора, но для большинства чисто DSP-шных задач даже только внутренней памяти достаточно. От этого недостатка избавлен BF.

...А насчёт Гринхиллс, там ихняя вроде только IDE. Сам компиллер всё тот же, АД-шный. Могу ошибаться...

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

[Tahoe]

Не знаю, отчего умному человеку пришлось м**хаться с банкам (регистров? памяти?) ADSP-21xx, если там нет вообще ничего непонятного уму простого обывателя?

Несмотря на иронию, если сильно интересно, я уточню, как его увижу.
Но, что б понятно было сразу, это были не "вопли пионЭра о плохом компиляторе". Первый проект на 2181 он для меня делал ещё в 98-99 году. Прошлым летом он успешно портировал uCOS на BF ( из свежих, под который порта нет ).
Ха, вспомнил. На местный фтп мюкос 2,83 им и закачан. Там его автограф есть.

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

Имхо "банковать" вообще дурной тон, а в DSP это чистой воды преступление.

[Stanislav]

Несмотря на иронию, если сильно интересно, я уточню, как его увижу...

Попутно уточните, тяжело ли писать на АСМе 21хх (по сравнению с АРМом, например). Вопрос, напомню, состоит именно в этом.

[Tahoe]

Попутно уточните, тяжело ли писать на АСМе 21хх (по сравнению с АРМом, например). Вопрос, напомню, состоит именно в этом.

Абсолютно некорректная постановка вопроса. Для 21хх кроме АСМа ничего и нет ( Си на этих камнях не рассматриваем, по причине "жалкого подобия левой руки" ). Для АРМа же наоборот, это надо сильно захотеть, что бы делать проект на асме, а не на сях. Очевидно, имхо, что каким-бы супер-пупер удобным ни был асм, сравнивать удобство работы с сями... Ну это как сравнивать BF и ARM. Разные весовые категории.

[Stanislav]

Абсолютно некорректная постановка вопроса.
......................

При чём здесь всё это? Прочитайте свой пост #24, и поясните, пожалуйста, что Вы имели возразить против моего утверждения.

[Tahoe]

При чём здесь всё это? Прочитайте свой пост #24, и поясните, пожалуйста, что Вы имели возразить против моего утверждения.

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

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

[Stanislav]

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

Простите, но Вы этого в данном посте не писали, и я против этого не пытался возражать. Разговор был совсем о другом.

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

Главный минус ADSP-21xx - отсутствие поддержки со стороны изготовителя и высокая цена на приборы. Я уже писал об этом.

Простите за то,что встреваю в беседу. Но уж темы больно интересные.
По поводу ядер понятно. Конечно мне кажется глупо сравнивать ARM7(старое ядро) со сравнительно ноывм BF. Да и цель их создания различна. Правда непонятно и выражение, что специализированный БЛЕК ФИН вдруг делается ещё и универсальнее универсального АРМа.

А никто конкретно эти ядра и не сравнивал. Какому-то сравнению с ядром BF ещё поддаются архитектуры ARM9 и ARM11, хотя и они в несколько раз проигрывают BF в производительности. Для 7-го сравнение вообще безнадёжно...

...С DMA после всего этого я вообще в тупике. Какой бы волшебный он ни был непонятно как физически обратитья к разным адресам в одной памяти в одну единицу времени ?

Упрощённо: представьте, что у каждого 4К блока памяти есть своя шина адреса и шина данных. Если одновременно обращаться в разные блоки, конфликтов не будет.
Реально всё несколько хуже, но не сильно. За один такт ядра могут быть осуществлены вот такие пересылки данных (конечно, при условии, что буфера размещены в памяти "правильно"):

• Two 32-bit data loads

• One pipelined 32-bit data store

• One DMA I/O, up to 64 bits

• One 64-bit cache fill/victim access.

А то что АРМ имеет в себе многое, да ещё и выполняет за такт оно ясно и из названия ядра!!!!!!!!!
Всётаки RISC!!!!!!

А вот попробуйте поработать с этим РИСКом, и увидете, насколько далеко от реальности написанное Вами.

Но если задача, позволяет реализовать без ДСП - почему бы и нет?

Конечно, можно, и часто это оправданно (например, трудно представить себе DSP по цене в 2-3 доллара). Однако, в теме речь идёт о сравнении производительности двух архитектур на DSP-шных задачах. Думаю, теперь этот вопрос прояснён в достаточной мере.

2 Paramon
"Thumb Mode? про BF ничего незнаю."
Нет, не Thumb, а обыкновенные инструкции переменной длины (16, 32 или 64 бит). При этом шина данных памяти программ - 64-битная.