Как правильно фильтровать? Опции

[inventor]

Задача такая - у меня АЦП может работать только на минимальной частоте 1000 Гц.
мне нужны кратные частоты: 125, 250 и 500.
Получить их можно проведя децимацию, предварительно перед которой
отфильтровав все что выше чстоты найквиста.
т.е. для получения данных на частоте 500,
я запускаю измерения на 1000 Гц,
фильтрую все что выше 250
и беру каждый второй отсчет.
Не стал заморачиваться с фильтрами - смотрю они уже есть в армовсеом коде
(те у кого STM в папке SMSIS)
у меня процессор СС3200 - не нашел примеров именно для него,
пока взял библиотечку у STM - она подходит к техасу (ф-я void arm_fir_decimate_fast_q31(///)).
Есть несколько вопросов, у меня может быть от 1-го канала до 8-ми,
вот как их всех одновременно фильтровать?
Код, который делает АРМ я так понимаю УЖЕ оптимизирован
по скорости, объему и прочему, сокращено количество циклов и всяких MAC операций.
как сделать "нормальную" фильтрацию одновременно всех 8-ми каналов,
и сколько навскидку времени уйдет на вызов функции фильтрации
т.е. переписать саму функцию фильтрации, чтобы использовать только 1 функцию
вместо идкущих подряд 8 и что то другое.
у кого какие мысли?

[AlexandrY]

Код, который делает АРМ я так понимаю УЖЕ оптимизирован
по скорости, объему и прочему, сокращено количество циклов и всяких MAC операций.

Не видно чтобы там код был оптимизирован. Он же на C-и написан. Там оптимизацию еще делать и делать.

Сначала надо избавится от передачи аргументов по указателям. Лучше вообще аргументы сделать статическими переменными. Автоматные переменные тоже делаем статическими.
Потом развернуть циклы, длина фильтра известна заранее, значит убираем ее из аргументов.
Выравниваем функцию в памяти, выравниваем данные в памяти. Избавляемся от копирования коэффициентов.
Делаем функцию инлайновой.

Ну и наконец компилируем все в IAR. Получим еще с несколько десятков процентов приращения производительности.

[SasaVitebsk]

Не видно чтобы там код был оптимизирован. Он же на C-и написан. Там оптимизацию еще делать и делать.
Сначала надо избавится от передачи аргументов по указателям. Лучше вообще аргументы сделать статическими переменными. Автоматные переменные тоже делаем статическими.
Потом развернуть циклы, длина фильтра известна заранее, значит убираем ее из аргументов.
Выравниваем функцию в памяти, выравниваем данные в памяти. Избавляемся от копирования коэффициентов.
Делаем функцию инлайновой.

Ну и наконец компилируем все в IAR. Получим еще с несколько десятков процентов приращения производительности.

Вот именно. Как по мне, проблема не в том, что "на С написано", а в том, что они данные под свою задачу оптимизировали. А в реальном проекте данные поступают в зависимости от способа их получения.
По поводу целочисленных фильтров - зависит от числа значащих разрядов, при обработке, от разрядности входных данных, от формы и зашумлённости входного сигнала.
Я себе делаю мат модель, имитирую входной сигнал, зашумляю его, потом дискретезирую его (имитирую АЦП) а потом прогоняю своей прогой и так вылизываю алгоритм. Порой, всё равно на реальном объекте нюансы возникают, но, тем не менее, удаётся сэкономить время на отладке в разы.
На мат моделе вылазят разные штуки, важные для понимания. Так, к примеру, столкнулся в последней задаче, что результат обработки (декодирование у меня было) сильно зависел от стабильности амплитуды полезного сигнала. Пришлось ввести АРУ. Сделал 2 варианта - программный и аппаратный. Результат практически идентичный, хотя, по идее аппаратный должен быть эффективнее, так как повышает число значащих разрядов.
И вообще. На таких задачах, как я убедился, самое главное - возможность максимально точно сымитировать входное воздествие.