Может получиться так, что в момент остановки датчик попадёт на границу дискреты и при наличии определённых механических возмущений немного подребезжит. Поэтому более корректно закладываться не на максимальную скорость вращения, а на максимальную выходную частоту датчика!

Извините, но это аццкий отжых. Иначе, отчего у меня Энкодер(правда, 1) + STEP разгоняются до 100кГц пока без напрягов для основной задачи? Приведенным выше макаком, ессно. На 18.432 МГц


Огласите весь список, пжалста! Не пойму, как мы без ловли фронтов отловим событие, по которому изменится регистр положения

С одним энкодером проблем на атмеге нет. Обрабатываем его по INT0 (самый высокий приоритет) и все. А вот когда 2 энкодера выдают килогерцы... рука тянется за бубном.

ЗЫ: вот кстати - история про то, что надо фронты обрабатывать:




Дык зря. Надо скан, уже ведь говорили где-то в темах по AVR

Мне кажется дело вкуса. У меня по INT0 замечательно работает.

Про фронты +1. Этими граблями сам получил.

Ну фронты ловить надо, спору нет. По ним обновляются младшие 2 бита положения - они же банальные сигналы квадратуры. Только вот обрабатывать достаточно только перенос, а не каждый фронт. Ну должно быть типа такого


Пардон, прошлый раз считал в уме, немного ошибся. Общее время 4(вход в прерывание)+2(RJMP с вектора)+16(худший случай)=22 такта.

Соответственно, ENC_POS - старшие 8 бит положения, STATE.A и STATE.B - младшие 2 бита положения в коде Грея. Оба регистра атомарно эксгумируются при помощи MOVW (поэтому и лежат рядом).

Двухэнкодерный случай рассмотрите сами

Похоже, что лучше будет некуда. Именно благодаря наличию худших/лучших случаев проц особо не надуется.





Скока-скока?

Вообщем-то поллинг энкодера по таймеру тоже имеет смысл. Если энкодер по каким-либо причинам зафлудит любой свой сигнал с большой частотой, сердце у проца станет. Только и будет, что в прерываниях молотить. Хотя, конечно, вменяемые энкодеры так делать не должны.

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

Да не в том дело. Если энкодер вменяем и не может залить сигнал флудом, то прилет такой помехи, которая клином поставит проц, надо рассматривать как аварийный режим. Работать такая помеха явно не даст - уже неизвестно, сколько левых импульсов насчитано/пропущено. Конечно, при такой аварии надо предусмотреть такую последовательность действий, которая безопасно остановит процесс.

Просто опрос по pin-change сам балансирует нагрузку на проц. И не отнимает мипсы при отсутствии перемещения.

Как промежуточный вариант можно сделать так - простробировать на D-триггерах сигналы энкодера, a в качестве строба подать сигнал от таймера с максимально возможной для обработки частотой. Обработчик оставить на pin-change. Можно, например, взять 74HC74, если сигналов всего два.

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

Сэр, у Вас КОСЯГ:


Природа отобрала 1 такт Плакать не будем.

Народ, в который раз меня вдохновила подобная беседа!!!
И вот я тоже прихожу к выводу, что поллить энкодеры несколько лучше в плане устойчивого считывания информации. Особенно, если энкодеры не промышленные, а самопал - типа из мышки...( Как это не печально, но бюджет не позволяет купить что-нить готовое. Даже импульсов 200 на оборот... Ничего дешевле 1500 р не находил, а нужно три энкодера. В универе денег нет((( Но что еще печальнее, энкодер из мышки не дает по двум каналам двига на pi/2 между фазами. Далее, не удается получить скважность сигнала на каждом канале равную 2... Если на одном получается, то на другом уже перекос... Понятно, что это уже не совсем квадратурный энкодер..., а что-то другое. И аппаратный декодер загибается на этом деле. Тут, похоже нужно программно... верно ли я мыслю?

Согласен.



Не согласен.


Худший случай не изменился. Немного ухудшилась одна ветка.



Согласен.

Там и программный загнется А что это будет по частоте?