|
Флаг ADIF регистра ADCSRA-в АЦП ATmega8-непонятно |
|
|
|
Sep 29 2013, 20:06
|

Гуру
     
Группа: Модератор FTP
Сообщений: 4 479
Регистрация: 20-02-08
Из: Москва
Пользователь №: 35 237

|
Цитата(V_G @ Sep 29 2013, 04:48)  Ну так я написал же, что содержимое регистров одинаковое. Откуда хотите, оттуда берите. А! Так они оба буферные! А я-то по вашему рассказу решила, что один из них простой, а второй буферный. Вот и пыталась выяснить, который из них кто. Так, значит, в любой момент времени я могу тот регистр прочитать (как двухбайтное слово) и никогда не может получиться так, что старший байт мне достанется от одного измерения, а младший от другого? Или я что-то должна сделать эдакое, чтобы оба байта гарантированно принадлежали одному измерению?
|
|
|
|
|
Sep 29 2013, 23:25
|

Профессионал
    
Группа: Свой
Сообщений: 1 818
Регистрация: 15-10-09
Из: Владивосток
Пользователь №: 52 955

|
Для полноты картины почитайте параграф "Accessing 16-bits Registers" в мануале по xmeg'ам. Коротко: при чтении сначала читайте младший байт, при этом в том же цикле старший байт будет занесен во временный регистр. Второй командой читайте старший байт, он будет считан из временного регистра. Перед чтением запретите прерывания, т.к. временный регистр на АЦП всего один, и в прерываниях могут быть команды доступа к 16-разрядным регистрам, которые испортят содержимое временного. Этот регистр доступен и сам по себе, называется ADCA_TEMP.
Эта тема - одна из причин, почему я предпочитаю ассемблер. Сишные программисты редко лезут в такие дебри. Была одна небольшая задачка (реализация ЧМ детектора на TigerSharс), которую я для теста написал на Си, чтобы не углубляться в архитектуру. Все быстро заработало, но для боевого применения в многоканальных системах обработки данных предпочту asm-реализацию с полным доступом ко всем вкусностям архитектуры TigerSharс. Хотя, возможно, такое возможно и на чистом Си, но с обязательным учетом особенностей аппаратной архитектуры.
|
|
|
|
|
Sep 30 2013, 00:31
|

Гуру
     
Группа: Модератор FTP
Сообщений: 4 479
Регистрация: 20-02-08
Из: Москва
Пользователь №: 35 237

|
Цитата(V_G @ Sep 30 2013, 03:25)  Коротко: при чтении сначала читайте младший байт, при этом в том же цикле старший байт будет занесен во временный регистр. Второй командой читайте старший байт, он будет считан из временного регистра. Но на C чтение двухбайтового значения именно так и происходит: Код // ADC_data = ADCA.CH1.RES; LDS R16, 556 LDS R17, (556+1) ... Я бы и на ассемблере короче не написала. Цитата(V_G @ Sep 30 2013, 03:25)  Перед чтением запретите прерывания, т.к. временный регистр на АЦП всего один, и в прерываниях могут быть команды доступа к 16-разрядным регистрам, которые испортят содержимое временного. Этот регистр доступен и сам по себе, называется ADCA_TEMP. А вот это непонятно. Почему команды доступа к 16-разрядным регистрам в прерываниях должны портить именно ADCA_TEMP? А если они к АЦП никак не относятся (скажем, это 16-разрядный регистр таймера), то содержимое ADCA_TEMP тоже будет угроблено? Или вы имели в виду только обращения к 16-разрядным регистрам других каналов АЦП? На счет запрета прерывания тоже имею вопрос: годится ли вместо пары STI/CLI запись CCP=0xD8, или protected IO register не может быть в этом деле помощником? Говорят, что он на 4 такта работу блокирует, там может быть этого хватит?
|
|
|
|
|
Sep 30 2013, 02:14
|

Профессионал
    
Группа: Свой
Сообщений: 1 818
Регистрация: 15-10-09
Из: Владивосток
Пользователь №: 52 955

|
Цитата(Xenia @ Sep 30 2013, 10:31)  Почему команды доступа к 16-разрядным регистрам в прерываниях должны портить именно ADCA_TEMP? А если они к АЦП никак не относятся (скажем, это 16-разрядный регистр таймера), то содержимое ADCA_TEMP тоже будет угроблено? Или вы имели в виду только обращения к 16-разрядным регистрам других каналов АЦП? Если в прерываниях доступ к 16-разрядным регистрам AЦП не предполагается (или если само считывание идет в прерывании высокого приоритета), то можно и не запрещать прерывания, т.к. у других блоков свои временные регистры. Тем не менее, если процедуры других прерываний достаточно длинные, я бы запретил прерывания при чтении АЦП от греха подальше. Цитата(Xenia @ Sep 30 2013, 10:31)  На счет запрета прерывания тоже имею вопрос: годится ли вместо пары STI/CLI запись CCP=0xD8, или protected IO register не может быть в этом деле помощником? Говорят, что он на 4 такта работу блокирует, там может быть этого хватит? Вроде особых противопоказаний нет, но надо смотреть, какой код сгенерирует компилятор (включая запись CCP). Тут где-то обсуждалось, что иногда вставляется что-то типа цепочки RJMP next_addr которые могут расходовать драгоценные защищенные циклы.
|
|
|
|
|
Oct 1 2013, 08:23
|
Участник

Группа: Участник
Сообщений: 29
Регистрация: 25-01-13
Из: Брянск
Пользователь №: 75 345

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

Группа: Участник
Сообщений: 29
Регистрация: 25-01-13
Из: Брянск
Пользователь №: 75 345

|
Цитата(V_G @ Oct 1 2013, 12:53)  Если преобразование еще не завершено, то и флаг ADIF не выставлен, будет читаться нулем хоть со сбросом, хоть без сброса. Вот если преобразование завершено то прочитав 4бит ADCSRA там будет лог.1 ,далее я записываю в этот бит лог.1 -значит этот бит я сбрасываю и уже следующей командой прочитав этот бит то там будет лог.0 и завершение следующего преобразования установит в лог.1 этот бит(бит ADIF , 4 бит. регистра ADCSRA).Мне непонятно-вроде я записываю лог.1 ,а считываю оттуда лог.0
Сообщение отредактировал serj32 - Oct 1 2013, 12:12
|
|
|
|
|
Oct 1 2013, 12:26
|

Гуру
     
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095

|
QUOTE (serj32 @ Oct 1 2013, 14:03)  Мне непонятно-вроде я записываю лог.1 ,а считываю оттуда лог.0 Это очень хорошая логика. Не конкретно в этом случае, а для регистров с многими флагами. Прочитав этот регистр, проанализировав и обработав выставленные флаги вы можете записать то считанное число обратно и сбросятся только те флаги, которые вы уже обработали. А флаги, которые взвелись после момента чтения останутся нетронутыми и вы сможете получить их при следующем чтении. Вы можете даже сразу записать считанное из регистра число обратно (сбросив выставленные флаги) и дальше работать со считанной копией. И уже к концу обработки в регистре флагов могут появиться те же флаги уже от нового события, вы их не потеряете и не затрете случайно. У AVR по такой логике сделаны все программно сбрасываемые флаги.
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
Oct 1 2013, 14:17
|
Участник

Группа: Участник
Сообщений: 29
Регистрация: 25-01-13
Из: Брянск
Пользователь №: 75 345

|
Цитата(V_G @ Oct 1 2013, 12:53)  Если преобразование еще не завершено, то и флаг ADIF не выставлен, будет читаться нулем хоть со сбросом, хоть без сброса. Ну а если предыдущие преобразования установили ADIF в лог.1 , а преобразование происходящее в настоящий момент ещё не закончено и сброса ADIF не происходило то в ADIF будет лог.1.Наверно будет так.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|