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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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