Ассемблер (ASM) для AVR в вопросах и ответах

[strengerst]

Спасибо ошибку устранил:
start3:
CLV;
//Считываем данные АЦП
in R17, ADCL;
in R16, ADCH;
//Записываем считанные данные в регистр.
out OCR0A, R16;
reti;

Но нечего не поменялось протеус также выдает не изменяемые по скважности импульсы. В чем может быть еще причина.

[dgrett]

start3 выполняется и при ADC complete и при Timer0 overflow.
В overflow попробуйте снова запустить конверсию. Не углублялся в режимы таймера, нзн.(времени сейчас нет)

[Ivanoff-iv]

По идее конверсию надо запускать по прерыванию окончания конверсии и всё (ну и один раз при старте, чтоб закрутилось) а в прерывании от таймера я не знаю что нужно делать (в смысле можно ничего не делать и вообще это прерывание запретить).
тогда в прерывании завершения конверсии будет:
1) получение данных преобразования,
2) запись их в регистр сравнения таймера и
3) запуск нового АД преобразования.
(изменение регистра сравнения и вызывает изменение уровня ШИМ)

[dgrett]

Точно, сморозил я, пардон

[strengerst]

Добавлено after 1 minute 4 seconds:
Я вот так вот сделал и все заработало
start3:
CLV;
//Считываем данные АЦП
in R17, ADCL; //ADCH - записываем, ADCL - можно не записывать
in R16, ADCH;
//Записываем считанные данные в регистр.
out OCR0A, R16;
SBI ADCSRA, ADSC;//Запуск преобразования
reti;

Получается что запуск преобразования нужно запускать каждый раз когда считываем данные с ADCH?
Я то думал что при выбора режима - непрерывное преобразования, этого делать не надо.

[dgrett]

С Мегой8 у меня тоже не получилось, запускаю преобразование каждый раз. Не пробовал, может надо было по человечески прочитать ADC, по ДШ?

[strengerst]

Всем спасибо за уделенное время и помощь. Буду пробовать дальше.

[Z_h_e]

Получается что запуск преобразования нужно запускать каждый раз когда считываем данные с ADCH?
Я то думал что при выбора режима - непрерывное преобразования, этого делать не надо.

A conversion will be triggered by the
rising edge of the selected Interrupt Flag... ...Switching to Free Running mode (ADTS[2:0]=0) will not cause a trigger event, even if the ADC
Interrupt Flag is set.

Сбрасывайте флаг ADIF и все само зажжжжужит. А лучше чтобы сбрасывало прерывание от АЦП автоматом.

Спойлер

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

Вроде там не должно быть каких-то нюансов.

[Гефестион]

Здравствуйте!

Недавно начал заниматься программированием AVR, сейчас тренируюсь на tiny2313 на простых задачах (светодиоды, кнопки, энкодер, UART).
Написал простейшую программку, которая по внешним прерываниям опрашивает энкодер, инкрементирует/декрементирует значение в регистре и сразу отправляет по UART. Общий вывод энкодера на земле, каналы энкодера подключены ко входам для внешних прерываний INT0, INT1, включены внутренние подтягивающие резисторы. Использую лишь одно из этих прерываний.

Алгоритм простой:
1) Настраиваю прерывание по срезу импульса на INT0
2) Соответственно, когда возникло прерывание, точно известно, что первый канал энкодера переключился из 1 в 0.
3) Проверяю состояние второго канала, который подключен на PD3.
4) Если энкодер вращается в одну сторону (например, по ч.с.), то там будет 1, делаю инкремент регистра Steps.
5) Если энкодер вращается в другую сторону (против ч.с.), то там будет 0, делаю декремент регистра Steps.
5) Посылка Steps по UART.
6) Выход из прерывания.

В основном цикле ничего нет, только "заглушка" rjmp pc.

Проблема в том, что независимо от направления вращения энкодера получается только инкремент (или только декремент, если переход не по sbis, а по sbic). Как будто второй канал энкодера постоянно находится в 1.

Самые очевидные причины проверил:
1) Энкодер исправен, проверял подключением к нему светодиодов и медленным вращением.
2) Каналы энкодера подключены именно к ножкам PD2 (INT0), PD3 (INT1)
3) Эти ножки порта настроены на ввод, подтяжки включены.
4) Прерывание по INT0 разрешено, по INT1 запрещено.
5) Неисправен вход PD3? Пробовал подключать второй канал энкодера на PA0 - результат такой же.

Код:

Int_Ext0:  PUSHF

                cli ; чтобы дребезг контактов не вызвал ещё одно прерывание

           sbis portD,3
           breq Decr
           inc Steps
           rjmp uart_snt
Decr:           dec Steps
   
uart_snt:   sbis UCSRA,UDRE ; Пропуск, если нет флага готовности
           rjmp uart_snt    ; ждем готовности - флага UDRE
                out UDR,Steps   ; отправляем байт

                sei
   
                POPF
           reti

PUSHF, POPF - макросы для сохранения SREG в стек и извлечения его оттуда. Прописаны в самом начале, до таблицы векторов прерываний.
Код пишу в универсальном редкаторе RJ Editor, компилятор tavrasm, загрузчик AVR Dude, программатор USB tiny (самодельный).

П.С. Сигналы на каналах энкодера выглядят так:

[Ivanoff-iv]

Если рассматривается только восходящий фронт - энкодер легко обмануть покачиванием около одного фронта (обозначенного красной стрелкой) покачиваемый около одной точки энкодер будет уверенно считать...

[akl]

Команда( ы) SBIS, SBIC, SBRS, SBRC не работают по флагам. CLI в обработчике бессмысленен

[trofim2]

Что значит:

akl писал(а):

Команда( ы) SBIS, SBIC, SBRS, SBRC не работают по флагам.

[akl]

Например, SBIS.

Вложения

SBIS.PNG

(46.43 KiB) Скачиваний: 511

[BOB51]

О том же и разговор
бит адресуемого порта тестируется на соответствие и затем выполняется условный переход.
Собственно бит и является в данном случае флагом.
Это SBIS или SBIC для регистров УВВ (0-31)
и SBRC или SBRS для работы с бит-флагами регистрового файла.
Другое дело, что с битами - флагами прерываний и флагами SREG вышеприведенные команды работать не будут.
(Опять же только в случае, когда те флажки находятся в регистрахРСФ/УВВ с адресами за пределами 0-31).

[Гефестион]

Блин, кажется, я понял в чём ошибка! Вместо sbis portD должно быть sbis pinD. И, конечно, rjmp Decr

Добавлено after 3 minutes 45 seconds:

akl писал(а):

CLI в обработчике бессмысленен

Я так понимаю, что из-за дребезга контактов прерывание может возникнуть несколько раз. Поэтому я их запретил на время обработки энкодера.

Последний раз редактировалось Гефестион Чт янв 18, 2018 13:50:16, всего редактировалось 1 раз.

[BOB51]

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

[viiv]

Гефестион писал(а):

Я так понимаю, что из-за дребезга контактов прерывание может возникнуть несколько раз. Поэтому я их запретил на время обработки энкодера.

В обработчике прерывания и так запрещены: при "влете" в обработчик прерывания запрещаются (аппаратно), а команда RETI разрешает прерывния.

[Demiurg]

Да, вместо portx нужно писать pinx.
При переходе на вектор прерывания флаг I аппаратно сбрасывается. Поэтому в обработчике команда cli бессмысленна.

А поскольку процесс чтения также не мгновенный...
Вобщем лучше сначала считать данные во временный регистр, а уж затем делать вывод о состоянии соответствующего бита

Поясните ваш поток сознания.

Команду reti можно использовать не только в обработчиках прерывания. Также никто не запрещает использовать команду ret при выходе из обработчика прерывания. Если не нужны прерывания.

Последний раз редактировалось Demiurg Чт янв 18, 2018 14:01:04, всего редактировалось 2 раз(а).

[Ivanoff-iv]

из-за дребезга контактов прерывание может возникнуть несколько раз.

тогда уж флаг прерывания чистить...

[Гефестион]

Ivanoff-iv писал(а):

из-за дребезга контактов прерывание может возникнуть несколько раз.

тогда уж флаг прерывания чистить...

Вы имеете ввиду флаг разрешения конкретного прерывания?

Последний раз редактировалось Гефестион Чт янв 18, 2018 14:16:36, всего редактировалось 2 раз(а).