rotary encoder grey code problem

[acornjelly]

Has anyone successfully implimented a function to read from a rotary encoder (grey code). I'm sure it should be simple, as I read you just have to XOR the first bit from the last reading, and second from the first, then that'll tell you what direction you're turning in. But I'm having problems.

I have this, surely it should work? I've got a 20ms delay as a bodge debounce and am calling this function from interupts


int1 oldrotdata, newrotdata, answer = 0x00;
int oldrotdat, newrotdat = 0x00;



int rot_det()
{

if (input(rota)) bit_set(newrotdat,0); // set bit 0 of variable to match input
else bit_clear(newrotdat,0);

if (input(rotb)) bit_set(newrotdat,1); // set bit 1 of variable to match input
else bit_clear(newrotdat,1);

if (oldrotdat == newrotdat) // if the encoder hasn't moved
return(0x03); // report so
else
oldrotdat = newrotdat; // else store previous state

newrotdata = input(rota); // check input, set to variable
answer = newrotdata ^ oldrotdata; // XOR bit 0 and old bit 1
oldrotdata = input(rotb); // read bit 1 of rot encoder, after calculation
return(answer); // return 1 for clockwise, 0 for anti
}

[PCM programmer]

See this CCS example file:

[RLScott]

[acornjelly]

Sorry, yes you're right. I'm using a quaz phaze thingy, not Gray code. I can't work out why it isn't working, it seems simple on paper

[Ttelmah]

Do you want to 'full' quadrature decoding (all four edges), or just one of the subsets of this?
What is the pitch of your encoder (lines per turn)?
What is the maximum rotational rate?
What is your PIC?

The problem is that if you are using (for example), the interrupt on change ability to 'see' the edges, and the normal handlers for this, there are literally dozens of 'extra' instructions involved in saving the registers, before the handler is reached, and a similar number on the return. Unless your PIC is very fast, or the rotational rate very low (or the number of lines similarly low), you need to write a high speed 'global' handler to deal with the interrupts and avoid problems.
This routine

[acornjelly]

Fantastic. I haven't had a chance to try it yet but what you say makes complete sense. I can run my code within a while(1) in the main program so it's obviously the way I've handled the interrupts. All new to me, I'll put this in my code when I find time and let you know how I get on. Thanks so much for the help

[cybanical]

[KU5D]

Global interrupt doesn't really have anything to do with priority. Basically that allows you to enable your subsequent interrupts. Depending on your chip, you could have many possible interrupts...

#INT_RDA for your hardware usart
#INT_EXT for some external interrupt
#INT_RTCC for some housekeeping interrupt

...so on and so forth. Once you set these up, you use global to enable them. I have a project now that runs smoothly with something like five interrupts on a 4525. From what I've been able to learn (mostly from folks here), interrupts are by default prioritized in the order they are declared (someone correct me if I am wrong). However, if you have one that is most important above all else, you can do a #device HIGH_INTS=TRUE at the top of your main and then pick your priority interrupt and do something like #INT EXT FAST at the top of the interrupt service routine to give it priority. Using FAST rather than HIGH will still have the compiler manage the stack for you...if you use HIGH then you have to manage the stack for yourself.

Another thing to consider is the canned delay_xx() functions. These will put the PIC into do-nothing mode and mask all your interrupts, so they should be avoided in an interrupt-driven program at all costs. Best bet is to set up a background housekeeper timer interrupt and use it to set flags to clock your delays rather than the canned delay_xx() stuff.
_________________
Confidence is the feeling you have right before you fully understand the situation...

[cybanical]

hmm.

So, I'm using Ttelmah's quadrature code that uses a Global interrupt and I'm trying to include a tachometer by using CCP2 interrupt on pinB3 to capture every 4th rising edge. I've read through http://www.ccsinfo.com/forum/viewtopic.php?t=29963 and I thought I was following the same pattern, however i get the following error when i attempt to compile.

[Ttelmah]

There seems to be a big misunderstanding here about what #int_global is/does....

The #INT_GLOBAL interrupt routine definition, is really nothing to do with the INT_GLOBAL flag definition needed to enable all the interrupts (except in a rather 'roundabout' way).
On the basic PIC (ignore the hardware interrupt priority on the PIC18 for now), there is just _one_ interrupt vector. When _any_ interrupt occurs, if two flags are enabled (the one for this specific interrupt, and the global flag), then the processor performs a call to this _one_ address. The #INT_GLOBAL definition, defines the code to put at this point.
Normally, CCS does the handler at this point for you automatically. Their handler, saves _every_ global register, and a copy of the scratch memory. Then it tests all interrupt flags that have a defined handler, and jumps to the code for the first one it finds that is enabled, and whose flag is set. When this has finished, it then clears the interrupt flag, restores all the memory it saved, and returns to the main program.
Now, the problem here, is that this takes _time_. The INT_GLOBAL handler supplied by CCS, typically adds anything from 60 to 100 instructions to the time needed to process an interrupt (depending on how many interrupts are enabled).
The only connection between the #INT_GLOBAL handler, and the #INT_GLOBAL 'enable', is that both affect _all_ the interrupts.

The #INT_GLOBAL used in the quadrature example, is done to allow really _fast_handling of a quadrature encoder. The difference between perhaps 600RPM, and something approaching 8000RPM, on the original test system. However doing this, implies you can no longer have any other interrupt definitions at all. If you do need another interrupt, then the code to detect this (test the bit), has to be added _by you_ to the INT_GLOBAL handler. Also, you then have to save any other registers _this_ handler needs, and the maximum interrupt frequency supported without missing a character, will _drop depending on the duration you will be in this other handler.
Now, as an example, this is the 'real' #INT_GLOBAL handler from the original system. With this, I could still manage over 3000RPM (my actual target), and have some other interrupts in use: