[_Sam_ 0]

Чтобы понять - нужен даташит на энкодер и максимальная скорость вращения в ТЗ.

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

[_Pasha 0]

На меге > 86кгц*2 получить не реально,

 

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

 

Я именно про квадратуру. Итого 20 тактов на 10тибитный счетчик со всеми входами/выходами. Отнять надо пару регистров для счетчика и регистр для сохранения SREG.

Потом, конечно, надо немного поколдовать над конвертированием.

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

[PhX 0]

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

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

[_Pasha 0]

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

 

и при наличии определённых механических возмущений немного подребезжит.

 

Обрабатываем его по INT0

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

[PhX 0]

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

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

 

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

[Rst7 5]

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

 

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

#define    SREG_SAVE R13
#define ENC_POS R14
#define STATE R15

#define PIN_ENCODERS PINC
#define BIT_A 1
#define BIT_B 4

ENC_HANDLE:
    SBRC    STATE,BIT_A
    RJMP    ENC_HANDLE_EXIT
    BST    STATE,BIT_B
    IN    STATE,PIN_ENCODERS
    SBRC    STATE,BIT_A
    RETI
    BRTS    ENC_HANDLE_DEC
    IN    SREG_SAVE,SREG
    SBRC    STATE,BIT_B
    INC    ENC_POS
    OUT    SREG,SREG_SAVE
    RETI
ENC_HANDLE_DEC:
    IN    SREG_SAVE,SREG
    SBRS    STATE,BIT_B
    DEC    ENC_POS
    OUT    SREG,SREG_SAVE
    RETI
ENC_HANDLE_EXIT:
    IN    STATE,PIN_ENCODERS
    RETI

 

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

 

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

 

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

[_Pasha 0]

Общее время ...+16(худший случай).

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

 

 

 

 

Если будет на поллинг по таймеру потрачено 50% времени - уже замечательно.

Скока-скока? ;)

[Rst7 5]

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

 

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

[_Pasha 0]

Хотя, конечно, вменяемые энкодеры так делать не должны.

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

[Rst7 5]

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

 

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

 

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

 

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

[_Pasha 0]

прилет такой помехи, которая клином поставит проц, надо рассматривать как аварийный режим.

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

[_Pasha 0]

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

............
ENC_HANDLE:
.....................................
    BST    STATE,BIT_B
; а потом уже SREG сохраняется

 

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

[haker_fox 60]

Народ, в который раз меня вдохновила подобная беседа!!!

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

[Rst7 5]

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

 

Согласен.

 

Природа отобрала 1 такт

 

Не согласен.

ENC_HANDLE:
    SBRC    STATE,BIT_A
    RJMP    ENC_HANDLE_EXIT
    IN    SREG_SAVE,SREG
    BST    STATE,BIT_B
    IN    STATE,PIN_ENCODERS
    SBRC    STATE,BIT_A
    RJMP    ENC_RESORE
    BRTS    ENC_HANDLE_DEC
    SBRC    STATE,BIT_B
    INC    ENC_POS
ENC_RESTORE:
    OUT    SREG,SREG_SAVE
    RETI
ENC_HANDLE_DEC:
    SBRS    STATE,BIT_B
    DEC    ENC_POS
    OUT    SREG,SREG_SAVE
    RETI
ENC_HANDLE_EXIT:
    IN    STATE,PIN_ENCODERS
    RETI

 

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

 

Плакать не будем.

 

Согласен.

[_Pasha 0]

И аппаратный декодер загибается на этом деле.

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