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

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

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

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

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

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

Ещё раз обращаю Ваше внимание на то, что ADSC, ADEN, ADIF я вообще не трогал. И согласно даташиту это не требуется (только ADSC и ADEN при инициализации АЦП). И так я работал без особых проблем в других проектах. Я предложил мой расчёт для получения результата. Тем не менее при съёме с периодом 75 тактов АЦП примерно 1 раз в 15 - 20 секунд и более (иногда до нескольких минут) АЦП запущенное на частоте 16М/128=125кГц каким то образом ловило предыдущий канал. Это я установил абсолютно точно. При одиночном запуске я сейчас считываю значение через 50 тактов. Всё работает отлично. Может быть при смене канала требуется дополнительное время? Это, в общем то логично, но я не нашёл такого упоминания в даташите. Может данный режим используется без смены канала?

ЗЫ: Кристалл at90can128. Там возможна такая фишка, как задание источника перезапуска АЦП в этом самом FRM. Этим источником может являться к примеру таймер.

Ну, вообще-то про предыдущий канал прямо написано:
"If both ADFR and ADEN is written to one, an interrupt event can occur at any time. If the
ADMUX Register is changed in this period, the user cannot tell if the next conversion is
based on the old or the new settings."

А про несинхронность обновления каналов, да, каюсь, был неправ. Нашёл таки, что оно действительно синхрится с преобразованием и в free-run режиме тоже.

То есть иными словами, необходимо два раза считывать и брать второй результат. Я правильно понял? Либо наверное перестартовывать.

Получается, что в общем-то этот режим, в условиях частой смены каналов, абсолютно бесполезен. Не для этого преднозначен.

Вроде разобрались всем миром.
Всем спасибо за обсуждение.

"ADMUX can be safely updated in the following
ways:
1. When ADFR or ADEN is cleared.
2. During conversion, minimum one ADC clock cycle after the trigger event.
3. After a conversion, before the Interrupt Flag used as trigger source is cleared.
When updating ADMUX in one of these conditions, the new settings will affect the next
ADC conversion."

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

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

Ну иногда да, особенно когда начинают рассказывать про магические перетекания из
канала в канал, про необходимые пропуски преобразований, итд....
Сделай все по даташиту и проблем не будет.
Не, ну конечно Атмел сильно намудрил с описанием функциональности АЦП, но после
примерно 3-4 прочтения становится все более менее понятно...

Не нужно таких сложных вычислений, в основном нужно знать моменты когда нельзя менять канал...
Ну и если есть свободный таймер то все это отследить вобще не представляет сложностей.
Если нету, ненамного сложнее, всегда можно привязаться к таймеру который обслуживает
другие задачи.

P.S. Кстати, а что это за магическое число 25 про которое все здесь говорят ?
В даташите 25 это только первое преобразование после ADEN или преобразование после смены
Reference, во всех остальных случаях 25 неактуально.
Кстати, во всех своих прогах, при инициализации АЦП делаю это холостое "длинное" преобразование
на 25 тактов, ну и дальше 25 уже нигде не встречается...

P.P.S. Даташит раздел АЦП : "However, the simplest method is to..."
Если мы обсуждаем наипростейшие варианты работы с АЦП и никуда не торопимся, тогда конечно
проще подождать пару преобразований до получения правильного результата...

В самом первом посте увидел инструкцию STD. У меня были глюки, когда было обращение STD /LDD к данным на границе 256-байтовой страницы. А где у Вас данные из АЦП?
Для меня это настолько геморройная тема была...
Представьте себе человека, находящегося на вершине безумия, который перенес блок данных в более безопасное место. Попустило. С тех пор, у кого ни спрашиваю, никто не знает такого глюка MCU core.
Причем, проявляется он как раз на частоте 16 Мгц. НАПРЯГИТЕ ПАМЯТЬ!!! Неужели ни у кого такого не было ???

Разьясните пожалуйста пару моментов.
13 - 260 μs Conversion Time
значит максимальная частота при 10бит ~77kHz?

By default, the successive approximation circuitry requires an input clock frequency
between 50 kHz and 200 kHz to get maximum resolution.
Как перевел диапазон 50-200к даёт максимальное разрешение.
Вообщем интересует, при каком значении частоты младший бит будет отличатся стабильностью? По эксперементам у меня при 125kHz (относительно 62,5 усред. на 8) начинает прыгать.

Выходное сопротивление источника сказывается. Смысл: при работе sample&hold.
Какое у Вас вых. сопр.?
P.S. Проверить предположение можно, подключив кондюк ~470 пФ на вход АЦП.

Сообщение отредактировал _Pasha - Jan 16 2008, 22:15

Небольшоё, аккумулятор-> 510 ом и 0,2uF на землю. Я "относительно" написал потому что у меня два канала шим стабилизации тока, когда канал выкл, вызывается ф. ожидания стабилизации напряжения, затем его измерения, в это время второй канал наводит помехи. Вот их влияние намного видней на 125kHz, если б не чего не фонило, то считывалось бы одинаково. Просто не понял в даташите 13 - 260 μs Conversion Time а у меня 125к ->8uSek и еще
The ADC module contains a prescaler, which generates an acceptable ADC clock frequency
from any CPU frequency above 100 kHz.
И это 50-200к
Трудности с переводом (учил немецкий), ощущения что вылез за разрешение 10 бит, растолкуйте пожалуйста.

Ещё раз поясняю младший бит не может "отличаться устойчивостью". Это ваша точность. Чтобы вам понятнее было представьте что у вас измеряемое значение 212.5 (в единицах АЦП). Соответственно АЦП будет показывать то 212, то 213. Несмотря на устойчивость. Поэтому сколько бы разрядов АЦП не имело всегда точность не менее +/- единица младшего разряда. По поводу погрешностей и прочего - почитайте даташит - там достаточно детально всё расписано и сведено в графики. От себя замечу, что точность АЦП AVR мне не понравилась. Правда я и не пытался добиваться высокоточных результатов. Применение внешнего АЦП как правило даёт более хорошие результаты по стабильности и точности.

По поводу каких-то ошибок в озу - нигде и никогда не слышал. То что вы видите в распечатке - это кусок листинга который формирует Си компилятор. Мне и в голову не приходило самому распределять там память. Как линкер её распределил, так я и работал. Из того что я уже приводил - понятно что ошибка возникает именно при чтении из АЦП. Вроде в этой ветке разобрались с её природой. То есть виноват я сам, так как нечего притягивать за уши те способы работы, которые для этого не предназначены. FRM предназначен для слежения за сигналом из одного канала, на сколько я понял. При применении перебора каналов необходимо использовать другие режимы работы АЦП, так как FRM не имеет в этом случае абсолютно никакого выигрыша, а доставляет головную боль.

2 _Diman_. По поводу задаваемого вами вопроса - поищите по форуму. Месяца два-три назад мощная тема была где спецы аналоговые это обсасывают. Так как есть понятие "максимальная частота преобразований" для АЦП, а есть понятие "полоса пропускания".

Не выдержал... Саша, Вы же здесь один из гуру, не делайте таких скоропалительных выводов.
Нормально этот режим работает, если точно привязываться к записи мультиплексора. А это можно правильно сделать, только используя прерывание самого АЦП...
У меня в серийном изделии нормально оцифровываются все 8 каналов. Прерываний всего 3. Прерывание ADC используется для диспетчера задач и переключения каналов.
Но есть одно но :-), может, Вы именно на него наткнулись. Переключать каналы надо осторожно, у меня были глюки с данными, когда я слишком рано записывал новый адрес канала в ADMUX, до завершения новой выборки. Вот тогда и было некое дрожание и привирание в результатах. Тогда я увеличил выдержку до задания нового канала - вставил фоновую прогу формирования вспомогательных ШИМов,- и все зааработало.
Еще одно неудобство для меня заключалось в том, что я коммутирую входные сигналы на АЦП, и было довольно трудно рассчитать правильное время коммутации - нужно учитывать время успокоения усилителя и прочее.
Сейчас все работает правильно.

Сейчас изделие отправили на натурные испытания на МТЗ. Это закрывается только первый этап из трёх данной темы. Потом начнётся устранение хомутов мелких и изделие ко мне ещё вернётся. Хорошо - уговорили. Я детально исследую данный вопрос, чтобы не быть голословным, и подробно доложу.

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

Причина такой фразы проста. При FRM я использовал текст запуска преобразования:


При одиночном преобразовании я делаю следующее


Если я в автоматическом преобразовании сделаю перестарт, то будет то же самое что и при одиночном измерении. Если же я буду делать два чтения, то текст разрастётся ещё больше. Таким образом выигрыша по коду не получается. Выигрыша по точности - тоже. Так зачем же тогда?

Расчёт тактов у меня осуществляется очень точно. Правда не по прерыванию АЦП, а по таймеру. Давайте посчитаем вместе с вами. У меня прерывания идут с частотой 5кгц. То есть 200мкс. АЦП настроено на работу с частотой 16M/128 = 125kHz. Или 8мкс, то есть 25 тактов на прерывание. Естественно может быть +/-. Я пробовал от запуска до измерения 3 прерывания. Это 75 +/-. Согласно рассчётам я могу попасть на середину предыдущего преобразования (оно будет запорчено), и потом должно пройти 2 полных 25+13. То есть по максимуму 25+13+13 = 51 такт. Но у меня больше!!! Как минимум на одно! И, главное хомут возникает нерегулярно, а достаточно редко! Представляете что иногда проходит несколько минут!!!

Видимо при работе по прерыванию от АЦП гарантировано сбрасывается значение. А у меня работа несколько другая. У меня 3 канала АЦП + один частотный + 2 CAN. Я выставил канал - прочитал а потом к примеру перешёл на CAN, а АЦП - молотит. Через некоторое время, я, нечитая, перехожу на новый канал. Я не усматриваю здесь проблемы, но отрицать её - значит грешить против фактов!

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

Чушь! Вы чего-то не договариваете. Потому что ADMUX буферизован, и "слишком рано" записать нельзя. "Слишком поздно" - это можно, но тогда на следующем прерывании будет принят предыдущий канал.