Впервые пришлось иметь дело со встроенным в атмегу АЦП, и заметил такую пакость - некоторые измерения получаются совершенно левыми. Т.е. получаем корректные данные раз 20 подряд, а потом - БАЦ - и какая-то хрень вылезает. Дальше снова нормальные результаты.

Может быть какие-то есть схемотехнические приемы для уменьшения помех этих?

Я просто ноги AREF и AVCC посадил на +5 В с конденсатором на землю 0,1 мкФ.

Вот так инициализирую АЦП:

// ADC initialization
// ADC Clock frequency: 921,600 kHz
// ADC Voltage Reference: AVCC pin
ADMUX=0x40;
ADCSRA=0x83;

Это функция чтения результатов преобразования:

unsigned int read_adc(unsigned char adc_input)
{
ADMUX=adc_input|ADC_VREF_TYPE;
// Start the AD conversion
ADCSRA|=0x40;
// Wait for the AD conversion to complete
while ((ADCSRA & 0x10)==0);
ADCSRA|=0x10;
return ADCW;
}

Лично я с таким не сталкивался... пока, по крайней мере.
возможно, стоит использовать внутренний ИОН с подцепленным на Aref кондером или, что еще лучше, специализированный ИОН?
насколько качественное питание используется для контроллера? Если источник импульсный - то я, в принципе, не удивлен...

Питание от линейного стабилизатора, не импульсное. Про внешний ИОН думал.. Попробую. Но может быть все-таки еще какие решения есть? Меня напрягает то, что ошибочные преобразования случаются хаотично и они отдельные (т.е. проскочит раз и снова все нормально).

Может быть какие-то хитрые временные интервалы нужно выдерживать между измерениями?

Сколько сколько частота преобразования? Я пробовал играться с 50кГц при 4Мгц ядра - вроде все работало при навесном монтаже. Для корректной работы рекомендуется до 200кгц(даташит). Для корректного преобразования необходимо, чтобы уровень напряжения был постоянным определенное время(13-25 тактов АЦП). Или хотя-бы достаточно медленно менялся...

Техника защиты от помех(из разных источников)
1) почитать даташит про атмегу - там есть про PCB - экранировать аналоговую часть по мере возможности
2) почитать про питание ПЛИС и применить аналогичноую методику для ARef - навесить разных конденсаторов для сглаживания бОльшего числа гармоник. Мне хватило 0.1 и 1 мкф
3) ввести мегу в режим легкого аналогового посапывания - ADC Noise reduction - это отрубит цифровую ВЧ часть\ядро на время преобразования
4) ну и самое страшное - повесить НЧ фильтр на ногу, с которой делается преобразование

временные интервалы-не нужно, т.к. есть режим непрерывного преобразования - одно кончилось - сразу началось другое.

апноуты AVR040 AVR042 и раздел ДШ по АЦП используемого МК.



AREF нужноподключить через резистор или через индуктивность.



это много.

на вход тоже желательно конденсатор повесить.

Понятно, что в даташите много всего написано на тему улучшения качества конверсии (и какой фильтр на AVcc повесить - емкость+индуктивность, и как усыплять процессор на время конверсии, чтобы не шумел зря, и что внутренний Vref куда лучше, чем Vcc, и что при >200КГц в качестве ADC clock не получится честных 10 бит, и прочее, и прочее)... И даже понятно, что именно оно и есть искомые "схемотехнические приемы". Но все это, похоже, к делу не относится - ведь помеха, чем бы она ни была, возникает редко, но сильно.

С налету я бы проверил следующее:

1. Не стал бы пока для пущего спокойствия инициализировать ADC каждый раз (ADMUX=adc_input|ADC_VREF_TYPE; ) - просто для проверки, а если нужно даже во время экспериментов - то пропускал бы после инициализации один отсчет (если невовремя поменять выбранный канал - то можно получить отсчет с предыдущего). Но дело почти наверняка не в этом - я подозреваю, что эта процедура пока вызывается с одним и тем же каналом, да?

2. Включил бы ADC во free-running mode (чтобы исключить влияние любых манипуляций с его настройками), и посмотрел бы, тупо читая и проверяя результат почаще (и _ничего_ больше с АЦП не делая), что за сигнал там идет на самом деле (входную ногу привязал бы для начала к земле, потом к Vcc, и только потом к сигналу - мало ли, вдруг сигнал _и_правда_ такой?).

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

У меня с ADC как раз на ATmega8L-8AI все нормально: +5V из розетки через трансформатор, диодный мост и линейный (обвешанный должными конденсаторами) стабилизатор, 8МГц внутренний clock, ADPS=0 (то есть 4МГц ADC clock), по 13 тактов АЦП (то есть 26 тактов процессора) на отсчет - в итоге 300K отсчетов в секунду. Vref - внутренний (и я даже поленился вешать на AVcc фильтр!), АЦП во free-running mode, чтобы ничего не проверять по дороге, и читаю я его строго раз в 26 тактов отполированным вручную циклом, чтобы обеспечить максимальную скорость захвата. Восемь бит там не получается, но никаких резких выбросов в случайные моменты нет, просто некий небольшой шум...

Много всего перепробовал, так и не помогло. Пришлось программно отбрасывать некорректные результаты.

У меня подобная шляпа на m16 была . Вот из-за чего выяснилось . Я как написано в умной книжке запускал преобразование АЦП с спящем режиме, соответственно ток потребления менялся и из-за маленькой ёмкости в БП напруха питания чуть изменялась. Навешал кондеров и усё нормально бегает максимум +- 1 значение. Единственное что я так и не заставил его делать так эт из спящего режима ADC выходить ибо не герит и всё прерывание от АЦП. Использовал Igle благо у мя Т2 от внешнего кварца тикает.

Я думаю эт с железом чёто на m8 пробовал нормально.