В данном случае, наверное, - нет. См 19 и 20 посты.

Вот, именно - тонкости! Представьте, что разность между считанным и текущим значениями - меньше двадцати. Что получим? По этой же причине у автора вопроса и прыгают значения: в первом топике он привёл код, якобы усредняющий из двадцати значений... Имхо, сумма подсчитывается из значений измерений делённых на 5 - так усреднять, мягко говоря, не корректно.

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

Меня смутила формулировка.. ИМХО, есть разница между "устранение помех" и "устранение причин из-за которых эти помехи возникают на входе АЦП"..

Получим, что результат никогда не достигнет входного значения. Но ведь и реальная, математическая экспонента никогда его не достигает! Вопрос лишь в необходимой точности. Если нужна большая - результат храним в long, а используем в качестве результата старшую половину - то есть как бы число с фиксированной точкой, в котором младшие 16 разрядов дробные.

Почему? Просто результат будет в 4 раза больше.


Пардон, не доглядел - конечно же надо сначала суммировать 20 значений, а результат делить на 5. А еще лучше - использовать степень двойки.

Сообщение отредактировал 777777 - Feb 13 2009, 12:00

Математическая экспанента хотя бы стремиться к нему. В Вашем же случае мы будем иметь постоянную ошибку. Результат этого - всё тот же - отбрасывание остатка при делении, который тем больше, чем больше делитель (это - ведь, наверное, и есть те тонкости, о которых Вы говорили выше). Тогда, уж лучше что-нибудь такое:

Инициализация переменной
T_average_tmp = T_current * N
...................
T_average_tmp += (T_current - T_average)
T_average= T_average_tmp / N

Последнюю строчку, может быть, записать даже так:
T_average= (T_average_tmp + N/2) / N

Последнюю строчку только так и нужно писать, чтобы погрешность от целочисленного деления осталась +-0.5LSB.

Что значит "постоянную ошибку"? Разумеется, экспонента будет отличаться от реальной из-за округлений, это неизбежно при цифровых вычислениях, вопрос лишь в необходимой точности. Даже если вы примените float, все равно ошибка будет, так как float тоже дискретно. Но задача ведь не в том, чтобы имитировать экспоненту, а в том, чтобы сгладить сигнал. Для этого вычисления в целых вполне достаточно.

Тогда уж лучше что-нибудь такое:

Правда, gnu-тый компилятор не очень эффективно кодирует сдвиги (не знаю, может IAR поумнее), поэтому этот участок лучше написать на ассемблере.
Смысл в том, что в старших 16 битах AdcF хранится фильтрованное значение, а в младших - его дробная часть, т.е. оно представляет собой число с фиксированной точкой. При кодировании на ассемблере можно даже подойти к делению (сдвигу) более творчески: если в отбрасываемых битах старший 1, то к оставшимся прибавляем 1, а если 0 - то не прибавляем, т.е. выполняем деление с округлением до целого. Тогда не будет ошибки с отбрасыванием, которой ты так боишься.

+1
Давно делаю похожим образом, часто запас разрядов в аккумуляторе делаю равным числу сдвигов для деления на коффициент фильтра (он степень двойки). Т.е. для беззнаковых 10-битных отсчётов и "рециркуляции" 7/8, т.е. весе очередного отсчёта 1/8 будет так:

Собственно, с не-степенью двойки будет аналогично, просто езде заменится на , но я не вижу в этом особого смысла. Если задача так чувствительна к тому, что новый отсчёт будет входить не с 1/8 или 1/16, а имено с 1/10 или 1/13, то скорее всего там и фильтр нужен более высокого порядка.

Пожалуйста,помогите переделать найденный на этом форуме программный ФНЧ под мои условия,сам не могу разобраться.

Остановился на таком варианте

Нужно создать в оперативной памяти закольцованный FIFO-буфер с двумя указателями (PTR_first и PTR_last).

И регистр суммы. Разрядность его должна быть достаточной для хранения суммы 20-ти значний без округления.

Как только приходит очередное значение от АЦП Вы его записываете в ячейку, на которую указывает PTR_last, добавляете его к сумме и вычитаете из суммы значение, на которое указывает PTR_first.

После чего двигаете PTR_first и PTR_last на следующие ячейки в кольце.

Таким образом у Вас всегда в регистре cуммы будет акутульное значение среднего, умноженное на 20.

Чтобы получить среднее достаточно будет поделить значение, находящееся в данный момент в регистре суммы на 20.

Сообщение отредактировал Флюктуация ваккума - Aug 15 2015, 12:23

Такой вариант не подойдет?
for(i=0;i<20;i++) // усредняем 20 выборки
{
ADC_cur = ADС;
if (i == 0)
{
ADC_old = ADC_cur; // первое значение отправляем в сумму
ADC_sum = ADC_old;
}
else
{
ADC_old += ADC_cur; // сложили текущее значение со старым
ADC_old /= 2; // поделили на 2
ADCsum += ADC_old; // просуммировали
}
}
ADC_cur = ADC_sum/20; // cумму поделили на 20 */