Как следует тестировать программу КИХ фильтра?, Code Composer Studio v3.3 + MatLab/Simulink + TMS320F28335 Опции

[beaRTS]

Недавно осилил КИХ-фильтр. Он выполняет сразу и децимацию (т.е. лишние выходные отсчеты не высчитывает => соответствующим образом посчитаны требования к фильтру).

Как следует поступать, чтобы проверить правильность его работы?

Что было сделано:
- до того , как заставил фильтр работать, посидел с пошаговой отладкой, исправил баги.
- затем подал тестовые сигналы - с Матлабом есть на глаз сходства =)
- этого стало мало, решил подать ступенчатую функцию Хэвисайда (переходная характеристика) и дельта-функцию Дирака (импульсная х-ка). Результаты сравнил с Матлабом (FDA tool). ах, да... тут я коэффициент децимации установил в 1 (чтоб фильтр не прореживал выходные отсчеты) - а так, он был равен 10.

что-то еще надо??? подскажите =). Или можно ехать дальше?

прикрепляю отчетный документик. ссылки кликабельны (это если качество картинок не нравятся).

Сообщение отредактировал beaRTS - Dec 12 2012, 08:49

Прикрепленные файлы

 FIR_filter_Testing_Debugging.pdf ( 1.4 мегабайт ) Кол-во скачиваний: 63

 

[DRUID3]

На скриптовом языке все быстро пишется. Формировать последовательности, проверять валидность алгоритмов - самое то, ГУИ быстренько "накидать". Для тестирования C-кода (без привязки к ЦОС) я так и не пробовал. вообще задачи софт-тестеров и разработчиков DSP-алгоритмов разные. Сам код на C в python просто так не вставишь, нужно немного переделать(а это оверхед). Хотя в NumPy вообще как-то C++ можно заюзать, но я так глубоко не копал. В SciLab можно библиотеки использовать.

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

[beaRTS]

Сам код на C в python просто так не вставишь, нужно немного переделать(а это оверхед).

ну, я просматривал оный вопрос. И правда, самый гемор со вставкой Питона в С/С++. Легче С/С++ в Питон приделать.

Вы входное воздействие как-то формируете? Если да, то и воздействовать на него можно:
Увых(АРУ)=Увх*f(АРУ);

просто не думал еще. на данном этапе понимания, все ПО разбил пока на части, которые - думается - вполне можно делать по отдельности:
- система АРУ (цифровая часть, которая через ЦАПы управляет аналоговой частью АРУ)
- цифровой (скорее) синхронный детектор
- ну всякие интерфейсные функции по работе с RS232, SPI
- работа с "внешним миром": LCD, клавиатура, и т.д...
Пока взялся за детектор, т.к. на уровне детектированного сигнала будет работать та же АРУ (как - пока смутно представляю )

Увых(АРУ)=Увх*f(АРУ);

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

Сообщение отредактировал beaRTS - Dec 12 2012, 14:38

[DRUID3]

ну, я просматривал оный вопрос. И правда, самый гемор со вставкой Питона в С/С++. Легче С/С++ в Питон приделать.

...не в том дело, что куда сложно вделать, а в том что у них совсем разная типизация и там можно наломать дров. Что-бы подключить C-шную библиотеку к пайтону нужен немалый изврат и смысл всей затеи теряется если нет целей просто "ускорить" исполнение скрипта на PC.

Эскизы прикрепленных изображений

 

[beaRTS]

...не в том дело, что ...

все - Вы спалились =) теперь знаю кого мучить в нужное время по поводу Питошки =).

у TI есть RTDX технология для реал тайма, но еще не осваивал.

печаль несусветная..
"As of 6/24/2010 RTDX is no longer supported. Alternative transports should be considered for the acquision of data, such as serial ports and ethernet. If you are currently using the technology and have no issues, there is no need to change. However, no action will be taken for support inqueries." (с) ссылка ндааа

Сообщение отредактировал beaRTS - Dec 12 2012, 15:38