Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Interrupts with trackball/quadrature encoders and PIC18

Status
Not open for further replies.

Pavius

New Member
I've interfaced a trackball to a 28 pin PIC18 (PIC18F2525 connected to an ALPS trackball outputting 4 data signals, 2 for each axis). I'd like to tie an interrupt on change for all of these signals so i won't lose any ticks while my uC is outputting stuff to LCD and the like.

The problem is that I can't use the RB<4:7> Interrupt-On-Change functionality because the RB[6:7] pins are used for ICSP. This only leaves INT0-2 for interrupts (not enough, i need interrupt on change of any signal). The way i see it, there are three solutions:

1) Poll, which is what i am doing now. This works, but poses a big limitation on the software because if i don't poll the data signals on time i will miss movement events
2) Have some glue logic do the decoding/counting for me (too expensive and i don't know how to program an FPGA yet)
3) Have an interrupt controller IC between the PIC and trackball, as depicted in the attached picture. On any change of the data signals, the INT0 will go low (or high) and stay that way until ACK is strobed, or some other form of quick acknowledgement. Anyone know of such an IC? Should be really small and simple.

Any other ideas?
 

Attachments

  • TbInt.jpg
    TbInt.jpg
    16.7 KB · Views: 313
LCD won't care if it looses a few ticks, they're slow devices.
Just set an interrupt to poll the pins or use PORTB 4:7 and jumper the ICP / Trackball
They also make some PICs with quadrature decoders in hardware.
 
The 18F2331 has one, you could do the other with RB4,5 and leave the ICD connected.

Yea I love debuggers too. Really handy.

Use the Microchip MAPs tool. QEI is what you want.
 
Last edited:
Generate a timer interrupt of TMR0 overflow. At 256 ticks and 20MHz that will check your trackball encoder every 51uS, plenty fast enough so you wont miss an encoder change. You could even slow it down a lot if you need to, even a 256uS int won't miss pulses.

The code on my trackball page is optimised for that type of system, the first thing it does is test if any of the 4 encoder pins have changed state (then exit if they haven't) so it is fast and efficient.
 
Thanks RB, but doesn't it bug you that your uC is constantly interrupted even when it doesn't need to be? Since I am doing this purely for educational reasons (i agree that for most projects using TMR0 is probably the best way to go), i want to try to find the least uC intensive way to interface to it. I also found an LSI IC w/ a serial interface that performs the counting for you, so that takes 99% of the load off of the uC.
 
Many of my designs are for commercial stuff, so being able to replace 2 specialist encoder chips with a fast easy interrupt is VERY attractive.

What I was saying was that since the encoder int only needs to check if any of the 4 pins pins have changed it is VERY fast, and uses almost no timeslice. In most cases the int routine is only going to be a handful of instructions, just to compare the last port reading to the new reading and then save the new reading. The int only needs to be called say every 1024 instructions (prescale 1:4) so it would be using less than 2% of processor time.

It really is the strength of PICs being able to replace costly and bulky external hardware with a few (free) PIC instructions in firmware.

If you were thnking educational, that would be the best thing to learn; ie how to get the PIC doing everything with almost zero external hardware. I think the educational institutions are to blame as they are too quick to throw chips at problems... The PIC IS the solution, not a problem that needs more chips thrown at it to get a solution. But that's just my way of looking at it.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top