_Sam_ 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Чтобы понять - нужен даташит на энкодер и максимальная скорость вращения в ТЗ. Может получиться так, что в момент остановки датчик попадёт на границу дискреты и при наличии определённых механических возмущений немного подребезжит. Поэтому более корректно закладываться не на максимальную скорость вращения, а на максимальную выходную частоту датчика! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба На меге > 86кгц*2 получить не реально, Извините, но это аццкий отжых. Иначе, отчего у меня Энкодер(правда, 1) + STEP разгоняются до 100кГц пока без напрягов для основной задачи? Приведенным выше макаком, ессно. На 18.432 МГц Я именно про квадратуру. Итого 20 тактов на 10тибитный счетчик со всеми входами/выходами. Отнять надо пару регистров для счетчика и регистр для сохранения SREG. Потом, конечно, надо немного поколдовать над конвертированием. Огласите весь список, пжалста! :) Не пойму, как мы без ловли фронтов отловим событие, по которому изменится регистр положения Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
PhX 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Извините, но это аццкий отжых. Иначе, отчего у меня Энкодер(правда, 1) + STEP разгоняются до 100кГц пока без напрягов для основной задачи? Приведенным выше макаком, ессно. На 18.432 МГц С одним энкодером проблем на атмеге нет. Обрабатываем его по INT0 (самый высокий приоритет) и все. А вот когда 2 энкодера выдают килогерцы... рука тянется за бубном. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба ЗЫ: вот кстати - история про то, что надо фронты обрабатывать: и при наличии определённых механических возмущений немного подребезжит. Обрабатываем его по INT0 Дык зря. Надо скан, уже ведь говорили где-то в темах по AVR Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
PhX 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Дык зря. Надо скан, уже ведь говорили где-то в темах по AVR Мне кажется дело вкуса. У меня по INT0 замечательно работает. Про фронты +1. Этими граблями сам получил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Огласите весь список, пжалста! :) Не пойму, как мы без ловли фронтов отловим событие, по которому изменится регистр положения Ну фронты ловить надо, спору нет. По ним обновляются младшие 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 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Общее время ...+16(худший случай).Похоже, что лучше будет некуда. Именно благодаря наличию худших/лучших случаев проц особо не надуется. Если будет на поллинг по таймеру потрачено 50% времени - уже замечательно. Скока-скока? ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Именно благодаря наличию худших/лучших случаев проц особо не надуется. Вообщем-то поллинг энкодера по таймеру тоже имеет смысл. Если энкодер по каким-либо причинам зафлудит любой свой сигнал с большой частотой, сердце у проца станет. Только и будет, что в прерываниях молотить. Хотя, конечно, вменяемые энкодеры так делать не должны. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Хотя, конечно, вменяемые энкодеры так делать не должны. Дык это на всю схему распространяется, помехо(не)устойчивость может натворить и при идеальном энкодере. И при поллинге у нас автоматом неплохой антидребезг получается, и во вторых имеется детерминированное время обработки любого количества энкодеров. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Дык это на всю схему распространяется, помехо(не)устойчивость может натворить и при идеальном энкодере. Да не в том дело. Если энкодер вменяем и не может залить сигнал флудом, то прилет такой помехи, которая клином поставит проц, надо рассматривать как аварийный режим. Работать такая помеха явно не даст - уже неизвестно, сколько левых импульсов насчитано/пропущено. Конечно, при такой аварии надо предусмотреть такую последовательность действий, которая безопасно остановит процесс. Просто опрос по pin-change сам балансирует нагрузку на проц. И не отнимает мипсы при отсутствии перемещения. Как промежуточный вариант можно сделать так - простробировать на D-триггерах сигналы энкодера, a в качестве строба подать сигнал от таймера с максимально возможной для обработки частотой. Обработчик оставить на pin-change. Можно, например, взять 74HC74, если сигналов всего два. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба прилет такой помехи, которая клином поставит проц, надо рассматривать как аварийный режим. Ну, "штатные" помехи обычно синфазные. И вот этот квадратно-гнездовой инкремент/декремент в моем варианте обработчика - немножко учитывает такие случаи. И, опять же, обработка нескольких энкодеров по PCNxx кладет проц на лопатки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Сэр, у Вас КОСЯГ: ............ ENC_HANDLE: ..................................... BST STATE,BIT_B ; а потом уже SREG сохраняется Природа отобрала 1 такт :) Плакать не будем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Народ, в который раз меня вдохновила подобная беседа!!! И вот я тоже прихожу к выводу, что поллить энкодеры несколько лучше в плане устойчивого считывания информации. Особенно, если энкодеры не промышленные, а самопал - типа из мышки...( Как это не печально, но бюджет не позволяет купить что-нить готовое. Даже импульсов 200 на оборот... Ничего дешевле 1500 р не находил, а нужно три энкодера. В универе денег нет((( Но что еще печальнее, энкодер из мышки не дает по двум каналам двига на pi/2 между фазами. Далее, не удается получить скважность сигнала на каждом канале равную 2... Если на одном получается, то на другом уже перекос... Понятно, что это уже не совсем квадратурный энкодер..., а что-то другое. И аппаратный декодер загибается на этом деле. Тут, похоже нужно программно... верно ли я мыслю? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба Сэр, у Вас КОСЯГ: Согласен. Природа отобрала 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 17 марта, 2009 Опубликовано 17 марта, 2009 · Жалоба И аппаратный декодер загибается на этом деле. Там и программный загнется :( А что это будет по частоте? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться