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 рублей дороговато.

[Stanislav]

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

Простите, а какой ADSP имеется в виду?
Если юзать ADSP-BF, то подобная пересылка сожрёт всего единицы процентов ресурса - контроллер DMA там могущественный.
Вообще, по возможностям ввода-вывода BF с ARM-ами (любыми) сравнивать нельзя - они здесь в разных весовых категориях.

Сообщение отредактировал Stanislav - Apr 16 2007, 22:22

[Tahoe]

Если юзать ADSP-BF, то подобная пересылка сожрёт всего единицы процентов ресурса - контроллер DMA там могущественный.

А чем он лучше АРМовского? Я просто не в курсе. Ну например, может он в БФ умеет пересылать периферия<=>периферия?

В Атмеловском АРМе DMA имхо вполне достойный. Конечно это не прям целый event manager, как в TMS-ах каких-то я видел, но всё же.

[Stanislav]

А чем он лучше АРМовского? Я просто не в курсе. Ну например, может он в БФ умеет пересылать периферия<=>периферия?

Нет, не может. Но память BF является многопортовой по множеству 4К блоков. Если один из блоков использовать в качестве промежуточного буфера для DMA пересылок, stall-ов ядра возникать не будет.
DMA контроллер BF - это, по сути, процессор в процессоре. Имеет большое число (12 периферия-память и 2 память-память; в новых генерациях даже больше, вроде) каналов, каждый из которых может выполнять свою "программу", записанную в памяти, без участия ядра. Подробнее можно почитать в Hardware Reference Manual.
К сожалению, систему DMA процессоров ARM с 9-м и 11-м ядром я не изучал - работал только с 7-ми. Там всё плохо по сравнению с DSP.

...В Атмеловском АРМе DMA имхо вполне достойный. Конечно это не прям целый event manager, как в TMS-ах каких-то я видел, но всё же.

Да, возможно. В новых генерациях процессоров, похоже, этому уделили серьёзное внимание. И всё же, недостатки архитектуры при этом должны здорово сказываться: конфликты DMA каналов друг с другом и ядром будут иметь место (память-то одна на всех), что отнимет значительную часть вычислительного ресурса. Правда, здесь могу и ошибаться: возможно, в каких-то ARM-based микроконтроллерах предусмотрено разделение DMA потоков, но мне такие неизвестны.
Во всяком случае, контроллеры DMA, как и прочая периферия, не имеют прямого отношения к архитектуре ядра, а являются самостоятельными устройствами, которыми каждый производитель старается оснастить свои произведения.
С TMS я знаком мало, но там, по-моему, контроллеры DMA тоже на высоте - положение обязывает.

[Tahoe]

DMA контроллер BF - это, по сути, процессор в процессоре. Имеет большое число (12 периферия-память и 2 память-память; в новых генерациях даже больше, вроде) каналов, каждый из которых может выполнять свою "программу", записанную в памяти, без участия ядра.

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

Да, возможно. В новых генерациях процессоров, похоже, этому уделили серьёзное внимание. И всё же, недостатки архитектуры при этом должны здорово сказываться: конфликты DMA каналов друг с другом и ядром будут иметь место (память-то одна на всех), что отнимет значительную часть вычислительного ресурса.

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

И насчёт конфликтов DMA каналов друг с другом я не понял. Речь о том, что они все вместе АМБУ насилуют? Потому что в памяти им особо конфликтовать негде. Буферы же разные. Ну либо пинг-понг. Благо у Атмела это предусмотрено. Т.е. в DMA можно зарядить одновременно буферы и для текущего, и для следующего пакетов.

Чессговоря я никогда особо не страдал от отсутствия двухпортовой памяти. Вот ФИФО штука полезная. А дуал-порт на борту...


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