Флаг ADIF регистра ADCSRA-в АЦП ATmega8-непонятно Опции

[serj32]

Здравствуйте.Вот если перевести АЦП в непрерывный режим флаг ADIF установится сразу после окончания преобразования,но непонятно когда он сбросится , а ведь на очереди очередное преобразование.
Этот флаг необходимо програмно сбрасывать ,чтобы увидеть очередное преобразование.В даташите не увидел ответа.Благодарю всех ответившим.

[ARV]

он сбросится аппаратно в момент перехода на обработчик прерывания

[serj32]

он сбросится аппаратно в момент перехода на обработчик прерывания

Спасибо понятно.А можно ли считывать результат АЦП в любое время (Режим непрерывного преобразования) при считывании результата АЦП
ну вначале младший ADCL затем ADCH, при считывании младшего старший будет заблокирован пока и он не будет прочитан.И мне не надо ожидать окончания преобразования просто устройство примитивное-индикатор на 8 светодиодов.Для обучения.Спасибо.

[RabidRabbit]

В том экземпляре даташита, что есть у меня, в описании флага ADIF сказано:
Alternatively, ADIF is cleared by writing a logical one to the flag.
А в непрерывном режиме без использования прерываний можете спокойно читать из регистра ADC в любое время

[ARV]

для обучения лучше делать правильно, а не "как-нибудь". считывать ADC до завершения преобразования все равно что определять время по компасу - оно то, конечно, можно, но бессмысленно...

[serj32]

для обучения лучше делать правильно, а не "как-нибудь". считывать ADC до завершения преобразования все равно что определять время по компасу - оно то, конечно, можно, но бессмысленно...

А если так.Дождаться когда завершится преобразование-Флаг ADIF установится,далее програмно сбросим ADIF и "поработаем" со светодиодами потом снова на метку-("Дождаться когда завершится преобразование-Флаг ADIF установится")
Или по прерыванию от АЦП и уже обработчик прерывания будет зажигать светодиоды.

[V_G]

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

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

А если так.Дождаться когда завершится преобразование-Флаг ADIF установится,далее програмно сбросим ADIF и "поработаем" со светодиодами

Именно так и нужно делать (если без прерываний). Или так: Проверили флаг ADIF, если он еще не установлен - пошли, недолго поделали что-нибудь полезное. Потом снова вернулись на проверку флага.

[RabidRabbit]

для обучения лучше делать правильно, а не "как-нибудь". считывать ADC до завершения преобразования все равно что определять время по компасу - оно то, конечно, можно, но бессмысленно...

Для задачи топикстартера - вовсе не бессмысленно - читаем непрерывно, непрерывно индицируем, и нам пофигу, что мы 10 (100 или 1000) раз отобразили значение предыдущего измерения

[ARV]

Для задачи топикстартера - вовсе не бессмысленно - читаем непрерывно, непрерывно индицируем, и нам пофигу, что мы 10 (100 или 1000) раз отобразили значение предыдущего измерения

вы уверены, что считывая регистр ADC до завершения очередного преобразования мы получим результат предыдущего завершенного преобразования?

[Xenia]

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

Подскажите, пожалуйста, как называются эти "специальные буферные регистры"?
Кандидатов на эту роль вижу два:
ADCA.CH1.RES
ADCA.CH1RES
Который из?

[V_G]

Названия регистров различаются в Си и ассемблере (я из тех извращенцев, что предпочитают ассемблер). Тем не менее, указанные Вами регистры имеют разные адреса, и в этом заключается фишка (содержимое регистров одинаковое).
Конкретно, в ассемблерном варианте, адреса регистров, принадлежащих одному каналу:
ADCA_CH0_CTRL,
ADCA_CH0_MUXCTRL,
ADCA_CH0_INTCTRL,
ADCA_CH0_INTFLAGS,
ADCA_CH0_RES,
идут подряд друг за другом, позволяя организовать обращение к общему блоку регистров канала (например, через DMA).

С другой стороны, адреса регистров
ADCA_CH0RES,
ADCA_CH1RES,
ADCA_CH2RES,
ADCA_CH3RES
также идут последовательно, что позволяет организовать блоковое обращение к регистрам результата всех каналов.

[Xenia]

Названия регистров различаются в Си и ассемблере (я из тех извращенцев, что предпочитают ассемблер). Тем не менее, указанные Вами регистры имеют разные адреса, и в этом заключается фишка (содержимое регистров одинаковое).
Конкретно, в ассемблерном варианте, адреса регистров, принадлежащих одному каналу:
...
ADCA_CH0_RES,
идут подряд друг за другом, позволяя организовать обращение к общему блоку регистров канала (например, через DMA).

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

Я не об этом спрашивала. Меня интересует, откуда брать готовые данные. Из ADCA_CH0_RES или из ADCA_CH0RES? Тем более, если, по вашим словам, это имена не синонимы, а "имеют разные адреса".

[V_G]

Ну так я написал же, что содержимое регистров одинаковое. Откуда хотите, оттуда берите.
Этот вопрос я задавал еще в конце 2008 в техподдержку Атмела. Вот их ответ:

The two registers in ATxmega64A3def.inc (ADCA_CH0RES/ADCA_CH0_RES) are actually holding the same result from the ADC. The reason for having this is to enable easier C-code implementation.

[RabidRabbit]

вы уверены, что считывая регистр ADC до завершения очередного преобразования мы получим результат предыдущего завершенного преобразования?

В случае с одним каналом - да, абсолютно уверен. А что, в регистрах ADC есть битовый флаг "данные в регистре ADC протухли и содержат случайный набор битов"?

[Xenia]

Ну так я написал же, что содержимое регистров одинаковое. Откуда хотите, оттуда берите.

А! Так они оба буферные! А я-то по вашему рассказу решила, что один из них простой, а второй буферный. Вот и пыталась выяснить, который из них кто.

Так, значит, в любой момент времени я могу тот регистр прочитать (как двухбайтное слово) и никогда не может получиться так, что старший байт мне достанется от одного измерения, а младший от другого? Или я что-то должна сделать эдакое, чтобы оба байта гарантированно принадлежали одному измерению?

[V_G]

Для полноты картины почитайте параграф "Accessing 16-bits Registers" в мануале по xmeg'ам.
Коротко: при чтении сначала читайте младший байт, при этом в том же цикле старший байт будет занесен во временный регистр. Второй командой читайте старший байт, он будет считан из временного регистра. Перед чтением запретите прерывания, т.к. временный регистр на АЦП всего один, и в прерываниях могут быть команды доступа к 16-разрядным регистрам, которые испортят содержимое временного. Этот регистр доступен и сам по себе, называется ADCA_TEMP.

Эта тема - одна из причин, почему я предпочитаю ассемблер. Сишные программисты редко лезут в такие дебри.
Была одна небольшая задачка (реализация ЧМ детектора на TigerSharс), которую я для теста написал на Си, чтобы не углубляться в архитектуру. Все быстро заработало, но для боевого применения в многоканальных системах обработки данных предпочту asm-реализацию с полным доступом ко всем вкусностям архитектуры TigerSharс. Хотя, возможно, такое возможно и на чистом Си, но с обязательным учетом особенностей аппаратной архитектуры.

[Xenia]

Коротко: при чтении сначала читайте младший байт, при этом в том же цикле старший байт будет занесен во временный регистр. Второй командой читайте старший байт, он будет считан из временного регистра.

Но на C чтение двухбайтового значения именно так и происходит:

Код

// ADC_data = ADCA.CH1.RES;
LDS     R16, 556
LDS     R17, (556+1)
...

Я бы и на ассемблере короче не написала.

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

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

На счет запрета прерывания тоже имею вопрос: годится ли вместо пары STI/CLI запись CCP=0xD8, или protected IO register не может быть в этом деле помощником? Говорят, что он на 4 такта работу блокирует, там может быть этого хватит?

[V_G]

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

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

На счет запрета прерывания тоже имею вопрос: годится ли вместо пары STI/CLI запись CCP=0xD8, или protected IO register не может быть в этом деле помощником? Говорят, что он на 4 такта работу блокирует, там может быть этого хватит?

Вроде особых противопоказаний нет, но надо смотреть, какой код сгенерирует компилятор (включая запись CCP). Тут где-то обсуждалось, что иногда вставляется что-то типа цепочки RJMP next_addr которые могут расходовать драгоценные защищенные циклы.

[serj32]

Хотел бы уточнить по флагу ADIF регистра ADCSRA.Вот если сбросить ADIF -запишу лог.1 в 4 бит регистра ADCSRA и когда буду читать этот же бит следующей командой то будет считан уже лог.0-(будем считать ,что преобразование ещё не завершено).Правильны ли мои рассуждения ? Зараннее всем благодарен.

[V_G]

Если преобразование еще не завершено, то и флаг ADIF не выставлен, будет читаться нулем хоть со сбросом, хоть без сброса.

[RabidRabbit]

Вот если сбросить ADIF -запишу лог.1 в 4 бит регистра ADCSRA и когда буду читать этот же бит следующей командой то будет считан уже лог.0-(будем считать ,что преобразование ещё не завершено).Правильны ли мои рассуждения ?

Да, совершенно верно.

[serj32]

Если преобразование еще не завершено, то и флаг ADIF не выставлен, будет читаться нулем хоть со сбросом, хоть без сброса.

Вот если преобразование завершено то прочитав 4бит ADCSRA там будет лог.1 ,далее я записываю в этот бит лог.1 -значит этот бит я сбрасываю и уже следующей командой прочитав этот бит то там будет лог.0 и
завершение следующего преобразования установит в лог.1 этот бит(бит ADIF , 4 бит. регистра ADCSRA).Мне непонятно-вроде я записываю лог.1 ,а считываю оттуда лог.0

Сообщение отредактировал serj32 - Oct 1 2013, 12:12

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

Мне непонятно-вроде я записываю лог.1 ,а считываю оттуда лог.0

Это очень хорошая логика. Не конкретно в этом случае, а для регистров с многими флагами. Прочитав этот регистр, проанализировав и обработав выставленные флаги вы можете записать то считанное число обратно и сбросятся только те флаги, которые вы уже обработали. А флаги, которые взвелись после момента чтения останутся нетронутыми и вы сможете получить их при следующем чтении. Вы можете даже сразу записать считанное из регистра число обратно (сбросив выставленные флаги) и дальше работать со считанной копией. И уже к концу обработки в регистре флагов могут появиться те же флаги уже от нового события, вы их не потеряете и не затрете случайно. У AVR по такой логике сделаны все программно сбрасываемые флаги.

[serj32]

Если преобразование еще не завершено, то и флаг ADIF не выставлен, будет читаться нулем хоть со сбросом, хоть без сброса.

Ну а если предыдущие преобразования установили ADIF в лог.1 , а преобразование происходящее в настоящий момент ещё не закончено и сброса ADIF не происходило то в ADIF будет лог.1.Наверно будет так.

[ILYAUL]

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