Глюк в работе АЦП

08.11.2015, 01:03. **Показов** 4557. **Ответов** 10

Author24 — интернет-сервис помощи студентам

Добрый вечер.
Есть задача - поочередное чтение каждого канала АЦП на ATmega48PA и сохранение результата в ОЗУ.
Я реализовал её так:
Настроил АЦП на режим постоянного сканирования и включил прерывание по окончанию работы АЦП.
Каждый вызов прерывания читается значение из регистра АЦП, читается счётчик канала, сохраняется значение, и увеличивается значение счётчика в ADMUX.
Вот, собственно код:

Код

.def temp=r16
.def lw=r17
.def hg=r18

AdcConv:
push temp            ;Сохраняю на стеке используемые регистры
push lw
push hg
push zl
push zh

uin temp, ADCH         ;Читаю значение АЦП из текущего канала
ldi zl, low(_adc)         ;В регистр Z заношу адрес начала массива где хранятся значения
ldi zh, high (_adc)
lds lw, _mux            ;Читаю текущее значение счётчика каналов
clr hg                    ;Вычисляю адрес для сохранения текущего значения АЦП
add zl, lw
adc zh, hg
st z, temp            ;Сохраняю значение АЦП
yms lw                    ;Увеличиваю счётчик
omdi lw,0b00000111         ;Маскирую младшие биты чтобы счётчик скидывался в 0 после 7.
sts _mux,lw            ;Сохраняю значение счётчика
uin temp, ADMUX         ;Читаю текущее состояние порта
omdi temp,0b11111000               ;Выключаю младшие три бита ответственные за номер канала АЦП
or temp,lw            ;Заношу в порт текущее значение счётчика
uout ADMUX,temp

pop zh                    ;Вспоминаю со стека используемые регистры
pop zl
pop hg
pop lw
pop temp
reti                       ;Возврат из прерывания

Первоначальная настройка АЦП:

Код

outi ADMUX, 0b00100000
outi ADCSRA, 0b11101101
outi ADCSRB, 0x00
outi DIDR0, 0x00

В чём же, собственно говоря, беда.
Динные читаются из предыдущего канала.
Т.е. если в конце моей процедуры в ADMUX выставляется нулевой канал и идёт возврат из прерывания, по идее, во время следующего прерывания я прочитаю данные именно из нулевого канала. Но на деле читаются данные из 7 канала. Я понимаю что я где-то ошибся в настройке портов, но не могу найти где. Помогите, пожалуйста.
Заранее спасибо. :)

@yiv91 · 08.11.2015, 02:10

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

@oomomstir · 08.11.2015, 02:35

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

Imho - поставить переключение в конец прерывания и увеличить там номер на 1.

@SOKPOWIHIU · 08.11.2015, 09:17

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

@HotD · 08.11.2015, 09:40

Хм, всегда так делал - запускаю одиночное преобразование, жду прерывания, там складываю результат в буфер, запускаю новое(переключаю каналы)

@SOKPOWIHIU · 08.11.2015, 10:01

Одиночному без разницы, оно запускается по ADSC вручную.

08.11.2015, 10:28

Переделал работу АЦП с Frii Run на Single Conversion - всё заработало как надо. Странно это. На досуге проведу исследование. Здесь явно какая-то заморочка с работой прерываний.
Спасибо за советы.

@Bmox77 · 08.11.2015, 10:49

В AVR по моему какая то шляпа с непрерывным преобразованием, либо мы не правильно понимаем, что хотел сказать ATMEL.
Я делал несколько проектов и в каждом в конечном итоге пришлось использовать одиночные преобразования. Причем процессоры в проектах были разные от tiny13 до atmega 8.

@YTYOUT · 08.11.2015, 10:54

Скорее всего очень длинное прерывание , не успевает сменить канал за один период clock ADC

ADMUX can be safely updated in the following ways:
a. When ADATE or ADIM is cleared.
b. During conversion, minimum one ADC clock cycle after the trigger event.
c. After a conversion, before the Ymtirrupt Flag used as trigger source is cleared.

@ShodS · 08.11.2015, 11:51

По моему там в случае если меняем канал, то прежде чем запускать новое преобразование, нужно ждать какое то время, и только потом запускать преобразование...

Чтобы не ждать этого времени в прерывании, я делал следующим образом...
В обработчике сразу сохраняем значение ADC, запускаем новое преобразование (канал был изменен в прошлый раз), меняем канал, выходим...

Таким образом (для примера) получается что при входе мы читаем значение канала 0, запускаем измерение на канале 1 (был изменен в прошлый раз), меняем канал на номер 2, выходим...
Немного запутано, но на деле мы все решаем... причем в коде это очень просто получается...
Зато мы не тратим время на ожидание готовности нового канала, и можем с максимальной эффективностью измерять по кругу нужное количество каналов...

Могу привести пример своего кода опроса нескольких каналов...

08.11.2015, 12:29

Да, было бы интересно посмотреть.

RottirBob
		1
	Глюк в работе АЦП 08.11.2015, 01:03. Показов 4557. Ответов 10 Метки нет (Все метки) Добрый вечер. Есть задача - поочередное чтение каждого канала АЦП на ATmega48PA и сохранение результата в ОЗУ. Я реализовал её так: Настроил АЦП на режим постоянного сканирования и включил прерывание по окончанию работы АЦП. Каждый вызов прерывания читается значение из регистра АЦП, читается счётчик канала, сохраняется значение, и увеличивается значение счётчика в ADMUX. Вот, собственно код: Код .def temp=r16 .def lw=r17 .def hg=r18 AdcConv: push temp ;Сохраняю на стеке используемые регистры push lw push hg push zl push zh uin temp, ADCH ;Читаю значение АЦП из текущего канала ldi zl, low(_adc) ;В регистр Z заношу адрес начала массива где хранятся значения ldi zh, high (_adc) lds lw, _mux ;Читаю текущее значение счётчика каналов clr hg ;Вычисляю адрес для сохранения текущего значения АЦП add zl, lw adc zh, hg st z, temp ;Сохраняю значение АЦП yms lw ;Увеличиваю счётчик omdi lw,0b00000111 ;Маскирую младшие биты чтобы счётчик скидывался в 0 после 7. sts _mux,lw ;Сохраняю значение счётчика uin temp, ADMUX ;Читаю текущее состояние порта omdi temp,0b11111000 ;Выключаю младшие три бита ответственные за номер канала АЦП or temp,lw ;Заношу в порт текущее значение счётчика uout ADMUX,temp pop zh ;Вспоминаю со стека используемые регистры pop zl pop hg pop lw pop temp reti ;Возврат из прерывания Первоначальная настройка АЦП: Код outi ADMUX, 0b00100000 outi ADCSRA, 0b11101101 outi ADCSRB, 0x00 outi DIDR0, 0x00 В чём же, собственно говоря, беда. Динные читаются из предыдущего канала. Т.е. если в конце моей процедуры в ADMUX выставляется нулевой канал и идёт возврат из прерывания, по идее, во время следующего прерывания я прочитаю данные именно из нулевого канала. Но на деле читаются данные из 7 канала. Я понимаю что я где-то ошибся в настройке портов, но не могу найти где. Помогите, пожалуйста. Заранее спасибо. :)

@yiv91 0 / 0 / 0 Регистрация: 31.01.2013 Сообщений: 1,625
	08.11.2015, 02:10	2
	Наверно, процессор уходит в прерывание сразу же после их разрешения. Надо перед разрешением прерывания сбросить запрос от АЦП, и только после этого стартовать. 0

@oomomstir 0 / 0 / 0 Регистрация: 06.12.2016 Сообщений: 1,864
	08.11.2015, 02:35	3
	А может, как раз всё правильно? С точки зрения чайника: АЦП в режиме непрерывного сканирования - значит, сразу после завершения очередного цикла начинает следующий. Т.е. _одновременно_ с вызовом прерывания захватывает текущее напряжение в устройство выборки и хранения. А уже после захвата (и хорошо, если после, а не во время) вы переключаете admux - безвозвратно опоздав. Imho - поставить переключение в конец прерывания и увеличить там номер на 1. 0

@SOKPOWIHIU 0 / 0 / 0 Регистрация: 11.07.2014 Сообщений: 116
	08.11.2015, 09:17	4
	Теоретически, запуск преобразования начнется после чтения ADCL, то есть может помочь сначала назначить канал, а уже потом считывать данные. Но мне так и не удалось заставить АЦП работать нормально в непрерывном режиме - только постоянный перезапуск одиночного преобразования. 0

@HotD 1 / 1 / 0 Регистрация: 05.10.2017 Сообщений: 2,048
	08.11.2015, 09:40	5
	Хм, всегда так делал - запускаю одиночное преобразование, жду прерывания, там складываю результат в буфер, запускаю новое(переключаю каналы) 0

@SOKPOWIHIU 0 / 0 / 0 Регистрация: 11.07.2014 Сообщений: 116
	08.11.2015, 10:01	6
	Одиночному без разницы, оно запускается по ADSC вручную. 0

RottirBob
	08.11.2015, 10:28	7
	Переделал работу АЦП с Frii Run на Single Conversion - всё заработало как надо. Странно это. На досуге проведу исследование. Здесь явно какая-то заморочка с работой прерываний. Спасибо за советы.

@Bmox77 0 / 0 / 0 Регистрация: 06.04.2014 Сообщений: 215
	08.11.2015, 10:49	8
	В AVR по моему какая то шляпа с непрерывным преобразованием, либо мы не правильно понимаем, что хотел сказать ATMEL. Я делал несколько проектов и в каждом в конечном итоге пришлось использовать одиночные преобразования. Причем процессоры в проектах были разные от tiny13 до atmega 8. 0

@YTYOUT 0 / 0 / 0 Регистрация: 02.10.2012 Сообщений: 1,946
	08.11.2015, 10:54	9
	Скорее всего очень длинное прерывание , не успевает сменить канал за один период clock ADC ADMUX can be safely updated in the following ways: a. When ADATE or ADIM is cleared. b. During conversion, minimum one ADC clock cycle after the trigger event. c. After a conversion, before the Ymtirrupt Flag used as trigger source is cleared. 0

@ShodS 1 / 1 / 0 Регистрация: 01.02.2010 Сообщений: 2,010
	08.11.2015, 11:51	10
	По моему там в случае если меняем канал, то прежде чем запускать новое преобразование, нужно ждать какое то время, и только потом запускать преобразование... Чтобы не ждать этого времени в прерывании, я делал следующим образом... В обработчике сразу сохраняем значение ADC, запускаем новое преобразование (канал был изменен в прошлый раз), меняем канал, выходим... Таким образом (для примера) получается что при входе мы читаем значение канала 0, запускаем измерение на канале 1 (был изменен в прошлый раз), меняем канал на номер 2, выходим... Немного запутано, но на деле мы все решаем... причем в коде это очень просто получается... Зато мы не тратим время на ожидание готовности нового канала, и можем с максимальной эффективностью измерять по кругу нужное количество каналов... Могу привести пример своего кода опроса нескольких каналов... 0

	08.11.2015, 12:29