Для 8-разрядного входного числа и 8-разрядных коэффициентах размерности 8.8 хватит гарантированно. Можно проверить на вашей же программе. А промежуточные вычисления делать 24-битовыми. XX.XX * .NN = ZZ.ZZZZ

upd. добавил подчеркнутое

Ну, если это камень в огород автора той заметки на Easyelectronics, то отвечу. Автор пользуется описанным подходом с середины 80-х и обычно как раз в целочисленной арифметике. Так что эффект потери точности при делении ему известен. И он легко устраняется сохранением неделенного результата.
В обсуждении той заметки была приведена даже реализация фильтра на Си.

Увы, переделка статьи, в которой должен был быть учтен этот пробел, была отложена.
Так что спасибо за напоминание! Доработаем-с!

Даже с сохранением неделённого результата так

будет корректнее.

Да, конечно, симметричное округление. Это правильно.
Но я обычно в промежуточных вычислениях работаю с запасом по разрешающей способности. Поэтому там округлением не занимаюсь. А только в конце, может быть, проделаю такое добавление половинки единицы дискретности.
Например, с АЦП идет много разрядов, младшие пляшут (собсно, зачем и усредняем), мы пускаем все это в обработку, не заботясь о мелочи, полразряда. А когда уж на индикатор выводится значение, которое должно быть стабильным, которое имеет определенную дискретность (не взятую с потолка) - вот тогда и есть смысл прибавить половинку.

В статье поправил. Еще раз спасибо коллеге ReAl. Да, и оговорился там, что от диапазона входных величин x, Na и k зависит и выбор z. В указанном примере лучше сразу объявить long z. Что скажете?

Сообщение отредактировал drvlas - Sep 27 2012, 10:21

Скажу, что при равномерном распределении (k-1)-го разряда методическая погрешность (y = Na * z >> k) за N вызовов filter() составит N*(1<<(k-1))/2.

UPD: нет, меньше, но лень предел считать в уме.

Я тоже хочу сказать, что как бы ни были (при)увлекательны формулы и числа, надо сначала посмотреть на реальную правду в глазах.
Если имеется наводка, то от нее нужно избавляться в зародыше, чтобы потом не морочиться с числами.
Вот если есть наводка, а автор хочет измерять от нуля, то вблизи нуля никакие числовые фильтры не помогут.
И вблизи максимума... Поэтому нужно отфильтровать на входе аналоговым фильтром и сместить и сжать шкалу.

Например, берем скользящее среднее. Если встречаются помехи-импульсы относительно сигнала-нуля, они тоже усреднятся. Не вижу причин для беспокойства. Ну, приподнимется чуть-чуть результат. Так надо же соображать, чтобы диапазон измеряемого сигнала (вместе с помехами, мы же не детектор-выпрямитель проектируем) укладывался в диапазон АЦП.

И верно, и нет.
Да, нужно подходить комплексно и не стараться вытянуть ЦОС грубые недоработки в проектировании платы.
Нет, ибо с числами можно не морочиться, а значительно улучшить результаты. Весь мир так делает. Почему нам отказываться?

Давайте конкретнее.
Вблизи нуля помогут. Нужно правильно выбирать диапазон работы АЦП, вот и все. Впрочем, коллега ViKo уже сказал об этом.

Можно и аналогию из аналоговой схемотехники привести. Если помехи у нас есть ниже нуля скачут, то фильтром на ОУ, запитанным от положительного питания, мы их тоже не отфильтруем.

А применение rail to rail ОУ даст мне на 10 битном АЦП полный ноль и полные 5 v ? ( шаг АЦП 0,0048 v)

Сообщение отредактировал endasm - Sep 27 2012, 13:47

Да вот я как-то, пардон, комментарии читать начал, но далеко не зашёл :-)
«Увы, ... отложена» близко и понятно :-(

Этот фильтр дотягивать будет и (с учётом замечания по симметризации округления) явно лучше.
Только такое впечатление, что, в терминологии исходной заметки, в нём не Na должно быть, а Nb.
Точнее, и ни то, и ни другое, так как фильтр уже другой, но Nb (малое по сравнению с делителем) по смыслу ближе.
По крайней мере если брать по статье Na=248 (30-кратное превышение влияния фильтрованного значения перед новым отсчетом), то в этот фильтр никак нельзя 248 ставить, он с таким коэффициентом при ступеньке даже в сотни квантов в несколько прыжков выйдет на заданное значение, а не в многие десятки.


Смотрите документацию на ОУ. RR может считаться уже когда он, скажем, милливольт пятдесят или сто от шины работает. А не пять.
Да и свой сигнал до нуля и опорного я чтараюсь и не рассчитывать, у АЦП свои ошибки есть. Если надо, подставку небольшую делаю. В том числе чтобы шумы/наводки при ограничении об шину не давали смещение сигнала после фильтрации.

"но далеко не зашел" близко и понятно

Ай-ай-ай! Это была ошибка. Уже устранил. Огромное спасибо!

То есть, вместо хранения Y в форме целой и дробной частей (которые, в принципе, можно обе использовать для выдачи - получаем увеличение разрядности, о котором говорится на каждом микроконтроллерном сайте) вы будете хранить Y (целую часть? или не хранится?) и Z (целую и дробную части). И в чем выигрыш? В уменьшении умножений - вместо двух - одно? Так если брать Nb как степень двойки, можно одними сдвигами и сложениями обойтись.
А именно, например для Nb = 16 - из Y вычитаем 1/16 часть, а X уменьшаем в 16 раз, и добавляем к Y.

Спасибо, что заметили: сохранять Y вовсе не обязательно. Я поленился еще раз переделывать код, так как это мелочь, что она объявлена статической. Если уж Вам очень хочется, чтобы все используемые переменные имели одинаковую размерность, то считайте, что у Z есть целая и дробная часть. Мой скромный, но очень практический опыт работы с целочисленной арифметикой говорит о том, что нужно хорошенько разбираться с размерностью на этапе проектирования математики. Когда модель, формулы построены, то в реализации уже не так важно, где стоит запятая (точка). Поэтому я считаю все переменные целыми (как их и обрабатывает МК) и редко говорю "фиксированная точка", а чаще "целочисленная арифметика".

Пример: умножаем ЧИСЛО1 * ЧИСЛО2. Оба целые однобайтные. Результат ЧИСЛО3 - двухбайтное целое. Прекрасно.
ЧИСЛО1 - однобайтовое целое
ЧИСЛО2 - однобайтовое целое
ЧИСЛО3 - двухбайтовое целое
Можно объявить вообще все эти числа ИНТами или ЛОНГами. Никаких запятых.

Теперь нам захотелось результат иметь такого же масштаба, что и ЧИСЛО1. Хорошо, можете считать, что у ЧИСЛА2 запятая отделяет 8 бит дробной части. Тогда
ЧИСЛО1 - честно однобайтовое целое
ЧИСЛО2 - однобайтовое дробное
ЧИСЛО3 - двухбайтовое с целой и дробной частью.
Как на мой взгляд, то первый вариант проще для восприятия. Но на вкус и цвет...


Вы немного не дочитали статью Она, собственно, посвящена тому, как можно легко и просто найти Nb по заданным характеристикам фильтра (а именно: по времени отклика на ступенчатое воздействие). Поэтому уж такой свободы в выборе Nb у нас нет. Ну, частный случай может быть, что Nb = 16, но я считал более важным обеспечить Na+Nb=256 или иная степень двойки, чтобы деления не было.

Я не читал вдумчиво, но ваш путь выбора фильтра разглядел. Однако, ради простоты фильтра я не стал бы заморачиваться получением точного времени отклика. Уверен, в большинстве случаев так и надо поступать.
Я пишу не про форму представления числа. А про лишнюю сущность - переменную Z.
Na + Nb = 256 можно (и нужно) обеспечивать и при Nb - степени двойки. Na мы вообще не будем использовать, я написал выше, как это получается.