New approach to Rotary Encoder

[Heckler]

Thanks! Aratti...

I had just finished adapting your earlier example for a 16F690 pic. It took me a while to figure out why my LCD was not working... Dang MCLR pin tripped me up untill I rememberd that it could not act as an output... then I had to move my LCD to PortC... then I had to figure out that my OLD 4 line LCD (bought it about 20 Years ago from AllElectronics) needed more time on the LCD_COMMANDUS.

Anyway it is working GREAT...
I will give your latest code a spin this weekend.

As far as update time to the LCD... it seems to be limited to any Pause or other code that is in the Main Loop. I had been blinking an LED in the main loop using a Pause statement and therefore this limited the LCD update frequency. I think I'll try and impliment another DT-Int using a timer to run the blinking LED in the main loop. This should remove any excessive delay to the LCD update.

PS. I can post Aratti's modified working code for the 16F690 if anybody is interested...

[Mike, K8LH]

.... As far as update time to the LCD... it seems to be limited to any Pause or other code that is in the Main Loop. I had been blinking an LED in the main loop using a Pause statement and therefore this limited the LCD update frequency. I think I'll try and impliment another DT-Int using a timer to run the blinking LED in the main loop. This should remove any excessive delay to the LCD update.

May I offer insight into another way around this problem? I've always been concerned about the overhead of printing to an HD44780 compatible character display. For example, if you tie up the processor for 400 usecs while printing eight (8) characters to the LCD, you might have a problem with another process that needs to run at 100 usec intervals. Instead of updating the display the usual way, with a 40 usec delay between each write, why not refresh the LCD from a 32 character buffer as a background task using interrupts. I did this recently on a TI MSP430 Launchpad project and it worked very well.

Here's the basic idea (C code). Your main program simply writes ASCII data into a 32 character array to update the display. Array elements 0-15 and 16-31 are mapped to LCD lines 1 and 2, respectively. The driver in the ISR only writes one character at a time from the array to the LCD during each interrupt, but I used a 500 usec interrupt interval so the entire display is actually updated around 59 times each second (updates are perceived as instantaneous). Also note that the PutLCD routine (not shown) does not need to include the normal 40 usec LCD inter-character delay.

Food for thought... Regards, Mike

    unsigned char lcd[32] = { "                                " };

    void interrupt()
    {                               // 500 us TMR2 interrupts
      static char bndx = 0x00;      // lcd display buffer index, 0..31
      static char line = 0xC0;      // lcd display DDRAM address

      pir1.TMR2IF = 0;              // clear TMR2 interrupt flag
   /*                                                                   *
    *  refresh one character on the display each interrupt.  entire     *
    *  display refreshed every 17 msecs (58.8 Hz refresh rate).         *
    *                                                                   */
      if(line.7)                    // if "new line"
        PutLCD(line ^= 64,0);       // toggle LCD DDRAM "line" address
      else                          // not "new line" so
        PutLCD(lcd[bndx++],1);      // refresh display, bump index
      bndx &= 31;                   // pseudo mod 31, 0..31 inclusive
      if((bndx & 15) == 0)          // if new line (0 or 16)
        line.7 ^= 1;                // toggle b7 pseudo "new line" flag
    }

[Ioannis]

For some peculiar reason that I cannot understand, Al's code is counting +/- 4 steps instead of one for each click.

Anyone can speculate why?

With a logic analyzer I have confirmed that the encoder is working fine. Here is a snapshot for 4 clicks of the encoder.



Ioannis

[HenrikOlsson]

Hi Ioannis,
I haven't looked at the particular code in question but generally, you decode all 4 edges, hence the term quadrature. Look at the capture for one click, first Ch.0 goes low (1) then Ch.1 goes low (2), then Ch.0 goes high (3) and finally Ch.1 goes high (4). So, 4 counts per click.

/Henrik.

[Ioannis]

Hmm, thanks Henrik, it looks logic now... well...

Ioannis

[Demon]

I need a rotary encoder for manual input in flight simulator; changing radio frequency, autopilot altitude, etc. I like the "slower" detection in post #1 for this particular application or else I'd issue 4 keyboard commands in a single detent. 100 feet would change to 500 feet with a single click with no way to set to the in-between values.

But Podgy brings up a very important point; all rotary encoder datasheets I've seen mention debounce. I know most PIC inputs have Schmitt triggers, but just how effective are they in these cases? I can't test until my batch arrives.

Robert

[Ioannis]

a couple of 100nF were needed for mine. After placing the caps to ground from each encoder output pin, false readings were a past.

Ioannis