[12 мА вместо 10-ти на 8 МГц]
Фууух, спасибо, полегчало. 1,9 мА. Странно, обычно я с потреблением не заморачивался и оставлял ноги висеть в воздухе в 3-м состоянии. И ДШ про то же подтверждает что так лучше не делать:ARV писал(а):неконтролируемых утечках, если все пины находятся в режиме входов
Unconnected pins
If some pins are unused, it is recommended to ensure that these pins have a defined level. Even though most of the digital inputs are disabled in the deep sleep modes as described above, floating inputs should be avoided to reduce current consumption in all other modes where the digital inputs are enabled (Reset, Active mode and Idle mode).
The simplest method to ensure a defined level of an unused pin, is to enable the internal pull-up. In this case, the pull-up will be disabled during reset. If low power consumption during reset is important, it is recommended to use an external pull-up or pull-down. Connecting unused pins directly to VCC or GND is not recommended, since this may cause excessive currents if the pin is accidentally configured as an output.
http://mymcu.ru/hybroid писал(а):Надо выбрать какой-то МК на ядре 51.
Не вполне понятно КАК Вы реализовали буфер этих 64 значений.pokk писал(а): Понадобилось мне вывести на индикатор данные из АЦП, что бы на индикаторе они сильно не прыгали сделал суммирование 64 значений, а после делением сдвигом. Так вот теперь значение на индикаторе более менее установилось, но если значение АЦП будет на границе перехода 0.9-1.0, то небольшое колебания АЦП опять приводит к прыганию данных на индикаторе.
Почему нельзя сначала заполнить буфер, а потом вычислить среднее?КРАМ писал(а):Буфер нужно заполнять ПО КРУГУ и вычислять среднее после КАЖДОЙ НОВОЙ ЗАПИСИ в буфер.
Код: Выделить всё
#define FILTR_DEPTH 64
static uint16_t adc_one_shot(void){
ADCSRA |= 1<<ADSC;
while(ADCSRA & (1<<ADSC));
return ADC;
}
uint16_t get_filtered_sample(void){
static uint16_t filtr[FILTR_DEPTH];
static current_sample = 0;
uint32_t sum = 0;
fltr[current_sample] = adc_one_shot();
if(++current_sample >= FILTR_DEPTH) current_sample = 0;
for(uint8_t i=0; i<FILTR_DEPTH;i++) sum += filtr[i];
return sum / FILTR_DEPTH;
}
Не рассмотривая оптимизацию под конкретную архитектуру...ARV писал(а):не самый оптимальный по быстродействию
Код: Выделить всё
uint16_t get_filtered_sample(void){
static uint16_t filtr[FILTR_DEPTH];
static current_sample = 0;
static uint32_t sum = 0;
sum =- fltr[current_sample];
fltr[current_sample] = adc_one_shot();
sum =+ fltr[current_sample];
if(++current_sample >= FILTR_DEPTH) current_sample = 0;
return sum / FILTR_DEPTH;
}Хранить все 64 измерения по отдельности, тратить 128 байт на то, что требует двух, не говоря про скорость работы? У такого метода есть хоть одно преимущество перед другими?Не вполне понятно КАК Вы реализовали буфер этих 64 значений.
Буфер нужно заполнять ПО КРУГУ и вычислять среднее после КАЖДОЙ НОВОЙ ЗАПИСИ в буфер. Длина буфера должна быть примерно 0,25...0,5 секунд. Это даст полосу фильтрации такого КИХ ФНЧ с прямоугольным окном 2...4 Гц.
Из этого следует, что састота вывода должна быть 0.1 - 1 Гц. При такой частоте нужное усреднение даст любой метод. Другое дело, что усреднение само по себе не поможет, разве что мигать будет не 2-3 младших бита, а всего 1.Понадобилось мне вывести на индикатор данные из АЦП, что бы на индикаторе они сильно не прыгали
Другие методы - это БИХ.COKPOWEHEU писал(а):У такого метода есть хоть одно преимущество перед другими?
Как же не поможет, если амплитуда помехи становится меньше в 4...8 раз?COKPOWEHEU писал(а):При такой частоте нужное усреднение даст любой метод. Другое дело, что усреднение само по себе не поможет, разве что мигать будет не 2-3 младших бита, а всего 1.
может быть, может быть...Kavka писал(а):Если от цикла избавиться в get_filtered_sample, то будет нормально.
Честно говоря, не особо углублялся в теорию. "На пальцах" он, как я понимаю, работает аналогично RC-цепочке. А там вся настройка в установке частоты среза, неустойчивости возникнуть неоткуда.Недостаток БИХ состоит в необходимости обеспечения устойчивости.
А недостаток ли это? Да, результат может отличаеться от прямого усреднения или КИХ, но пульсации меньше.При ограниченной разрядности БИХ оказывается много хуже КИХ, поскольку быстро убывает вклад дальних семплов.
Затраты процессора - возможно, но расходовать на такую задачу аж 128 байт памяти вместо 2 я считаю лишним. Для более мощных устройств - возможно, но не для AVR, где всего 64 байта - 8 кБайт. (мелочь без ОЗУ не рассматриваем).На самом деле ресурсы вычислителя при КИХ и БИХ для равной крутизны примерно одинаковы.