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

[serj32]

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

[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 которые могут расходовать драгоценные защищенные циклы.