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

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

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

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

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

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

Осталось проверить децимацию

выполняется. На картинке доказательство.
Да и в пошаговой отладке специально акцентировал на этом внимание - каждые М-раз (М-коэфф децимации) заходил в нужную ветку if().


а вообще, как тестировать ЦОС модули, ну, или просто ПО, например, систему АРУ цифровую (которая управляет RF-усилителями на плате).
Стоит для этого скриптовый язык углублять, например, Питон, чтобы писать какие-нибудь скрипты для входных воздействий и скрипты для обработки выхода модуля в удобочитаемую форму ??? и как вообще (через встраивание проги на С++ в Питон или ....??) и для чего делается связка скриптового языка + компилируемый (С++)?

есть TDD, (не погружался)
есть Google C++ Mocking Framework (тоже только слышал пока что)

что хорошо, а что плохо?

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

Либо на железе. Либо должна быть модель этого железа. Google C++ Mocking Framework для этого не нужен

"Либо должна быть модель этого железа." что значит модель железа?? это типа, как в Code composer studio есть эмулятор их процессоров ???

Ну, например, есть у меня отладочная плата EzDsp TMS320F28335. а делать плату приборчика своего нет желания, хоть и радиотракт отмакетирован и вылизан. Не хочу просто время тратить, по максимуму хочу ЦОС и программку на С++ замутить (тем самым прокачать скилы), пока предприятие до конца не развалили... да искать себе применение по прокаченным навыкам.
Так вот. ПОнятно что ЦОС могу и на отладочной плате проверить: тот же цифровой детектор доделать поэтапно... а вот как-нибудь АРУ, например, можно проверить без реальной платы устройства??? Отсюда вопрос про скрипты и возник. Может быть, не на целевой платформе, так на Писюке ??

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

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

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

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


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





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

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

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

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


печаль несусветная..
"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