Вопрос по АЦП, Free running mode Опции

[SasaVitebsk]

При работе с АЦП делаю заранее заданное демпфирование по каналам. То есть порядок выборки каналов у меня постоянно скачет. Это поменять нельзя. АЦП запущено в "Free running mode" и проверяется по таймеру. Время с момента переключения канала и до выборки значения АЦП вдвое превышает означенные 25 тактов (пробовал и увеличивать).

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

Код

    127             default:
    128               x0=Adc[TekChan].X1=ADCH;                            // Прочитать значение АЦП
   \                     ??pvPWWLvl1_7:
   \   000000B8   91300079           LDS     R19, 121
   \                     ??pvPWWLvl1_9:
   \   000000BC   8334               STD     Z+4, R19
   \   000000BE   2E23               MOV     R2, R19

То есть по databreakpoint останавливаюсь в последней строчке и вижу в АЦП значение FF к примеру, а в ячейку уже занесено 83. Каналы и всё прочее выставляется верно.

Создаётся впечатление, что АЦП не успевает завершить операцию. Но, как я уже писал, при увеличении времени в разы сама ошибка остаётся.

Может я чего не знаю. Может необходимо как то обновить значение. Типа прочитать два раза или что-то ещё.

Я в непонятках.

[SasaVitebsk]

А Flags у вас объявлен как volatile?
Просто похоже данная проблема к АЦП не имеет отношения. Обычный хомут какой-то. Попробуйте по шагам пройти, либо asm просмотрите.

[alux]

А Flags у вас объявлен как volatile?

Flags объявлен глобально, без volatile. volatile в данном случае здесь ни при чем. Но на всякий случай проверил: с volatile проблема осталась. На мой взгляд проблема как-то связана с прерываниями. Если за время обработки прерывания от таймера1 произошло несколько прерываний от АЦП (которые имеют низкий приоритет), то после окончания обработки прерывания от таймера1 попадаем в обработчик прерывания от АЦП. В момент между считываниями ADCL и ADCH возможна ситуация, когда происходит следующее преобразование АЦП, и предыдущий результат теряется. Но не обнуляется ведь!
Это только моя версия происходящего. Какие будут еще ваши предположения?

PS. Чем объяснить такую строгую периодичность: после трех правильных данных идут три нулевых?

PS2. Версию, что таймер своими шумами влияет на работу АЦП, я тоже отбрасываю.
Может быть нехватка стека? Но я не использую ресурсоемких функций. И пробовал увеличить CSTACK(0x100), RSTACK(0x64). Не помогло.

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

volatile в данном случае здесь ни при чем.

Но Flags должен быть volatile, также как и tmp. Лучше сразу писать правильно, чем ждать, когда начнется "при чем". Есть еще одно потенциальное место для бага: Flags &= ~DISPLAY; Оно компилируется примерно в такое:

Код

register Tmp = Flags; (1)
Tmp = Tmp & DISPLAY; (2)
Flags = Tmp; (3)

Что произойдет, если между командами 1 и 3 произойдет прерывание, изменяющее Flags? Обращения к подобным переменным надо делать атомарными, т.е. с запретом прерываний.

Но не обнуляется ведь!

Попробуйте присваивать tmp в прерывании константу, т.е. исключите АЦП из получения результата.

[alux]

Попробуйте присваивать tmp в прерывании константу, т.е. исключите АЦП из получения результата.

Присвоил переменным Flags, value, tmp квалификатор volatile. В прерывании АЦП делаю tmp=123;. В итоге на терминал выводится последовательность 123 без промежуточных нулей.

Обращения к подобным переменным надо делать атомарными, т.е. с запретом прерываний.

В главном цикле при обнулении флага сделал так:

Код

oldState = __save_interrupt();
__disable_interrupt();
      Flags &= ~DISPLAY;  // Critical section goes here
__restore_interrupt(oldState);
..................

Еще вычитал в документации, что для неразрывного кода используется ключевое слово __monitor. Но оно, насколько я понял, относится к функциям.

PS. В общем, обнуление флага сделал в критической секции. Проблема осталась. Мне кажется проблема кроется в чем-то другом. Мои идеи иссякли.

PS2. Эксперимент с присвоением константы 123 переменной tmp показывает, что проблема кроется в АЦП? Т.е. так, как я описывал выше?


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

Спасибо, СергейБорщ, SasaVitebsk, что указали на потенциальный источник ошибок.

Сообщение отредактировал alux - Apr 15 2008, 17:13