roboforum.ru

[dccharacter]

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

О, так это ж капчур в чистом виде. Вешаем энкодер на капчур, ставим делитель 4-ку, в прерывании беснуемся... Если еще какие-нить буфферы сделать, можно будет снова три энкодера пихать в один 50-ти рублевый ПИК??? это ж не i2c...

Добавлено спустя 3 минуты 2 секунды:
т.е. 4 енкодера - в 1827 четыре капчур-канала. А таймера три... странно... ну или три.

[boez]

А, сорри, я тоже невнимательно глянул, там обработчик на любой фронт повешен - значит и правда надо 170 кГц. Наверное придется отказаться от digitalRead, повесить энкодер на 2 соседние ноги (к примеру 2 и 3) и сделать что-то наподобие

Код: Выделить всё • Развернуть

const signed char Decode[4] = {0,1,-1,0};
...
void doEncoder() {
    encoder0Pos += Decode[PIND>>encoder0PinA];
}

Или не выделываться и назначить прерывание только по фронту, тогда и частота упадет, и обработчик упростится:

Код: Выделить всё • Развернуть

void doEncoder() {
    if (PIND&(1<<encoder0PinB))
        encoder0Pos++;
    else
        encoder0Pos--;
}

[Michael_K]

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

[dccharacter]

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

Я соглашусь - я год строил лазерные часы, уперся в драйвер двигателя (даже описывал свои приключения в теме "жарю блины") - спалил три драйвера из-за флюса, черт бы его побрал (http://we.easyelectronics.ru/warning_gu ... el-tt.html - не я писал, но ППКС - Анатолий, Михаил, ну предупреждать же надо про такую бадягу!!!! столько сил и денег потрачено...). В итоге купил 8-ми выводную микруху в соике за 100 рублей, на которую тупо подаю ШИМ и ВООБЩЕ никаких проблем. Но пониманию процесса это не содействует. А с BDLC движками я процентов на 70 разобрался, пока блины жарил. Так что либо время, либо опыт

[Michael_K]

Или не выделываться и назначить прерывание только по фронту, тогда и частота упадет, и обработчик упростится:

Так делать нельзя. Представьте, что у вас вал гуляет около этого фронта - он же считать будет в одну сторону постоянно. Смысл квадратурного энкодера теряется.

[boez]

А, ну да, в режиме "удержание позиции", типа как в серве, это будет основным рабочим режимом, так не пойдет Хотя при обычном вращении и нечастых реверсах - вполне нормально, а нагрузку на проц снижает раза в 2.5.
Ну и вообще - если в иксмеге есть декодер, надо брать ее - и АВР, и работает с энкодером.

[NorthStar]

А кто знает - на оптическом квадратурном энкодере нужно ли что-нибудь делать для борьбы с дребезгом контактов?

[=DeaD=]

Вы не томите, предложенный мной код помог или как?

[NorthStar]

Сорри. Я когда ваш ответ увидел, то уже разобрал этот макет.
Я скоро вернусь к этому вопросу - обязательно проверю. Просто плата Arduino у меня одна, а идей много..)

[Duhas]

А кто знает - на оптическом квадратурном энкодере нужно ли что-нибудь делать для борьбы с дребезгом контактов?

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

[=DeaD=]

для борьбы с дребезгом контактов?

А с чего бы дребезг? Промежуточные состояния может? Тогда - триггер шмитта.

[NorthStar]

Кстати, а что такое ЛИР? Можно ссылку иль чертеж?

[Michael_K]

let me google that for you: лир энкодер

[Rm86]

Некоторое время назад делал драйвер. Обрабатывал 2 энкодера, управлял мостом MOSFET, и все это по командам UART
Делал на PIC16f1936.
Обработку энкодеров сделал следующим образом:
Инициализирую таймеры 0 и 1 для счета:

Код: Выделить всё • Развернуть

        OPTION_REG = 0b00101000; // Инкремент по фронту RA4 делитель 32
// Настройка таймера 1 - для счета инкремента ДО
   T1CON   = 0b10000100;
   T1GCON   = 0b00000000;
   TMR1ON = 1;

Постоянно, пока програма находится в режиме ожидания, в бесконечном цикле main определяю направление вращения для каждого энкодера:

Код: Выделить всё • Развернуть

      temp_a1 = RC0;         
      temp_a2 = RA4;
      while (!clock_reg.byte){ // Если нет текущих заданий
         if (temp_a1 !=RC0){  // Изменился счетный вход второго энкодера
            if (RC0){
               if (ENC_B2) //Вход "направление"
                  a1_inc_flag = 1;  //направление "вперед"
               else
                  a1_inc_flag = 0;  //направление "назад"
            }
         }
          if (temp_a2 !=RA4){  // Изменился счетный вход первого энкодера
            if (RA4){
               if (ENC_B1) //Вход "направление"
                  a2_inc_flag = 1;
               else
                  a2_inc_flag = 0;
            }
         }

Каждые 10мс по флагу прерывания считываю показания счетных таймеров и в зависимости от полученных битов направления, инкрементирую или декрементирую их:

Код: Выделить всё • Развернуть

         if (a2_inc_flag)
            Angle_E2 += TMR0;
         else
            Angle_E2 -= TMR0;
         TMR0 = 0;
         if (a1_inc_flag)
            Angle_E1 += TMR1;
         else
            Angle_E1 -= TMR1;
         TMR1 = 0;   

Сразу предостерегу: у такого метода счета есть небольшая погрешность в моменты изменения направления вращения. В моей задаче направление менялось редко и плавно, поэтому ошибкой я пренебрегал.