Всем привет!
Перенес код опроса АЦП (ATmega16) внутрь обработчика прерываний от таймера, АЦП напрочь перестал работать, оба байта стабильно 00, 00.
Есть какие-то подводные камни при запуске однократного преобразования АЦП в теле обработчика прерывания? (Сам факт вызова процедуры обработчика прерывания вижу на осциллографе.)

Этим кодом пользовался много раз:

А Вы не обрабатывайте АЦП в прерывании, Вы обрабатывайте его в главном цикле, так-то оно правильней будет... за 13-14 тактов многое может произойти, да так, что и выйти корректно из прерывания может не получиться, или выйти не туда

Ну так оно и было, все работало. Мне нужно обеспечить гарантированное время в петле регулирования. Все что связано с регулированием (измерение и вычисление управляющего воздействия) засунул в прерывание от таймера, а интерфейсную часть (опрос клавиатуры и вывод на LCD) оставил в основном цикле. И... неожиданно обломался. Уже пару дней перечитываю даташит - ну не вижу я ни одной причины по которой нельзя опросить АЦП внутри обработчика прерывания!
Времена на стадии отладки сделал огромные (21 mS), при входе в прерывание выставляю на пин "1" на осциллографе вижу, что прерывание случилось, при выходе из прерывания сбрасываю пин в "0", то есть, все работает, но не измеряет. Опора как была так и есть. В общем, фигня какая-то. Клавиатура работает, LCD тоже, то есть структура программы не рушится, если случаются вложенные прерывания, они отрабатывают корректно.

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

Ну пусть дальше и работает А, случайно, прерывания АЦП запретили? Регистр состояния не меняется в процессе обработки? Может, проще в основном цикле запускать преобразование, а по прерыванию АЦП брать результат и синхронизировать с таймером?

Да, сам АЦП прерывания не генерит, ADIE=0. Так все красиво в программном коде разложилось, не хочется перелопачивать. Попробую посмотреть на ассемблере, что там компилятор сотворил.


А у Вас тоже 00 00 было или просто точность измерений упала?

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

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

Для этого лишь надо кроме старта еще самодельный флаг выставить, что с АЦП данные надо востребовать, а в основном цикле его проверяете, и если стоит, то ждете готовности и опрашиваете.

P.S. Сама делала так: таймер запускала на удвоенную частоту опроса, в четных перерываниях от таймера делала старт АЦП, а в нечетных его опрашивала без ожидания.

Идея понятная. Нечто подобное я делал, нашел в в своих-же разработках: Запуск АЦП по переполнению таймера

Ловим результат в обработчике прерываний от АЦП (естественно, прерывания от АЦП разрешены ADIE=1)

Сейчас работать не хочет, видимо, причина где-то в другом месте.

Мега8 недалеко ушла от 16-й, все работало и работает, АЦП опрашивается, 3962.5 Гц, тоже цикл регулирования. Смотрите листинг

А Иде смотреть-то?

А где вы их проверяете? В этом же прерывании или в основном цикле? Если в основном цикле, то как объявлена переменная VADC?

Вы только не забывайте, что это 13-14 тактов частоты АЦП, в вашем случае это 13...14 * 128 = 1664 или 1792 тактов ядра. Вы хорошо подумали, прежде чем засунуть такое ожидание в обработчик прерывания?

Ой. Делайте VADC = ADC; и не морочьте себе голову. Любой компилятор для AVR знает, в каком порядке надо читать двухбайтные регистры.

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

Чудес не бывает.

Я контролирую не VADC, а непосредственно с1, с2, чтобы свести к минимуму возможные причины ошибок в т.ч. присвоения, преобразования типов и т.п..
VADC тоже выводится на экран после мат. обработки, но это сейчас не интересно.
Вывод на LCD и в основном цикле пробовал и прямо в обработчике пробовал. Переменные тоже пробовал объявлять глобальными и локальными, ситуация не меняется.


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


Когда код заработает так и сделаю, а сейчас, предпочитаю видеть каждый байт как он есть.


Ой, Спасибо! Однако, Вы не сказали, удавалось лично Вам опрашивать АЦП в обработчике прерываний таймера?

Покажите объявление этих переменных. Хорошо, без намеков: используете ли вы в объявлении ключевое слово volatile?
Мне удается опрашивать его где угодно. Еще раз повторю: чудес не бывает. В документации опрашивать АЦП в прерывании таймера не запрещено.

Нет, volatile не использую. Раньше пользовался, когда менял C'шные переменные из кода ассемблерных вставок, но так и не знаю, зачем это надо компилятору. Собственно, проблема решилась, заработала конструкция:



Отключил 90% кода не связанного с обслуживанием АЦП, измерение ожило, затем стал возвращать процедуру за процедурой, специально проверил, работоспособность прерываний которые случаются во время interrupt[ADC_INT] (это разрешено командой SEI) - все работает, переменные c1, c2 хранятся в регистрах, но успешно сохраняются и восстанавливаются через стек. К сожалению, так и не понял, что было. Сейчас вернул почти весь код на место, все работает, возвращаться к обработке АЦП "внутри таймера" уже нет смысла.