КИХ-фильтрация, на базе ADSP-BF533 Опции

[evil_laugh]

Доброго всем времени суток.

Вопрос больше по примитивной арифметике. Делаю передискретизатор частоты. На входе - последовательность данных с АЦП, формат - беззнаковый 16 бит (16.0)

Есть рассчитанные коэффициенты имп. хар-ки КИХ-фильтра, по модулю не превышающие 1. Их думаю представить в формате 1.15 - 1 знаковый бит, 15 дробных, диапазон значений от -1 до (1-2^-15).

Задача - провести фильтрацию. Ну и впоследствии умножить всю выходную последовательность на целочисленный коэффициент интерполяции, опять же в формате 16.0.

Есть процессор ADSP-BF533 семейства Blackfin, на котором всё это надо реализовать. Имеет встроенный умножитель с накопителем, который умеет (как я понял) автоматически перемножать либо данные в формате 1.15, либо в формате 16.0. Оба формата для него стандартные.

У меня возникает закономерный вопрос: как совместить форматы данных коэффициентов и данных АЦП? Необходимо, как я понимаю, либо нормировать данные с АЦП (т. е. приводить их в формат 1.15), как написано в одной умной книжке, либо наоборот - коэффициенты приводить в 16.0, либо как-то иначе стыковать эти два формата. Если нормировать - то как перевести число из 16.0 без знака в 1.15 (со знаком)?

Необходимое условие реализации - только ассемблер, никаких Си и им подобных. В Си бы такого вопроса не возникло.

Если у кого-то есть любые идеи, как реализовать вычисления - я буду рад выслушать и научиться. В ЦОС я пока полный новичок, с арифметикой столкнулся только сейчас. В принципе приветствуются тапки, носки, помидоры, паяльники, карданы и вопли праведного гнева из серии "пойди диодиком помигай, нуб"

[stealth-coder]

Форматы 16.0 и 1.15 больше умозрительные, поэтому перевод из 16.0 в 1.15 выполняется логическим сдвигом вправо на 1 разряд, после сдвига старший бит (знаковый) всегда будет 0, т.е. число будет положительным и можно сказать: "теперь я интерпретирую эти числа как 1.15". Ну а дальше прогоняете операцию умножения-накопления, если коэффициенты в сумме дают 1, то переполнения результата быть не должно, надо только проверить, что не произойдет переполнения в процессе умножения-накопления, для этого надо загнать в фильтр отсчеты, имеющие максимальное значение и проконтролировать флаги переполнения аккумулятора (с AD BF533 не работал, но в AD TS101 это сделаеть можно) либо просто подумать, внимательно посмотрев на процесс умножения-накопления, в AD TS101, например, под переполнение в аккумуляторе есть дополнительные 8 бит, т.е. переполнения гарантированно не будет, если длина фильтра будет меньше 256.

[stealth-coder]

Форматы 16.0 и 1.15 больше умозрительные, поэтому перевод из 16.0 в 1.15 выполняется логическим сдвигом вправо на 1 разряд, после сдвига старший бит (знаковый) всегда будет 0, т.е. число будет положительным и можно сказать: "теперь я интерпретирую эти числа как 1.15". Ну а дальше прогоняете операцию умножения-накопления, если коэффициенты в сумме дают 1, то переполнения результата быть не должно, надо только проверить, что не произойдет переполнения в процессе умножения-накопления, для этого надо загнать в фильтр отсчеты, имеющие максимальное значение и проконтролировать флаги переполнения аккумулятора (с AD BF533 не работал, но в AD TS101 это сделаеть можно) либо просто подумать, внимательно посмотрев на процесс умножения-накопления, в AD TS101, например, под переполнение в аккумуляторе есть дополнительные 8 бит, т.е. переполнения гарантированно не будет, если длина фильтра будет меньше 256.

Извините, немножко ввел в заблуждение, почему-то утром в понедельник решив, что 16.0 это БЕЗЗНАКОВОЕ целое. Скорее всего это, конечно же, обычное 16-битное ЗНАКОВОЕ целое, просто в документации на процессоры в таких случаях пишут просто "int". Перевод из int16 в fract 1.15 чисто умозрительный и не требует каких-либо действий. Разница начинает появляться в представлении РЕЗУЛЬТАТА каких-либо действий в зависимости от конкретного процессора.