Перейти к содержанию
    

Как следует тестировать программу КИХ фильтра?

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

 

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

 

Что было сделано:

- до того , как заставил фильтр работать, посидел с пошаговой отладкой, исправил баги.

- затем подал тестовые сигналы - с Матлабом есть на глаз сходства =)

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

 

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

 

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

FIR_filter_Testing_Debugging.pdf

Изменено пользователем beaRTS

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

выполняется. На картинке доказательство.

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

 

 

а вообще, как тестировать ЦОС модули, ну, или просто ПО, например, систему АРУ цифровую (которая управляет RF-усилителями на плате).

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

 

есть TDD, (не погружался)

есть Google C++ Mocking Framework (тоже только слышал пока что)

 

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

post-69111-1355307580_thumb.png

Изменено пользователем beaRTS

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Ну, например, есть у меня отладочная плата EzDsp TMS320F28335. а делать плату приборчика своего нет желания, хоть и радиотракт отмакетирован и вылизан. Не хочу просто время тратить, по максимуму хочу ЦОС и программку на С++ замутить (тем самым прокачать скилы), пока предприятие до конца не развалили... да искать себе применение по прокаченным навыкам.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а вот как-нибудь АРУ, например, можно проверить без реальной платы устройства???

Вы входное воздействие как-то формируете? Если да, то и воздействовать на него можно:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Вы входное воздействие как-то формируете? Если да, то и воздействовать на него можно:

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

просто не думал еще. на данном этапе понимания, все ПО разбил пока на части, которые - думается - вполне можно делать по отдельности:

- система АРУ (цифровая часть, которая через ЦАПы управляет аналоговой частью АРУ)

- цифровой (скорее) синхронный детектор

- ну всякие интерфейсные функции по работе с RS232, SPI

- работа с "внешним миром": LCD, клавиатура, и т.д...

Пока взялся за детектор, т.к. на уровне детектированного сигнала будет работать та же АРУ (как - пока смутно представляю )

 

 

 

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

 

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

а так просто хотелось узнать про полезность скриптовых языков.

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

Изменено пользователем beaRTS

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

post-19294-1355322926_thumb.jpg

post-19294-1355322938_thumb.jpg

post-19294-1355322946_thumb.jpg

post-19294-1355322953_thumb.jpg

post-19294-1355323021_thumb.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

у 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...