Опрос АЦП внутри прерывания Опции

[AndreyVN]

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

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

Код

//АЦП доступен, прерывания разрешены
//ADCSRA: 7-ADEEN 6-ADSC 5-ADATE 4-ADIF 3-ADIE 2-ADPS2 1-ADPS2 0-ADPS0
//           1      0       0      0      0      1       1       1
ADCSRA = 0x87;
...
ADCSRA |= 0x40; //Начать одиночное преобразование АЦП
while( (ADCSRA & 0x40)==0x40 ); //ждем завершения преобразования ADSC (13-14 тактов)
c1 = ADCL; //Читаем результат преобразования сначала младший
c2 = ADCH; //затем старший (иначе не работает!)
VADC = c1 + c2*256;

[Abell]

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

[AndreyVN]

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

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

[stells]

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

[Abell]

Ну так оно и было, все работало.

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

[AndreyVN]

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

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

я сталкивался с неправильной обработкой АЦП в подпрограмме обработки прерывания от таймера

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

[stells]

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

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

[Xenia]

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

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

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

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

[AndreyVN]

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

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

Код

interrupt [TIM2_OVF] void timer2_ovf_isr(void)
{
ADCSRA |= 0x40; //Начать одиночное преобразование АЦП
}

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

Код

interrupt[ADC_INT] void ADC(void)
{
unsigned char c1,c2;
c1 = ADCL; //Читаем результат преобразования сначала младший
c2 = ADCH; //затем старший (иначе не работает!)
VADC = c1 + c2*256;
}

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

[_Pasha]

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

[AndreyVN]

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

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

[Сергей Борщ]

оба байта стабильно 00, 00.

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

Код

while( (ADCSRA & 0x40)==0x40 ); //ждем завершения преобразования ADSC (13-14 тактов)

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

Код

c1 = ADCL; //Читаем результат преобразования сначала младший
c2 = ADCH; //затем старший (иначе не работает!)
VADC = c1 + c2*256;

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

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

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

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

[AndreyVN]

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

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

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

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

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

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

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

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

[Сергей Борщ]

Вывод на LCD и в основном цикле пробовал и прямо в обработчике пробовал. Переменные тоже пробовал объявлять глобальными и локальными, ситуация не меняется.

Покажите объявление этих переменных. Хорошо, без намеков: используете ли вы в объявлении ключевое слово volatile?

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

Мне удается опрашивать его где угодно. Еще раз повторю: чудес не бывает. В документации опрашивать АЦП в прерывании таймера не запрещено.

[AndreyVN]

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

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

Код

interrupt [TIM2_OVF] void timer2_ovf_isr(void)
{
ADCSRA |= 0x40; //Начать одиночное преобразование АЦП  
PORTA.4 = ~PINA.4; //Для осциллографа
}

interrupt[ADC_INT] void ADC(void)
{
unsigned char c1,c2;
#asm("sei"); //Разрешить вложенные прерывания (управляющие H-мостом)
PORTA.4 = ~PINA.4; //Для осциллографа
c1 = ADCL; //Читаем результат преобразования сначала младший
c2 = ADCH; //затем старший (иначе не работает!)
V2 = (c1 + c2*256)*4.97*Ku/1024;
PORTA.4 = ~PINA.4; //Для осциллографа
}

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

[_Pasha]

Нет, volatile не использую.

Ну вот и ответ на вопрос.

[WHALE]

Ну вот и ответ на вопрос.

ТС так и не указал используемый компилятор.Но судя по приведенным кускам кода-это CV.
А он не такой резкий в оптимизации как тот-же ЯР и не выкидывает без предупреждения
не- volatile переменные в прерываниях.Кажется,квалификатра volatile там и вовсе нет...
Но я бы не заметал непонятки под ковер, а постарался-бы все-таки разобраться до конца,
бо неизветно,не всплывут-ли они потом при модификации кода.

[AndreyVN]

ТС так и не указал используемый компилятор.Но судя по приведенным кускам кода-это CV.
А он не такой резкий в оптимизации как тот-же ЯР и не выкидывает без предупреждения
не- volatile переменные в прерываниях.Кажется,квалификатра volatile там и вовсе нет...
Но я бы не заметал непонятки под ковер, а постарался-бы все-таки разобраться до конца,
бо неизветно,не всплывут-ли они потом при модификации кода.

Да, действительно, Code Vision (версию сейчас не назову), на модификатор volatile CV ошибки не выдает, но, возможно, никаких действий не предпринимает.

[demiurg_spb]

Ну вот и ответ на вопрос.

+1

[Сергей Борщ]

А он не такой резкий в оптимизации как тот-же ЯР и не выкидывает без предупреждения не- volatile переменные в прерываниях.

А никто не говорил, что переменная выкидывается в прерывании. И ИАР не выкидывает. Выкидывается ее чтение в основном цикле. И выкидывается совершенно законно, и предупреждать никто не обязан - иначе вы получали бы ворох предупреждений на каждую строчку кода.

Да, действительно, Code Vision (версию сейчас не назову), на модификатор volatile CV ошибки не выдает,

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

но, возможно, никаких действий не предпринимает.

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

Даже несмотря на то, что CV - компилятор "языка, похожего на C", вам обязательно стоит потратить лишние несколько минут чтобы разобраться, что дает ключевое слово volatile и когда его просто необходимо применять. Во избежание в дальнейшем траты кучи времени на "глюки компилятора".