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 ничего более не было доступно. Но это лишние телодвижения, причём ещё и аппаратные.

[dxp]

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

Про компиляторы уже сказали. Их три штуки, все достойные. Есть бесплатный gcc, на котором сидит прилично разработчиков (blackfin.uclinux.org).

Что касается IDE, то оболочки, как правило, почти везде если не сказать отстойные, то уж всяко не дотягивающие до возможностей связки "программерский редактор+система сборки". В VisualDSP++ оболочка вполне сносная, ординарная. НО! Там есть очень классная вещь - СОМ-сервер! Это позоволяет писать сторонние программы для управления функциями оболочки и отладкой (начиная от руления дебаг-сессиями и заканчивая расстановкой брейкпоинтов и прочим - словом, все, что доступно из оболочки). Язык реализации при этом может быть совершенно любым - компилируемым или скриптовым, я пользовался С++ и Python. В частности, на Питоне написан скрипт, реализующий программирование флеши: схема обычаная - сначала грузим драйвер-программатор, выводим его в рабочую точку, далее грузим в буфер кусок кода для флеши, затем даем команду прошить его; далее следующий кусок, и т.д. Запускать скрипт можно хоть из редактора, хоть из командной строки, хоть из консоли оболочки.

Аналогичным путем можно автоматизировать любой процесс, связанный с отладкой и доступом к потрохам процессора. Например, автоматизировать процесс сбора каких-либо данных на целевой плате с последующим сохранением их на РС. И т.д. Тут только фантазия органичивает.

Ничего подобного нет ни в популярном IAR'е, ни во многих других оболочках. Т.ч. с программными средствами там все более-менее в порядке, получше, чем у многих, как видите. Самый большой недостаток по средствам разработки - это высокая цена на эмуляторы. Ситуацию в значительной мере улучшает отечественный EMU-AD, но и он тоже недешев.

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

Это говорит лишь о том, что uCOS - не самая популярная ОС для АДшных процов.