[DropDown 0]

Может у кого-нибудь есть ответы

 

1. Сколько реально получилось реализовать на нем кодеков G.723.1 (G.729A)

 

2. Сколько производительности жрет uCLinux на нем

[jojo 0]

Автекс грозится продать нам платы STAMP с БлэкФином. В ноябре посмотрим, что там за Линукс такой.

 

http://www.blackfin.org

http://blackfin.uclinux.org/frs/?group_id=7&release_id=90

[Slavik 0]

Не понимаю, зачем блекфину линукс-подобные системы. Для подобных вещей (портирования операционки для встраиваемых систем) наверное лучше использовать какие нибудь армы, амд, интелы, моторолы... А блекфин всётаки заточен под ЦОС.

[jojo 0]

Судя по информации от AD, блэкфин есть процессор как для DSP, так и для управления, с единым ядром.. а не многоядерный камень с DSP и RISC-ядрами.

 

http://www.analog.com/processors/processor...chOverview.html

 

А раз так, то если Линукс будет достаточно толково перенесен на Блэкфин, то почему бы и не юзать. Посмотрим.

[Slavik 0]

Ну во-первых есть модели с несколькими ядрами на борту (bf561), правда однотипными. А во-вторых, архитектура ядра блекфина заточена всётаки под DSP. А как проц общего назначения... наверное всётаки не то, есть наработанные решения на других, более подходящих чипах. Конечно в союзе с Intel AD пыталась сделать чтото более менее универсальное, так что, там где нужна RTOS и DSP - блекфин самое оно.

[olefil 0]

Могу ответить по второму варианту дофига жрет ucLinux, во всяком случае программных ресурсов на 100%, а по времени тоже немало. Учти что сохранение всех регистров при сменах контекста в процессорах DSP это давольно долгий и неприятный момент. Там хоть и одна команда для сохранения основных регистров но выполняется она дофига тактов. я думаю при нормальном подходе к программированию ты потеряешь 1-10% производительности все зависит от тебя самого

[vat 0]

А вообще стоит ли связываться с этим Стампом? Функции эмулятора он хоть какие-то поддерживает? Почему его разработчики противопоставляют его Ез-киту? Если собираешься делаешь на блэкфине не PDA, а однозадачный девайс, к тому же очень требовательный к ресурсам проца, то будет ли польза от стампа (на этапе разработки)? Не имея полноценного эмуля, а только ез-кит все-таки можно хотя бы вчерне проработать проект, а там уж и потратиться на ADDS-USB-ICE.

[procopus 0]

Кто-нибудь уже имеет опыт с этим STAMP-ом?

 

Как можно компилировать программы отдельно от сборки ядра? Я скопировал параметры компилятора, которые передаются при сборке образа, в результате исполняемый файл получился точно таким же, но при его запуске (гружу его отдельно по tftp) система падает, к сожалению сейчас не помню с какими сообщениями.

[jojo 0]

Я протрахался полдня с Линуксом и gcc для BF из комплекта STAMP.

Есть проблемы с компиляцией . Преодолимые, наверное. Но сейчас не хочется бороться.

 

Linux и uboot успешно собираются.

 

В итоге я выбрал VDSP, как средство написания программ. И EMU-AD для отладки. Все так, как с самого начала и предполагалось.

[fontp 0]

Может  у кого-нибудь есть ответы

  1.  Сколько реально получилось реализовать на нем кодеков G.723.1 (G.729A)

 

Есть немецкая компания которая продаёт это для BF. У них 25 Мипс на кодер+декодер смесь С+ассемблер G723.1. Я недавно портировал на BF С-код 723, писаный на TMS6x. Повозился месячишко с прагмами и получил 26 Мипс один только кодер, но исключительно на С(29 кодер+декодер). Там С на самом деле очень неплохо разбирается с циклами. От осведомленных людей слышал про 23-24 мипс ассемблерные реализации пока. Считайте - 600/25 = 24, 750/25 = 30

 

729AB получится понятное дело больше :laugh:

[DropDown 0]

хорошие показатели, стоит поработать. единственно - 600 в делителе - это МИПСы процессора или тактовая? Реально наверное надо рассчитывать на выполнение кода в SDRAM, внутренней маловато будет. Сколько тогда максимум МИПС от процессора можно получить (в процентах от тактовой)?

[DropDown 0]

Я протрахался полдня с Линуксом и gcc для BF из комплекта STAMP.

Есть проблемы с компиляцией . Преодолимые, наверное. Но сейчас не хочется бороться.

 

Linux и uboot успешно собираются.

 

В итоге я выбрал VDSP, как средство написания программ. И EMU-AD для отладки. Все так, как с самого начала и предполагалось.

<{POST_SNAPBACK}>

 

в расчете на свою операционку?

а порт действительно пока еще кривоват, но что можно требовать от версии "Beta-2". но всё таки запустили, cross под cygwin.

[jojo 0]

В итоге я выбрал VDSP, как средство написания программ. И EMU-AD для отладки. Все так, как с самого начала и предполагалось.

<{POST_SNAPBACK}>

 

в расчете на свою операционку?

<{POST_SNAPBACK}>

Нет, вовсе без операционки. У нас из задач - только цифровая фильтрация. Применение операционной системы не планируется, как и во всех остальных местных задачах.

[fontp 0]

хорошие показатели, стоит поработать. единственно - 600 в делителе - это МИПСы процессора или тактовая? Реально наверное надо рассчитывать на выполнение кода в SDRAM, внутренней маловато будет. Сколько тогда максимум МИПС от процессора можно получить (в процентах от тактовой)?

<{POST_SNAPBACK}>

 

в числителе 600 тактовая, да и в делителе такты, так называемые, MIPS

(а какие ещё MIPS можно привести для реализации на современном конвейерном DSP? все другие мипсы - или фантазии разработчика алгоритма или рекламный трюк маркетингового отдела корпорации-разработчика процессора, в данном случае AD. В первом случае не понятно как это измерить, во втором - рекламные МИПСы приводятся исключительно только для алгоритма фильтрации/свёртки/корреляции)

 

на BF533 внутренней RAM достаточно для всех внутренних переменных алгоритма. Ну если не пихать туда uLinux или поддержку сети. Переменным состояния канала совсем не обязательно размещаться во внутреннюю память.

 

Кстати по контексту этой и соседней темы. Если говорить о фильтрации, то этот C-компилятор даёт максимально возможную производительность - 2 мака на такт. Чтобы написать такой код на ассемблере - ещё надо постараться. Даже массив тапов С делает циклическим во внешнем цикле, т.е. адресуется циклически. Понятное дело как и все DSP и этот заточен на фильтрацию.

На других задачах эффективность не такая высокая, всё таки система инструкций не ортогональная, как у TMS6x. Но всё таки регистров много и компилер работает, это не ADSP21xx и тем более не tms54 где на С писать неуместно.

[procopus 0]

Я протрахался полдня с Линуксом и gcc для BF из комплекта STAMP.

Есть проблемы с компиляцией . Преодолимые, наверное. Но сейчас не хочется бороться.

да, там мэйкфайлы кривоваты, а в документации написано так, как должно быть, если бы они были нормальными.

Но все-равно, при сборке вместе с образом программа собираеться и работает, а отдельно - собирается и не работает. Я про особенности микроклинукса практически ничего не знаю, может там есть свои требования к компиляции программ отдельно от образа?