AlexZabr
-
Постов
900 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные AlexZabr
-
-
Скорее всего такой передачи данных нет. Требуется использование TLC файлов.
Спасибо.
А что за TLC файлы ?
-
а можно больше не писать таких говорящих самих за себя заглавий тем? а писать в строчке тема(как бы это странно не звучало /для некоторых посетителей форума/) - тему сообщения !!!??? по заглавию вашему посту самое место в "Общение на свободные темы"
:maniac: :bb-offtopic:
Согласен, сорри.
Поддался эмоциям... :)
-
Скорее всего где-то была определена функция fir1, перекрывшая стандартную.
Спасибо.
Вроде не помню что-бы перегружал fir1, но проверить думаю стоит.
Правда закрывал МАТЛАБ открывал заново не помогло. Clear All тоже не помогло (хотя и врядле помогло-бы оно ведь только переменные очищает)...
Как проверить переопределения функции ?
Спасибо.
-
Либо я вдруг чокнулся, либо мой МАТЛАБ "поехал"...
понадобился элементарный FIR (скажем low-pass), делаю как обычно:
b = fir1(35, 3000/22050); - скажем 35ого порядка, 3kHz cut-off
ожидаю ессно получить в векторе б 36 коеффициентов.
Вместо этого получаю бред какой-то:
b = 35.1360;
тоже-самое с любыми другими комбинациями FIRа...
не понимаю, что происходит...
давно с такими вещами работаю - проблем не было, а тут вдруг какой-то глюк...
Может кто в курсе что может быть с МАТЛАБом вдруг ?
P.S. делаю то-же самое, на том-же MATLABе на моем лэптопе - все нормально, коееифиенты получаю как положено...
Ничего не понимаю... :blink:
-
В посте много обсуждалось разных причин использования DSP процессороввместо GPU, но надо
добавить одну тоже немаловажную (в порядке самокритики) - лень разработчика :) . Освоив один камень и выловив его глюки, очень тяжело заставить себя перескочить на другое CPU. Программировал на 64х, а следующий проект на 8051, это как пересадка с формулы-1 на самокат, подсознательно ищешь причину взять побыстрее DSP и все за 2 дня закончить
.Да, это мне кажется весьма реально...увы.. :)
Тогда прймущество у того кто вначале осваивает более простые/дешовые процессоры, учиться укладыватся в как можно меньше ресурсов, а затем уже, по мере реальной надобности переходить на более серьезные "машинки". Тогда у опыт будет разносторонный может быть более подходящий для достижения лучшего price/performance в каждой кокретной апликации...
Все конечно IMHO...
Я вообще не привык к такому универсально-мощно-DSPшному подходу работая в соотв. индустрии у нас в стране (хотя я не DSPшник - я системщик). У нас обычно стараются подбирать типы/виды CPU под тип задач под конкретные апликации - все это с целью добиться price/performance. Обычно не стремятся к большим запасам производительности в плане "так, на всякий случай" когде не предполагается соотв. расширение прозводительности на тойьже базе hardware, ибо такой подход удорожает себестоимость (а значит и продажную стоимость что не есть хорошо).
С другой стороны у нас тоже свойственен подход к re-use даже там где это не оправвдано технически , но оправдано в плане time-to-market. Т.е. например в прошлых проэктах требующих больших вычислительных мощностей использовали мощные/относительно не дешевые DSP, новый-же проэкт не требует таких производительных мощностей, но все равно первым делом будут рассматрвиать вариант использования прошлого процессора к которому привыкли, на который у инженеров скопулся немалыйй опыт а значти реализуя на котором можно серьезно сократить time-to-market показатель, даже ежели ресуры этого процессора будут использованы всего на 30-40% в новом проэкте. Естественно, при условии что его себестоимость фирме не слишком высока относительно требований проэкта...
-
Ну да, это я и имел ввиду. Спасибо.
-
Ну если за ту-же цену, то логика есть. Мне казалось DSPшные процессоры в среднем дороже контроллеров схожих поколений...
Мне (в принципе в следствии отсутствия персонального опыта) казалось так-же что программирование DSP будет посложнее чем контроллера или процессора общего назначения.
Сейчас вот изучаю азы имплементации обрабоатки сигналов в среде TI с целью имплементации моего алгоритма определенной обработки аудио (фактически мой дипломный проэкт), вижу что пока вроде (на элементарном уровне) работа с кодом C и ассемблером - действительно не срашнее обычного контроллера/процессора общего назначения...
-
Я на форуме относительно новичок, да и с цифровой обработкой сигналов имею дело пока только в академически рамках, посему мое недоумение вполне может показаться наивным, но все таки...
Я обратил внимание многие на форумах тут озадачиваются подбором DSP процессоров для целей далеких от цифровой обработки сигналов как таковой. Я так понима вся сила и преймущества DSP процессоров в их специфике работы под задачи свойственные цифровой обработке сигналов, например наиболее употребимые вещи такие как цифровые фильтры (FIR, IIR), частотный анализ (DFT/FFT/SFFT), корреляции,
фильтр банки, специализированные виды обработки (например узкополосные фильтр банки с DWT и им подобные) и т.д.
Реализация этих вещей на практике сводится к очень большому числу однотипных математическхи операций которые часто съедают серьезные ресурсы (по скорости обработки например) у обычных процессоров, посему архитектура DSPшных процессоров заточена на такие цели. Наиболее распростарненный пример такого например специальные ассмблерные инструкции такие как MAC которые осуществляют наиболее употребимую в цифровой фильтрации, FFT и им подобным процедуру умножения и сложения за один такт и им подобные.
Однако я замечаю многие на форумах озадачиваются DSP процессорами для работ не имеющих отношения к DSP как таковой.
В чем причина ?
Мне кажется для многих вещей не имеющих отношения к обработке сигналов либо к другим тяжелым математическим работам подошел бы какой-нить контроллер - они весьма дешевы, доступны и достаточно легки в программировании...
-
Да, вполне вероятно что в недорогих мыльницах Кенон например предпочел дешевые CPU типа х86 или им подобные. Но их профи цифро-зеркалки и мыльницы высокого класса обычно идут с ихними propritary DSP заточенными под ихний image processing типа семейства DIGIC/DIGIC II.
Когда речь идет об камерах среднего и ниже ценового диапазона - там часто (на сегодняшний день) интересы удешевления (производства и потребительских цен) начинают серьезно превалировать над интересами качества, особенно модели производимые китайскими/тайванскими/корейскими sub-contractors (т.е. примерно 80% рынка недорогих цифро-мыльниц в целом). Там экономия в пару центов на BOM, производстве и других связанных затратах часто важнее чем 10-15% добавочного качества (например качества image processingа). А посему чем более интегрирован будет камерны процессор - тем выгодней для производителя в условиях очень жестокой рыночной конкуренции цен.
Тем более учитывая что уровень image processingа достигамеый в таких интегрированных чипах сегодня более чем неплох, хотя ессно будет уступать по возможностям специализированным, значительно более дорогим DSP под image processing. Думаю согласимся, что качесво картинок сегодня даже у относительно дешевых цифро-мыльниц весьма хорошее, скажем даже очень хорошее для нужд среднего потребителя - а это и есть 80-90% рынка. Остальные 10-20% готовы заплатить в 2,3,4,5 раз больше за те добавочные 10-25% качества которые дадут камеры высокого уровня построенные именно на качество.
-
Хмм, тут у меня есть зацепка: многие производители цифро-мыльниц среднего и дешового уровня используют (китайцы, корейцы, тайвань и т.д., некоторые японцы тоже) изпользуют в своих дизайнах специализированные цифро-камерные процессоры. Инфа ин первых рук... :)
Я до недавнего времени работал в Zoran Microelectronics которые одна из подразделений которой проэктирует main processor chip for digital cameras - т.е. специалиривоанный процессор (точнее поколения таковых) заточенный на цифро-камеры. Я работал именно в этом подразделении, но занимался не самим процессором а его системный board design (в teamе занимающимся этим).
Такого типа процессоры имеют потчи все функционально-электронные части встроенные в чип, т.е. на одном силиконе. Цорановские процессоры так и называются: COACH (Camera-On-A-Chip). Там в чипе есть куча цифровых и аналоговых блоков, таких как блоки управления питанием и потреблением, интерфейсные блоки с внешним миром (карточки памяти, опер. память, USB, и т.д. и т.п.), блоки интерфейса с видео/still сенсорами разных типов, с аудио (микрофоном) audio codec и конечно-же core процессора (может быть ARM например или другие), а то и 2 кора. Естественно, в камерах немало image processingа, нередко весьма тяжелого, но такого типа коры обычно справляются (ессно, с необходимыми ресурсами, все индивидуально).
Такого типа узко-специализированные процессоры в основном и идут в камеры среднего и мелкого пошиба которые мы и видим в магазинах. Ессно знаю конкретные фирмы (китайские, тайванские а так-же японские) цифро-мыльницы которых идут с Цорановксим чипом, назвать марки и модели не могу, сорри (подписан на это), но принцип думаю понятен. Немало камер такого разряда выпускается с Цорановскими чипами внутри, есть конечо-же и конкурирующие производители такого плана чипов (Тайванцы, Штаты).
Камеры высокого класса (профи и очень дорогие мыльницы от "китов" типа Кенона, Никона), часто идут со своими in-house чипами. Не знаю точно насчет Никона, но Кенон напримерсам разрабатывает свои процессоры для камер.
Саша
-
Опубликовано · Изменено пользователем Саша Z · Пожаловаться
Фотографы-любители среди нас (особенно die-hard дальномерщики) наверняка в курсе новой цифровой Лейки (М8). А в сочетаннии с нашим интересом DSP - думаю было-бы интересно изнать какой DSP выбрали инженеры Лейки для обработки сигнала (видимо image processing).
Так вот - там стоит Analog Dev. BlackFin, а для контроля таботы камеры (экспозиция, UI, управление затвором и т.д.) изпользуется контроллер М16С от Renesas.
Просто познавательно на каком DSP остановили свой выбор инженеры Лейки.
Саша
-
Мне не доводилось это делать, но когда рылся в техасовских доках, нашел, что в CCS есть целая библиотека для работы с вейвлет преобразованиями (функции реализованы на ассемблере, для вызова из C):
//------------
void IMG_wave_decom_one_dim(short *in_data, short *wksp, int *wavename, int length, int level )
Description
One dimensional wavelet pyramid decomposition. The wavelet filter coefficients are passed by the vector wavename. The length of the input vector should be divided by 2^level. The decomposition output is stored in the same vector of input. The IMG_wave_decom_one_dim function calls the decomInplace assembly function. Input and output data format is Q16.0.
//------------
void IMG_wave_decom_two_dim(short **image, short *wksp, int width, int height, int *wavename, int level );
Description
Two dimensional wavelet pyramid decomposition. The wavelet filter coefficients are passed by the vector wavename. The width and height of the image should be divided by 2^level. The decomposed image is stored in the same matrix of in_data. The IMG_wave_decom_two_dim function calls three assembly functions: decomInplace, col2row and decomCol. Input and output data format is Q16.0.
//------------
void IMG_wave_recon_one_dim(short *in_data, short *wksp, int *wavename, int length, int level );
Description
One dimensional wavelet pyramid reconstruction. The wavelet filter coefficients are passed by the vector wavename. The length of the input vector should be divided by 2^level. The reconstruction output is stored in the same vector of input. The IMG_wave_recon_one_dim function calls the reconInplace assembly function. Input and output data format is Q16.0.
//------------
void IMG_wave_recon_two_dim(short **image, short *wksp, int width, int height, int *wavename, int level );
Description
Two dimensional wavelet pyramid reconstruction. The wavelet filter coefficients are passed by the vector wavename. The width and height of the image should be divided by 2^level. The reconstructed image is stored in the same matrix of in_data. The IMG_wave_recon_two_dim function calls three assembly functions: decomInplace, col2row and decomCol. Input and output data format is Q16.0.
//------------
void IMG_wavep_decom_one_dim(short *in_data, short *wksp, int *wavename, int length, int level );
Description
One dimensional wavelet packet decomposition. The wavelet filter coefficients are passed by the vector wavename. The length of the input vector should be divided by 2^level. The decomposition output is stored in the same vector of input. The IMG_wavep_decom_one_dim function calls the decomInplace assembly function. Input and output data format is Q16.0.
//------------
И ещё какие-то. Берите хелп и смотрите. Там есть данные о производительности.
Большое спасибо, это уже что-то.
Буду рыться в хелпах и их онлайновких доках.
Еще раз премного благодарен,
Саша
-
Я тут потихоньку осваиваю азы имплементации алгоритмов обработки сигналов с прицелом на старый 16-битный fixed point DSP.
Сейчас поднял тему обмена данными между MATLABом и C кодом (написанным в CCS v.3.3).
Мне дали готовый проэкт состящий из сорса C и 2х ассемблерных вспомагательных сорсов, а так-же 2 MATLABовских файла (m-files). Задача проста - МАТЛАБ генерирует 100 samples синуса, эта data записывается в файл (из МАТЛАБа). Затем в С, читается файл, оперируется samplами синуса и результат сохраняется в выходной файл котрый может читаться МАТЛАБом.
Я так понимаю MATLAB оперирует numerical data в формате 32 бита floating point, так ? При сохранении в файл, читая его (в виде HEX значений) я вижу там хранение по байтовое, т.е. 100 samples синуса дали 400 байт в файле (каждое значение МАТЛАБовского синуса разбито на 4 отдельных, последовательно записанных в файле байта).
При чтении файла в C, вначале содержимое читается в массив типа int размера 400. Затем вызывается ассемблерная рутина которая как я вижу пакует по-байтовое содержимое массива в 16-битные значения в отдельный массив размера 200 значений. Затем данный массив в памяти читается в С в массив типа float размера 100 значений (т.е. как я понимаю каждые последовательные два 16-битных значения формируют цельное 32-битное значение типа float).
Затем, в коде С манипулируют значениями, после чего, во второй ассемблерной рутине, каждое значение обработанного массива разбивается на 4 бытовых значения записываемых в памяти которые затем в коде С читаются как массив 400 значений записываемых байтово в новый файл.
Этот новый файл может читаться МАТЛАБом как numerical data.
Все это до меня "дошло" изучая сорсы С и ассемблера (ну и МАТЛАБа ессно, но там все элементарно) и прогоняя проэкт (в CCS) в debuggerе.
Исходя из этого, сделал для себя выводы насчет которых хотел-бы слышать подтверждение либо опровержение с указанием правильного подхода.
Выводы:
1. МАТЛАБ оперирует с 32х битными значениями (что касается numerical data) в формате float.
2. При прямой записи в файл из МАТЛАБа, числа разбиваются побайтно, т.е. цельное значение в 32 бита разбивается на 4 отдельных, последовательно записываемых байта.
3. При необходимости чтения такого файла в C с последующей обработкой (т.е. мы знаем что в оригиналезначения 32х битные типа float), нужно предварительно скомпоновать их в 16-битные значение.
4. При чтении 16-битных данных в С (из памяти) в массив типа float - считываются 2 последовательных worda и принимаются как цельное 32х битное значение типа float.
Это есть рецепт построения правильного обмена информацией между МАТЛАБом и С когда применяются промежуточные файлы храниения числовой информации.
Это так ? Если не совсем (или совсем не так) - как именно ? Где я ошибаюсь в предположениях ?
Есть ли возможность обмена числовой информацией между МАТЛАБом и С (в CCS с ориентировкой на 16-битные DSP fixed point) напрямую через память, без применения промежуточных файлов ? Если да, то как ?
Заранее благодарен, Саша
-
Кому-нить из уважаемых форумчан доводилось имплементоривать filter bank на основе wavelet decomposition на конкретных DSP чипах ?
Интересует сложность имплементации, в плане требования к ресурсам процессора/памяти.
Пример: предполагаемый subband decomposition на 32 частотных полосы (5-и уровневый) посредством DWT (discrete wavelet transform).
Какие аспекты практической реализации на DSP чипах ? Какая сложность реализации (в плане коль-ва вычислений) ?
Мой алгоритм успользует все это, в МАТЛАБе все хорошо и весело ибо не в реальном времени и используем встроенный в МАТЛАб (точнее в DSP toolbox) DWT, но когда дело касается реализации а реальной hardware - подозреваю могут быть серьезные проблемы...
Спасибо, Саша
-
Оговорка: по части имплементации под DSP я новичок, посему заранее мои извинения за возможно примитивные вопросы.
Теперь к делу:
Есть определенный алгоритм обработки аудио сигнала, алгоритм стабилизирован и симулирован в Матлабе с DSP toolboxом). Теперь пришло время имплементации, платформа - TMS320C5402 DSK.
По первичным прикидкам, данный процессор не потянет имплементацию сего алгоритма в реальном времени, и даже post-processingе могут быть проблемы при имплементации алгоритма в его виде на данный момент (ввиду нехватки адресуемой процессором памяти).
Вся эта работа - мой дипломный проэкт на B.Sc.EE. В универе (в конкретной лабе) есть только данная платформа, посему и вынужден изголяться имплементацией на ней, других вариантов нет.
Цель задачи - не промышленная, просто показать разработанный алгоритм и его наметки реализации на DSP. Посему, и ввиду вышеизлоенного подумал о возможности имплеемнтации алгоритма на смешанной базе: MATLAB + Hardware. Т.е. основная рассчетно-интенсивная часть будет в Матлабе на PC, затем несколько кусков алгоритма должны бежать на DSP. Ессно, речь не идет о реальном времени, все будет в post-processing.
Это предусматривает обмен информацией между частью алгоритма в Матлабе и его частями в hardware с след. виде:
1.Начальная обработка сигнала в Матлабе, результат (вектора коеффициентов) и определенные части отцифрованного сигнала передаются на DSP (через цифровой интерфэйс DSK).
2. DSP прогоняет полученную data реализуя свою часть алгоритма, затем передает обработаные части сигнала обратно Матлабу по тому-же интерфэйсу.
3. Матлаб стыкует все части сигнала (свои и полученные с DSP) в единый сигнал (цифровой сигнал) который и есть output.
Вопрос таков: реально (если да то насколько сложно) состыковать в работе Матлаб с процессором в плане такого типа обработки сигнала (можно считать нет жестких требований real-timeа) ?
Если да, но как состыковывается таким образом сорсы Матлаба (скажем m-files) с сорсами в CCS v3.3
(С и ассемблерные сорсы) с целью совместной работы со взаимной передачей данных ?
Заранее благодарен, Саша
-
Спасибо всем, действительно как оказалось - все гениальное - просто...
-
Есть ли возможность запускать программу в CCS ver. 3.3 без подключенного борта ?
Пишу код под C5402 в недавно скаченной CCS 3.3. Я в этом новичок.
CCS сконфигурировал на С5402 Simulator.
Судя по описанию, для Runа программы (после успешного Build All ессно) - опязательно загрузить .out в подключенный борд (которого у меня пока нет) и тогда можно делать Run - будет бежать из процессора.
А что-же тогда симулятор ? Неужели нельзя запускать программы в режиме симуляции, т.е. без подключенного hardware ?
Если можно, то как ? МОжет нужно как-то еще сконфигурировать CCS ?
Спасибо, Саша
Почему DSP процессор для не DSP работы ?
в Сигнальные процессоры и их программирование - DSP
Опубликовано · Пожаловаться
Ну во первых начните пожалуй "price/performance - бред IMHO" ибо это ваше мнение, не более того.
Я говорю о реальности индустрии в которой 8 лет кручусь. Когда не говориться о продукции люксусного ранга - тут price/performance играет первостепенную роль. Ориентация на проэктируемую партию (те. кол-во) - это ессно часть фактора price/performance.
Я работал как системщик (т.е. board design) в и области проэктирования цельных систем и в области ASICs.
В псоледней идет борьба за каждый цент - если можно съэкономить цент без ощутомой потери качетсва/призводительности - за это горло перегрызут, ибо конкуренция задавит.
С другой стороны, как-то работал в фирме продукт которой была систем обработки видео в реальном времени, очень тяжелые алгоритмы, система раасчитана на работу в телестудиях во время вещания спортивных програм (клеила виртуальную рекламу на фубольные поля, тенисные корты и т.д.) - там требования по качетсву сигнала были очень жестокие (и без них не пустят ни в какую студию), посему не скупились на дорогую элементную базу и сам дизайн. Но там сама hardware было единично, там было борты с 6 дорогущими на то время SHARKs и т.д..