Золотовский Д.В. Учебный курс для новичков по микроконтроллерам AVR. Часть 1
Подождите немного. Документ загружается.
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
LDI OSRG,63 ;63 - (0.25Y) вычитаем
SUB OSRG,ACC
RET ; Выходим с результатом в OSRG
; X= 150 - Y
Near: LDI OSRG,150
SUB OSRG,ACC ; 150-Y Не зря мы в АСС скопировали
RET ; Выходим с результатом в OSRG
; X = 63+255-4Y
Far: LSL OSRG ; Y*4 сдвигом умножаем на 4
LSL OSRG
COM OSRG ; 255-(Y*4) вычли
SUBI OSRG,-63 ; 63+(255-(Y*4)) сложили
RET ; Выходим с результатом в OSRG
TooFar: LDI OSRG,255 ; Совсем далеко? Ну и думать нечего!
RET ; Выходим с результатом в OSRG
Итого, 52 байта на весь экшн. Причем на самую длинную ветвь отводится
всего 10 тактов. Красота! Можно даже в прерывании обрабатывать!
Да, к вопросу о том, зачем мне понадобилось растягивать диапазон до 255
попугаев. Дело в том, что несколько повышается точность выхода, но правда
увеличивается уровень болтанки сигнала. Т.к. ИК порой выдает много
мусора, особенно на дальних расстояниях, когда у него вытягивается
характеристика и малейшие колебания превращаются в мощный расколбас
выходного значения.
Так вот, когда у нас диапазон большой, то можно нажрать этой каши
побольше, потом усреднить и сразу же поделить на попугаев (в том же
сдвиге). На выходе, по идее, получим очень стабильные и красивые
сантиметры. Впрочем, это только первичный экспериментальный прогон. Я
толком еще не тестировал, но первые опыты уже дали более-менее
адекватные результаты.
AVR. Учебный Курс. Инкрементальный энкодер.
Энкодер это всего лишь цифровой датчик угла поворота, не более того.
Энкодеры бывают абсолютные — сразу выдающие двоичный код угла и
инкрементальные, дающие лишь указание на направление и частоту
вращения, а контроллер, посчитав импульсы и зная число импульсов на
оборот, сам определит положение.
Если с абсолютным энкодером все просто, то с инкрементальным бывают
сложности. Как его обрабатывать?
С энкодера выходят два сигнала А и В, сдвинутых на 90 градусов по фазе,
выглядит это так:
А дальше пляшем от типа энкодера. А они бывают разные.
Механический.
Тебе, скорей всего, в руки попадется либо механический, либо оптический с
малой дискретностью. Выдающий, в лучшем случае, пару десятков
импульсов на оборот. Устроен он просто — две контактные группы
замыкаются в нужном порядке в зависимости от вращения.
В оптическом же может быть два фонаря и два фотодиода, святящие через
диск с прорезями (шариковая мышка, ага. Оно самое).
Механический подключается совсем просто центральный на землю, два
крайних (каналы) на подтянутые порты. Я, для надежности, подключил
внешнюю подтяжку. Благо мне на Pinboard для этого только парой тумблеров
щелкнуть(см.рис.). Оптический подключается в зависимости от типа
оптодатчика, обычно там стоит два фотодиода с общим анодом.
Обычно, все пытаются работать с ними через прерывания INT, но этот метод
так себе. Проблема тут в дребезге - механические контакты, особенно после
длительного пользования, начинают давать сбои и ложные импульсы в
момент переключения. А прерывание на эти ложные импульсы все равно
сработает и посчитает что нибудь не то. Лучше считать не импульсы, а
состояния.
A:0 0 1 1 0 0 1 1 0 0 1 1 0
B:1 0 0 1 1 0 0 1 1 0 0 1 1
Метод прост:
Подставим нули и единички, в соответствии с уровнем сигнала и запишем
последовательность кода (см. рис. выше).
Если A и B идут на одни порт контроллера (например на A=PB0 B=PB1), то
при вращении энкодера у нас возникает меняющийся код:
11 = 3
10 = 2
00 = 0
01 = 1
11 = 3
Теперь остается только циклически опрашивать наш энкодер сравнивая
текущее состояние с новым и на основании этого делающего выводы о
вращении. Причем частота опроса должна быть такой, чтобы не пропустить
ни одного импульса. Например, мой EC12 имеет 24 импульса на оборот.
Вращать его предпологается вручную и я вряд ли смогу вращать его с
космической скоростью, но решил все же замерить. Подключился к
осциллографу, крутнул ручку что есть мочи:
Выжал меньше килогерца. Т.е. опрашивать надо примерно 1000 раз в
секунду. Можно даже реже, будет надежней в плане возможного дребезга.
Сейчас, кстати, дребезга почти нет, но далеко не факт что его не будет потом,
когда девайсина разболтается.
Сам опрос должен быть в виде конечного автомата. Т.е. у нас есть текущее
состояние и два возможных следующих.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Эту задачу надо запускать каждую миллисекунду.
// EncState глобальная переменная u08 -- предыдущее состояние энкодера
// EncData глобальная переменная u16 -- счетный регистр энкодера
void EncoderScan(void)
{
u08 New;
New = PINB & 0x03; // Берем текущее значение
// И сравниваем со старым
// Смотря в какую сторону оно поменялось -- увеличиваем
// Или уменьшаем счетный регистр
switch(EncState)
{
case 2:
{
if(New == 3) EncData++;
if(New == 0) EncData--;
break;
}
case 0:
{
if(New == 2) EncData++;
if(New == 1) EncData--;
break;
}
case 1:
{
if(New == 0) EncData++;
if(New == 3) EncData--;
break;
}
case 3:
{
if(New == 1) EncData++;
if(New == 2) EncData--;
break;
}
}
44
45
46
47
48
49
EncState = New; // Записываем новое значение
// Предыдущего состояния
SetTimerTask(EncoderScan,1); // Перезапускаем задачу через таймер диспетчера
}
Почему я под счетчик завел такую большую переменную? Целых два байта?
Да все дело в том, что у моего энкодера, кроме импульсов есть еще
тактильные щелчки. 24 импульса и 24 щелчка на оборот. А по моей логике,
на один импульс приходится четыре смены состояния, т.е. полный период
3201_3201_3201 и один щелчок дает 4ре деления, что некрасиво. Поэтому я
считаю до 1024, а потом делю сдвигом на четыре. Получаем на выходе один
щелочок - один тик.
Скоростной опрос на прерываниях
Но это механические, с ними можно простым опросом обойтись — частота
импульсов позволяет. А бывают еще и высокоскоростные энкодеры. Дающие
несколько тысяч импульсов на оборот, либо работающие на приводах и
вращающиеся очень быстро. Что с ними делать?
Ускорять опрос занятие тупиковое. Но нас спасает то, что у таких энкодеров,
как правило, есть уже свои схемы подавления дребезгов и
неопределенностей, так что на выходе у них четкий прямоугольный сигнал
(правда и стоят они совершенно негуманно. От 5000р и до нескольких сотен
тысяч. А что ты хотел — промышленное оборудование дешевым не бывает).
Так что без проблем можно применять прерывания. И тогда все упрощается
неимоверно. Настраиваем всего одно прерывание по внешнему сигналу.
Например, INT0 настраиваем так, чтобы сработка шла по восходящему
фронту. И подаем на INT0 канал А.
Пунктиром показано предполагаемое положение в произвольный момент.
Красные стрелки это фронты по которым сработают прерывания при
движении либо в одну, либо в другую сторону.
А в обработчике прерывания INT0 щупаем вторым выводом канал В. И
дальше все элементарно!
Если там высокий уровень - делаем +1, если низкий -1 нашему счетному
регистру. Кода на три строчки, мне даже писать его лень.
Конечно, можно такой метод прикрутить и на механический энкодер. Но тут
надо будет заблокировать прерывания INT0 на несколько миллисекунд. И
НИ В КОЕМ СЛУЧАЕ нельзя делать это в обработчике.
Алгоритм прерывания с антидребезгом будет выглядеть так:
•
Зашли в обработчик INT0
•
Пощупали второй канал
•
+1 или -1
•
Запретили локально INT0
•
Поставили на таймер событие разрешающее INT0 через несколько
миллисекунд
•
Вышли из обработчика
Сложно? Нет, не сложно. Но зачем? Проще сделать банальный опрос, как
указано выше и не зависеть от выводов прерываний. Впрочем, хозяин барин.
Обработка множества инкрементальных энкодеров
одновременно
Про инкрементальный энкодер и про обработку его сигналов с помощью МК
уже была статья. Вроде-бы ничего сложного — два бита текущего состояния,
два бита предыдущего — автомат с 16 состояниями. Рассмотрим эту задачу
ещё раз с позиции максимально эффективной (по скорости и размеру кода)
обработки сигналов множества энкодеров одновременно.
Обозначим текущее состояние энкодера как «y1» и «y2», а предыдущее, как
«x1» и «x2». Всего 4 бита — 16 состояний. Условимся, что направление
«Вперёд» у нас будет от первого датчика энкодера ко второму. Запишем все
возможные состояния в таблицу.
Таблица 1.
№ y2 y1 x2 x1 Вперёд Назад Состояние
------------------------------------------------------------------
0 0 0 0 0 0 0 Стоп
1 0 0 0 1 0 1 Назад
2 0 0 1 0 1 0 Вперёд
3 0 0 1 1 0 0 Не определено
4 0 1 0 0 1 0 Вперед
5 0 1 0 1 0 0 Стоп
6 0 1 1 0 0 1/0 Назад*
7 0 1 1 1 0 1 Назад
8 1 0 0 0 0 1 Назад
9 1 0 0 1 1/0 0 Вперёд*
A 1 0 1 0 0 0 Стоп
B 1 0 1 1 1 0 Вперёд
C 1 1 0 0 0 0 Не определено
D 1 1 0 1 1 0 Вперёд
E 1 1 1 0 0 1 Назад
F 1 1 1 1 0 0 Стоп
* - строчки 6 и 9 в таблице в принципе означают перемещение назад и вперёд
соответственно, в случае если оба датчика энкодера никогда не срабатывают
одновременно. Такая ситуация теоретически может иметь место если энкодер
это две оптопары и колесо с отверстиями, причем размер отверстия меньше
расстояния между оптопарами. На практике это встречается редко, по этому
будем иметь этот случай ввиду, но учитывать не будем.
Теперь в соответствии с таблицей напишем код определяющий направление
вращения энкодера. Самый простой и тем не менее достаточно эффективный
вариант вариант это - упаковать все 4 бита в одну переменную и сделать
switch по ней:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
static uint8_t EncState=0;
static volatile uint16_t EncValue=0;
inline static void EncoderScan(void)
{
uint8_t newValue = PINC & 0x03;
s uint8_t fullState = newValue | EncState << 2;
switch(fullState)
{
case 0x2: case 0x4: case 0xB: case 0xD:
EncValue ++;
break;
case 0x1: case 0x7: case 0x8: case 0xE:
EncValue --;
break;
}
EncState = newValue;
}
Тут мы воспользовались возможностью задавать несколько меток case для
одного блока. Значение меток соответствуют номерам строк из нашей
таблицы — очень удобно и наглядно, легко обработать и другие состояния
если надо.
Теперь приступим к количественным измерениям. Для чистоты
эксперимента сканирование энкодера будем помещать в обработчик
прерывания, например, от таймера — там будет сразу видно сколько
регистров надо сохранять. Сами функции сканирования энкодера будем
делать встраиваемыми, что их тело помещалось непосредственно в
обработчик прерывания. Размер будем считать от начала обработчика по reti
включительно. Целевой процессор — Mega16. Компиляторы avr-gcc 4.3 и
IAR C/C++ Compiler for AVR 5.50.0 [KickStart]. Во всех случаях оптимизация