Увеличение скорости счета импульсов на АТ90S2313

[kison]

А что даст прерывание по обеим линиям ? все равно надо читать соседнюю линию.

Удвоение разрешения энкодера. Если у Вас с одной линией затык, то это Вам не нужно
Ускоряйте обработчики.
Например ваш обработчик от энкодера:

interrupt [EXT_INT0] void ext_int0_isr(void)
//прерывание по фронту, анализируется состояние второго входа  
{   
 #asm("cli")        
 PORTB.7=1;        
  if(PIND.3==0)
  {
  i--;
   } 
    if(PIND.3==1)
  {
  i++;
   }      
  #asm("sei")  
 }

Прерывания запрещать не надо, они и так запрещены.
Вот то же:

interrupt [EXT_INT0] void ext_int0_isr(void)
//прерывание по фронту, анализируется состояние второго входа  
{   
 PORTB.7=1;        
  if(PIND.3==0)
  {
  i--;
   } 
    else
  {
  i++;
   }      
 }

На несколько тактов будет короче.
В RevriteDig непонятна строка temp=Dc; Видимо должно быть temp=i;
Тогда прерывания нужно запретить только на время считывания этой переменной:

void RevriteDig(long int Dc)   
//функция перезаписи индицируемого значения
  {
   long int temp;
   #asm("cli") 
   temp=i; 
   #asm("sei")
   D[0]=D[1]=D[2]=D[3]=D[4]=0;
    while(temp ›= 10000)
         {
         temp = temp - 10000;
         D[0]++;
          }
       while(temp ›= 1000)
         {
         temp = temp - 1000;
         D[1]++;
          } 
       while(temp ›= 100)
         {
         temp = temp - 100;
         D[2]++;
          }
       while(temp ›= 10)
         {
         temp = temp - 10;
         D[3]++;
          }       
       while(temp ›= 1)
         {
         temp = temp - 1;
         D[4]++;
          }
      }

Вообще неплохо работать не напрямую с образом индикатора, а с локальным массивом и переписывать в D[] уже готовые результаты при запрещенных прерываниях. Так индикатор перестанет "моргать".
Прерывание от таймера стоит сократить. Ну и разблокировать прерывания в нем - небольшое подмаргивание индикатора все же лучше чем пропуски импульсов от энкодера.
Да - вместо задержки в основном цикле лучше считать кол-во прерываний на индикацию. При большой загрузке delay_ms(100); // каждые 100мс обновить индикацию превратятся в куда большую задержку.

interrupt [TIM1_COMP] void timer1_comp_isr(void)
// динамическая индикация
 {
  static unsigned char PosDig; 
 #asm("sei")
  PORTB =0x00;      //гашение всех сегментов
  PORTD &= ~((1‹‹0)|(1‹‹1)|(1‹‹4)|(1‹‹5)|(1‹‹6));        // отключение катодов
  switch (PosDig)              //выбор подключаемого катода
  { case 0: PORTD.6 =1; break;
     case 1: PORTD.5 =1; break;
       case 2: PORTD.4 =1; break;
         case 3: PORTD.1 =1; break;
           case 4: PORTD.0 =1; break;
               }       
     PORTB = DigSim[D[PosDig]];     
          
  PosDig ++;
  if (PosDig ==5) PosDig = 0;    
 }

В общем тут и без ассемблера есть где развернуться.

[nml]

Я думал за такой способ, но нужно еще знать направление счета, а оно определяется фазой сигнала.

Было бы желание, а извернуться можно всегда.

Вот например - а что если завести одну фазу на T0 и на INT0, вторую - соответственно на T1 и INT1

Два таймера настроить на счет импульсов с T0 / T1
Прерывания INT настроить на спад. И в прерываниях INT разрешать-запрещать счет таймеров? В принципе, это та же логическая схема на входе (инвертор и две штуки 2И), но паять рассыпуху не надо будет.

В результате один таймер будет считать в минус, один - в плюс. А в программе вы уже будете просто вычитать первый из второго.

[picavr]

Вот например - а что если завести одну фазу на T0 и на INT0, вторую - соответственно на T1 и INT1

И ловить короткие помехи по INTам.
Нет. лучше всё в таймере. скорости AVR хватит на обработку энкодера со скоростью скажем 100 000 импульсов в сек. Если вынести прерывание обработки энкодера по таймеру одному а преоывание индикаци на другой таймер.
Если скорость существенно ниже то и одно прерыание от таймера с успехом справится.

Делал лет 8 назад управление бензоколонками от компутера...
Подсчёт импульсов от 4-х бензоколонок паралельно, по 100 импульсов на литр, сколько там льёт литров в секунду примерно представляете...

Вот по прерыванию 100 микросек это всё и обрабатывалось + успевал обработку УСАРТ - общение с компьютером. Это PIC на 16 мгц успевал обрабатывать а у вас в 4 раза производительнее.

[kison]

И ловить короткие помехи по INTам.

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

Это PIC на 16 мгц успевал обрабатывать а у вас в 4 раза производительнее.

С чего бы тинька на 4-х мегагерцах стала в 4 раза быстрее PIC16 на 16-ти? Скорее в два раза медленней.

[E_C_C]

удалил -разобрался

[E97]

Вот например - а что если завести одну фазу на T0 и на INT0, вторую - соответственно на T1 и INT1

Да чото типа такого.

Или если у вас будет возможность поставить HLC2705 то задача существенно упростится достаточно подвести выход direction на INT0 а tach на T0. По внешнему прерыванию отслеживать направление а по таймеру кол. импульсов.

[nml]

Или если у вас будет возможность поставить HLC2705 то задача существенно упростится

Для данного случая - упростится, но не настолько, чтобы оправдать усложнение схемы (imho). Если возможно чисто программное решение - то надо программно и делать.

[picavr]

Или если у вас будет возможность поставить HLC2705 то задача существенно упростится .

Да принципиально можно вообще всё сделать на логике.. ТОЛЬКО ЗАЧЕМ усложнять железо, если всё сможет обработать один МК? Для этого МК и применяют что бы железо максимально упростить.... Только нужно мозги приложить... те кто не может мозги, ... прикладывают железо...

Если там будут помехи, то опрос по таймеру также не годится

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

Кроме того независимо есть ли сигнал от энкодера загрузка процессора будет как при максимальной частоте этих импульсов.

Если грамотно написать прогу, то загрузка на каждый проход по обработке 1 энкодера будет примерно 3-10микросекунд из 100 .. а это 3-10%. Так что не слишком это много, но ничего не пропустит...

С чего бы тинька на 4-х мегагерцах стала в 4 раза быстрее PIC16 на 16-ти? Скорее в два раза медленней.

тактовая частота ядра получится одинаковая 4 МГЦ в обоих случаях... а дальше как софт напишете.. если обработка только в регистрах.. тогда одинаково.. если в RAM тогда да.. AVR медленнее..
А Тинька2313 до 20мгц бегает с кварцем.

[Panda_Y2k]

У вас не 500гц, а 5кгц. При даже 4мгц тактовой скорости все равно должно хватать.
Зачем в прерывании выставляете ногу PB7?
Сделайте в прерывании со входа так:
interrupt [EXT_INT0] void ext_int0_isr(void)
//прерывание по фронту, анализируется состояние второго входа
{
#asm("cli")
PORTB.7=1;
if(PIND.3==0) i--
else i++;
#asm("sei")
}

Это немного сократит обработчик.
Почему в прерывании от таймера не запрещаете прерывания? что это за устройство?
Датчик станка с чпу?
А как у вас там все замыкается? не вижу подтяжки на PD3


ЗЫ Похоже недоглядел, уже такую рекомендацию дали

[E_C_C]

Почему в прерывании от таймера не запрещаете прерывания?

Чтобы не произошел пропуск импульса, индикация в данном случае вторична.

что это за устройство?
Датчик станка с чпу?

Датчик ВЕ 178.
С одной стороны это попытка восстановления стенда ТНВД,там надо считать обороты и показывать скорость врашения.
Попутно возникла мысль сделать эл счетчик для намоточного станка.

Вот в качестве счетчика для намотки все может работать там скорость вращения низкая, а для ТНВД пока нет.

А как у вас там все замыкается? не вижу подтяжки на PD3

в реальном устройстве оптронная развязка по входам, я не стал городить ее в протеусе.

Пока пробую переделать проект на ассемблере, результат выложу .