Может чего не понял (всю тему читать лень), но такие махинации со сдвигами (особенно если Х0 длиннее 8 бит, а контроллер не поддерживаем сдвиг на нужное число разрядов за раз) займут хучу тактов. Я бы делал проще сначала Х0 умножаем на 172, а потом откидываем один правый байт (т.е делим на 256), итого получаем коэффициент 0,671875 т.е тот же самый, что и в Вашей формуле (Х0>>1+X0>>3+X0>>5+X0>>6).

Сообщение отредактировал Herz - Jan 10 2016, 10:35

Да вы немного не поняли, это только один коэффициент, так раскладываются все ну смотря какой фильтр, допустим 7 штук, потом раскрываем скобки,
потом упрощаем вынося за скобки, допустим вынесли за скобки >>2 И потом >>1.
Оставшееся раскладываем по сдвигам и записываем как
темр=все с 1 сдвигом
темр=все с 2 сдвигами
и т д
а потом
темр=темр + (что за скобкой1) >>2
темр=темр + (что за скобкой2) >>1
И наконец
темр=темр+целая часть

Хотя можно и немного по другому, записать
Итого все на сдвигах, да в том то и прикол что для приемлемой точности более 7 сдвигов то и не нужно
Там когда график строишь сразу округляешь чтобы поменьше сдвигов было, график то конечно похуже но на практите это даж не заметно
особо, а кода меньше и выполняется быстрее, я бы сказал красивое решение )

Хотя и Ваш вариант нада попробовать )))) и сравнить ))))

Сообщение отредактировал Herz - Jan 10 2016, 10:35

Ну мой вариант это тоже по сути сдвиг максимум на 8 разрядов. Только я снова Вас спрашиваю, сколько тактов уходит на сдвиг на 7 бит? Или Вы не оцениваете вычислительные затраты в тактах, тогда о какой эффективности алгоритма идет речь? Непонятно.
Кода меньше, чем где?

ДЛя avr один сдвиг в право один такт (LSR, Logical Shift Right (asm)), если семь сдвигов то семь тактов, не считая временных буферов для X,Y.
Хотя и это можно посчитать

А если округлять то вообще не более 4-х тактов выходит на фильтр )
Правда там еще сложения есть, в итоге вместе с буфером больше конечно будет
А вообще на ПЛИС это реализуется похоже еще интереснее ....

Сообщение отредактировал RedD - Jan 10 2016, 14:27

Кода меньше если округлять с подбором, визуально контролируя АЧХ.
Допустим если округлять до двух знаков да еще с подбором на мин количество сдвигов, то и сдвигов меньше и слагаемых меньше,
а результат будет чуть чуть похуже, а на практике и не заметен вообще, ну это если сделать измерения ....

Оно конечно когда там полноценный DSP или STM то можно и не заморачиваться и делать по полной программе, а на avr так не получится, там каждый такт на счету )

Сообщение отредактировал RedD - Jan 10 2016, 12:54

С отрицательными числами тоже? (извините, плохо знаю AVR)
И потом нужно еще принимать во внимание разрядность исходных данных. Всё хорошо когда они 8-битные, но сейчас даже самый плохенький АЦП в контроллере уже имеет разрядность 10+, так что это уже 2 байта.
И потом, если Вы вдруг решите изменить частоту среза фильтра это же все коэффициенты и их группировки нужно пересчитывать (и возможно вводить новые сдвиги). Это весь текст ЦФ надо править.

Все ответы здесь ....
https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%...%BA%D0%BE%D0%B9

В том числе и алгоритм, это всего лишь ЦОС, если посмотреть на схему и алгоритм то один в один, остальное тоже там, обычный институтский курс

Сообщение отредактировал RedD - Jan 10 2016, 19:27

А вообще меня интересовала практическая реализация вот этого вот
Трехполосный эквалайзер + компрессор в полосе 0,3 - 3,4 кГц.
На маломощном avr )

Сообщение отредактировал RedD - Jan 11 2016, 05:42

Вы не поняли, я про то, что изменение даже одного коэффициента влечет переписывание алгоритма обработки в целом (число сдвигов, группировки по сдвигам и т.д.)
Про ЦФ я кое что знаю, первый фильтр я написал еще когда учился в 6 классе , не совсем фильтр конечно, а систему разностных уравнений для получения эффекта вращающихся галактик, но не суть. Писалось это на БК0010, с его быстродействием 300тыс.оп./cек и работало в реальном времени. К слову всё делалось безо всяких википедий и учебников
Раньше это делалось чисто аналоговым путем (обычный АРУ на пиковом детекторе) безо всяких процессоров, в чем преимущество цифрового метода?
интересно бы еще узнать мнение целевой аудитории.

Ну то что я хотел сделать я почти сделал )


На Ваши вопросы
1. То не вижу разницы в том сколько двигать 8 16 32, почему ?
Ну хотя бы потому что под 16 бит АЦП и МК нужен 16 бит и т д иначе просто глупость получается.
2. Насчет отрицательных не думал, нужно будет че нить придумаем )

Ну в Atmege ядро вроде бы 8-битное. Если речь уже не об atmege, то и сложности с группировкой сдвиговых операций наверно смысла не имеют? В том же кортексе сдвиг на нужное число бит (арифметический, т.е с учетом знака) делается одной инструкцией ASR.

Что Вы имеете под группировкой ?

Про знак .....


С АЦП не может придти отрицательное значение только положительные ....
с ними и работаем, для 8 битного АЦП 0-255, для 10 битного 0-1023

Если про это то

Си
temp=temp-x2>>2 => temp=temp-(x2)>>2,

Да и то только для наглядности, приоритет сдвига выше чем сложение. Сдвиг в 3 группе, сложение в 5 пятой группе приоритетов )

ASM
temp=r20,
ldi r0,x2,
lsr r0,
sub temp,r0

Сообщение отредактировал RedD - Jan 11 2016, 15:52

Ваши же слова:


Ага, а усиление как делать будем? Допустим нужно будет усилить какието полосы частот, а какието ослабить -подумайте что будет если просто поделить диапазон 0-255 на N.
(подсказка: Ваш сигнал всегда содержит (бесполезную)постоянную составляющую, которая также будет усиливаться/ослабляться вместе с (полезной) переменной)

Про усиление или ослабление я Вас понял, но дело даже не в постоянной составляющей, например
С АЦП прищло 10, усиливаем в два раза, 10*2=20 но дело в том что усиливаем только положительную полу волну, а отрицательную наоборот ослабляем, и усиление не то, и сигнал искажен.

Делаем смещение на 128 при (256, 8 бит) пришло 10 ушло 20, пришло -10 ушло -20.

В общем то дельное замечание

Но и сигнал тогда на вход двухполярный нужен, операционник с двуполярным питанием, как то так, ну ессно смещение в половину AREF,

Сообщение отредактировал RedD - Jan 11 2016, 18:37