hjl4

Hi,

I hope someone out there has done this in assembly before.
I took apart a mouse, and removed the encoder wheels, along with the IR Led's.
I want to use this, as an encoder for an accelerator, using 2 bit gray code.
In other words, when thumb pressure is applied to a spring returned knob, it send gray code to micro. 16f628.
I can't use interupt as it is all ready used by a safety switch. My delema is knowing the direction(accel or deccelerate)the encoder is going. As the encoder is moved clockwise, the micro needs to increase speed of dc motor, and decrease when moving ccw. My guess is ,I should get 4 different speeds. Right?

I have searched this forum, and others, and there search engines sucks..with no good results.
I have googled, and everybody including there dog, has done this.
Unfortunately, I don't have time learning CHBasic or even C. I write in assembly exclusively.
I hope someone can help.
Thank you!

Nigel Goodwin

There's more assembler code than anything else available, so using assembler is an advantage.

However, I don't think your scheme will work?, a mouse encoder doesn't output grey code, it's just a quadrature encoder. So you only get speed and direction, NOT absolute position.

The conventional way for throttle control is to use a pot.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

Mike, K8LH

Correct me if I'm wrong, but, it seems you would like to use one of the encoders for a speed control by determining if there's been a change and by the direction of the change, clockwise or anti-clockwise...

Polling the encoder A and B lines is perfectly acceptable... You can determine if the encoder has moved simply by checking a saved ENCOLD value to the current encoder value... You can determine which direction the encoder has moved by exclusive-or'ing the A or B bit of the old encoder value with the opposite bit of the current encoder value... After determining direction, adjust your speed value or variable up or down accordingly...

Good luck with your project... Regards, Mike

hjl4

Thanks Mike and Nigel.
Last night I was very tired, as I worked on this all day.
And I could'nt visualize how this could be done.
Your right Nigel when you say it would'nt be grey code. What was I thinking?
And Mike I will definately go your way. Now that I have slept, I am refreshed, and now I can see the whole picture.

What sleep can do.
If I get stuck on this, I'll make sure to follow up. And if success, I will post my code here, to see if it could be optimized in any way.

Thanks Guys.

motion

Before we start finding solutions to your problem, I have some issues with your assumptions:

By decoding which interrupt flag was set, you can use interrupts from several sources simultaneously.

Unless you need response times in order of microseconds, you don't really need interrupts to detect the safety switch closure. With a properly designed program, you can poll the safety switch once every 1-10 msec for instance. This is still faster than how most mechanical systems can respond anyway.

It might be more of a pain to remanufacture the mouse into an optical encoder. It will be easier to find a PS2 mouse program to receive the step and direction signals already encoded in the serial PS2 protocol. You will need to use interrupts here though. Hence, if you insist on using interrupts for the safety switch, you would need to decode the interrupt source to use two interrupts simultaneously. Or you could also use a serial mouse.

If you convert the mouse into an optical encoder, you need to poll the signals at high speed to detect transistions. If you miss two transistions between polls, you can no longer determine the direction last taken. Interrupts will be useful here.

BTW, the quadrature signal from the encoder is in 2-bit gray code.
http://www.nist.gov/dads/HTML/graycode.html

Lastly, there are PICs with built-in quadrature decoders.

__________________
"Having to do with Motion Control"

Oznog

Polling could be hokey if the motor speed is significant. You need to dedicate a lot of time to polling.

Polling could be done, but from what you say, you may not need to do this. You say the ext interrupt is taken up by a safety switch, and in any case a single interrupt won't read gray code. That's what the interrupt-on-port-change RBIE/RBIF is for. This will cover any changes in portB<7:4> pins configured as inputs, so any of these 4 you don't use as encoder inputs should be used for an output to avoid useless interrupts.

__________________
I thought what I'd do was I'd pretend I was one of those deaf-mutes.

hjl4

Thanks Oznog,

I thought I had read that somewhere. So if I set up Portb as interupt, lets say bit 1 and 2 are inputs and the rest outputs, I can still have bit 3 and 4 as outputs?
If so, That would save me from trying to see what i can squeeze out of the Pic. I'll have plenty of pins left over.
The Datasheets can be so overwhelming sometimes.
I'll read it again, and see if I can set it up that way. It would save precious time, instead of frequent continuous polling.



Thanks.

Mike, K8LH

We're only talking about polling the rotary encoder which is being used as a control, not polling a rotary encoder attached to a motor...

Polling (and debouncing) the encoder switches, or any switches for that matter, can be automated as a background task quite easily using an ISR (interrupt service routine)... I often use TMR2 1.0-msec interrupts and ISR code for switch management to provide such niceties as switchpress audio feedback (40-msec short beeps), 'short' and 'long' switchpress detection, and rotary encoder translation to pseudo "INC" and "DEC" switches...

Kind regards, Mike

philba

I'd definitely use RBIF but timer driven sampling should work as well. You can pretty easily estimate the speed of of the quad encoder pulses. 1mS might be a bit slow as you should be sampling at least 2X the max rate.

I've played with mouse encoders and some of them can be flakey. I wound up building a state machine that factored in glitches and it worked pretty well. just consider all possible transitions and you should be fine. I used the RBIF (int on change) feature of a midrange PIC.

Mike, K8LH

hjl4 (and gang),

As you can see, there's many many different ways to accomplish the same thing... Don't be afraid to experiment and try different methods... The interrupt on change method is certainly just as viable as an interrupt driven polling method and there are subtle and not so subtle advantages and disadvantages to each method... Many times your hardware design may force you to use a particular method...

I've found rotary encoders with a built-in push button switch on the shaft (PEC11 series and NSE120 series) can provide rather simple and elegant single front panel control solutions for some projects... Rotate the encoder to scroll through LCD menus, select values from a list, or to increment or decrement values... Decode 'short' and 'long' encoder push button switch presses for <OK>, <ESC>, or <TAB> type functions...

Regards, Mike

hjl4

Hi Mike,

I have'nt had time to work on my encoder or program.
I 'm trying to read thru your first reply, and I'm having a bit of problem making sense of it.
If I use quadrature encoder, and turn it beyond it's 2 bits(3h), how does the Pic know if I am rotating it clockwise or ccw if I go beyond the 2 bit limit. I mean after 01,11,10,00, and then what???. Does the Pic see this as a reset back to 01?
I have an encoder with total of 25 steps.(optical that is).

Maybe I'm way over my head here.
I can't seem to grasp the concept.

Anyways,Thanks for your replies.

Nigel Goodwin

It's a question of which bit changes first, this tells the program which way it's turning.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

mstechca

You can define a rectangular area so that you can create absolute positions with your mouse.

In your code, you need to compare whether each and every mouse move goes out of the area, and if it does, have it return to the last spot in the area.

It's just like the mouse arrow on your screen. It never falls off of the screen completely. You still see at least one pixel even if you moved it to the bottom right.

__________________
-=: The best low-priced components to troubleshoot with are the speaker and the LED :=-

hjl4

Ok I'll try that .

If I still can't get it, I'll be back.

Thanks.

panic mode

you don't have to kill yourself with loads of code if you can live with one more chip (dual D-type flip flop). this way all you have to do is count up or down:
http://www.engr.colostate.edu/~dga/m...gures/9-16.gif