Подключение инкрементального энкодера к AVR

[pasipaka]

Посмотри даташит на SN75175, это диф. приемник с линии, там в типовой схеме всё есть, использую их на плазме, а там помех УЖАС!.., работают нормально.

Я пакет SN75176 (трансивер) купил.... Да, он имеет 1 приемник, но и в 2 раза меньше. Да и драйвер есть, если вдруг где что передать нужно.

[Godzilla82]

Это точно... Чукча не читатель, чукча - писатель

До сих пор нет условий задачи. То есть, требуемая точность, быстродействие.

Я подозреваю, что это студент-двоечник, которому надо сделать всё готовое, чтобы он ваше блюдечко преподнёс преподу и получил оценку в зачётку.

А теперь по делу:
Есть станок, движется там планшет или ещё что. С какой скоростью? Сколько оборотов при этом делает вал с энкодером?

Софтварный энкодер без проблем обсчитывает 100 - 200 кГц (событий).
Есть энкодеры где только A,B и Z. Для задачи достаточно только A и B.

Если устройство пропускает импульсы - то в мусорку такое устройство, если не пропускает, то сигнал Z добавляет много лишнего геммороя, в том числе и снижая быстродействие.

Дифференциальный выход нужен только в условях сильных помех. Имхо, в большинстве случаев достаточно обычного экранированного кабеля.

100 - 200 кГц - это уже выше механического дребезга. Хотя МК с аппаратным квадратурным интерфейсом может быть полезен.

Софтварный алгоритм для двухбайтного счётчика выполняется за 30-40 тактов, ну плюс ещё тактов 20 на вход в прерывание. Итого, при частоте 16 МГц получаем частоту обсчёта 400 кГц. Это без особых ухищрений.

Для новичка это будет проще всего.

P.S. Боюсь, только, что не в коня корм.

[turn]

.. я студент, и мне нужна .. энкодер с МК ...

Студент, не е%и мозги ни себе, ни людям с АВР-ами .. в STM32 уже встроена аппаратная поддержка и инкрементального энкодера, и апппаратный ШИМа для BLDC мотора. на сайте у Дихальта разжевывается на русском один такой пример, есть несколько апнотов - было бы желание. Проц ~$2, демоборд - $12.

[Godzilla82]

в STM32 уже встроена аппаратная поддержка...

Я бы не советовал новичкам использовать STM8. Для него пока ещё очень сырой софт. Да и документация оставляет желать лучшего.

[pasipaka]

Это точно... Чукча не читатель, чукча - писатель
....

Дифференциальный выход нужен только в условях сильных помех. Имхо, в большинстве случаев достаточно обычного экранированного кабеля.

100 - 200 кГц - это уже выше механического дребезга. Хотя МК с аппаратным квадратурным интерфейсом может быть полезен.

Софтварный алгоритм для двухбайтного счётчика выполняется за 30-40 тактов, ну плюс ещё тактов 20 на вход в прерывание. Итого, при частоте 16 МГц получаем частоту обсчёта 400 кГц. Это без особых ухищрений.

Для новичка это будет проще всего.

P.S. Боюсь, только, что не в коня корм.

Это вы мягкое с теплым намешали?... Чего то вы так радикально...
О дифф. сигнале вопрос подымал я. А у меня имплуьсы могут до 1 МГц достигать. Но пока на таких скоростях не катаю.

З.Ы.
Сорри, если влез со своими вопросами.

[pasipaka]

Немного вопрос в сторону:
если число импульсов на оборот датчика кратно степени 2, то диапазон значений прекрасно ограничиивается маской и побитный умножением: например, дачтик с 4096 имп/на оборот (2^12степени).
Для хранения значений берем слово (16 бит). Значения должны вертется от 0 и до этого максимума, потому эффективно ограничение реализуется так:
Koord&=0b0000111111111111

А вот если датчик дает некратное степени 2 число импульсов, например 14400.
Как тогда эффективно ограничить???
Если движемся в плюс, то при превышении максимума, его же вычитаваем.
А если в минус (при условии, что переменная слово 16бит) при переходе с 0 в FFFF тоже вычитать соотв. значение (52136) ? Раково как-то и не красиво.

А может есть какие более изящные алгоритмы??? По каким словокомбинациям гуглить? А то не нахожу....

[Godzilla82]

З.Ы.
Сорри, если влез со своими вопросами.

Наверное, я немного запутался. Ответ адресовывался топикстартеру. Т.З. от него не было, и о мегагерцах можно было только догадываться. При таких скоростях - конечно, только аппаратный декодер и дифф. сигнал.

[Godzilla82]

Как тогда эффективно ограничить???
Если движемся в плюс, то при превышении максимума, его же вычитаваем.
А если в минус (при условии, что переменная слово 16бит) при переходе с 0 в FFFF тоже вычитать соотв. значение (52136) ? Раково как-то и не красиво.

Не совсем понял, о чём речь. Если аппаратный квадратурный декодер - то он потребуется 16-ти битный. Иначе дрожание на границе перехода приведёт к сбою общего счёта. Будет с частотой 1 МГц перещёлкиваться с 0 на 255. Забибикаетесь программно приплюсовывать это число.

Программный - так там мегагерц сложновато будет сделать. Вот 16 бит и 200 кГц - без проблем.

[pasipaka]

1 МГц - там аппаратно. Это линейный датчик с разрешением 0,1 микрона.

А касательно ограничений - это софтверно, для углового энкодера. Кой-какие эксперименты провожу. Имею 14400 импульсов на оборот. А затем эту координату угла шлю в ПК. Но хочу, чтобы ПК получал только числа в диапазоне от 0 до 14399. Потому есть ли какой лаконичный алгоритм такого ограничения? Дабы не ставить множества условий и вычитаний...

[Godzilla82]

Но хочу, чтобы ПК получал только числа в диапазоне от 0 до 14399.

 
unsigned int send_to_pc(unsigned int count)
{
return count % 14400;
}