roboforum.ru

А, сорри, я тоже невнимательно глянул, там обработчик на любой фронт повешен - значит и правда надо 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 писал(а):В любом случае это достаточно напряженно, если что-то кроме энкодера еще нужно делать.
Софтово решать такие штуки можно, но это не очень-то красиво. Если речь идет о серьезных проектах (в данном случае это, вероятно, не так), то я бы не особо рассчитывал на программные решения, честно. Но это, конечно, имхо.

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

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

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

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

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

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

Некоторое время назад делал драйвер. Обрабатывал 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;   

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