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

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

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

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

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

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

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


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

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

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


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

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


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


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


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

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

Да нормальные там средства - вряд ли хуже, чем для ARM-а.

Вообще, по-моему, пересылка "периферия-периферия" требуется редко. Мне за всё время трудовой деятельности такой режим ни разу не понадобился.

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


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


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

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

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

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

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

Полностью поддерживаю Stanislav и mse. Всё правильно сказано. Но тенденция производителей процессоров такова, что "фишки", присущие исключительно dsp, сейчас есть и в других процессорах и контроллерах. Например, однотактная команда умножения 2х операндов, как минимум 16 бит, с последующим накоплением результата в 40, 48 и более битном аккумуляторе есть и в dspic (насколько я зная), и в avr32 (это я точно знаю).

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

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

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


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

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

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

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

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


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

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

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