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

Зависит от того, что Вы дальше с этими числами делаете... Если есть ДМА, то проще. Для меня.

Допустим, ДМА нет. Дальше просто вывожу на LCD принятые данные.

Тогда быстро нельзя, раз для глаза... Значит, - любым способом.

Также зависит от выбранного процессора. Многие современные AVR-ки без всякого DMA можно завести в режим free-run, и доставать из ячеек измеренную величину в любой момент по мере надобности.

Использование на всю катушку редко бывает красивым , все, что работает, то правильно по определению.


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

Лично мне прерывания от внутреннего АЦП не нравятся, хотя аргументов против них у меня немного. Не нравятся прежде всего тем, что время преобразования такого АЦП очень коротко, а потому такое прерывание произойдет почти сразу же за командой START. А я "лишние" прерывания не люблю за то, что другим прерываниям мешают (большинство AVR не поддерживают вложенных/многоуровневых прерываний). Поэтому с моей точки зрения прерывания от внешних источников - хорошие, а от внутренних - плохие , разве что только прерывания от таймеров являются здесь исключением. Например, прерывания от UART, по моим представлениям, - хорошие и их обязательно следует использовать, тогда как прерывание от готовности SPI или I2C - "плохие", а потому тут лучше подождать окончание передачи, нежели использовать механизм прерываний. С этой точки зрения прерывания от АЦП тоже плохие , а потому, если вам нужно лишь раз в секунду на дисплее цифру выводить, то с прерываниями здесь тоже можно было бы не заморачиваться, а просто подождать, когда преобразование завершится.

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

Еще идея, мною однажды реализованная. Мне было нужно раз секунду обновлять текст на дисплее, мигая в такт светодиодом. Сам же текст зависел от показаний АЦП (температура или какое-то внешнее напряжение). Я поступила так: запустила таймер с периодом 1/16 секунды с обработкой прерываний от него. Получилось 16 шагов. На 8-ом шаге делаю TOGGLE светодиоду, инвертируя его светимость. На всего шагах опрашиваю АЦП и тут же запускаю следующее преобразование. Опросы сразу же суммирую (sum+=ADC.DATA), а на последнем 16-ом шаге эту сумму вываливаю в буфер для вывода, а затем зануляю. Этим способом я получаю не 12-разрядную величину (на ХМеге АЦП 12-разрядный), а 16-разрядную, которая шумит заметно меньше, давая мне дополнительный десятичный знак.

Прочитал заголовок темы, первая мысль: "Любопытно, как интегрированный в МК кот влияет на АЦП."

Извините.

Да никак, согласно квантовой теории Шредингера кот жив и мертв одновременно, а у нас МК двичный. Вот в квантовом компьютере кот делов натворил бы.

Извините))