DRSSTC Interrupter, PIC based / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

DRSSTC Interrupter, PIC based

previous 1 2 3

Move Thread

LAN_403

JimG

Mon Jun 05 2006, 01:21PM

Registered Member #52 Joined: Thu Feb 09 2006, 04:22AM
Location: Austin TX
Posts: 57

It doesn't matter which one gets dropped. This should illustrate what happens when you drop the most signifigant bit:

0  x       8 ccw    ->  0 ccw
1  ccw     9 x      ->  1 ccw
2  cw     10 x      ->  2 cw
3  x      11 cw     ->  3 cw
4  cw     12 x      ->  4 cw
5  x      13 cw     ->  5 cw
6  x      14 ccw    ->  6 ccw
7  ccw    15 x      ->  7 ccw

I don't think your code can be changed by just making the table shorter since you're not checking for the case where the encoder isn't being turned and are cleverly allowing for the for the invalid cases in the table to to just fall through.

Edit:

The way this falls out you could just add 2 to the value and check to see if the 3rd LSB is set. This may just simplify to doing a compare to see if there was a change, rotate the old value left by 1, and by b'0100', or that with the new value, add 2, and check the bit for a branch.

Update:

I got this to work with the above method using 3 bits, but the code isn't all that elegant and doesn't get the same bragging rights that a jump table does. I might be able to rework it to get rid of a few instructions, but I don't know if the effort is really worth it.

There's also a mistake in the description, the old value has to be rotated left by two.

Update 2:

I think I found a better 3 bit solution that exploits another another pattern that comes up if the msb of the previous value is the lsb of the current.

; load up the current encoder value
	movf	PORTA, W
	andlw	h'03' 
	movwf	encoderState

	; compare against the old encoder value
	xorwf	oldState, W
	btfsc   STATUS, Z
	goto	CheckButton


	; put the MSB of the old
	; state in the carry
	rrf	oldState, F
	rrf	oldState, F

	; rotate the current encoder state
	; left putting the carry value
	; in the LSB
	rlf	encoderState, W

	; store in a temperary place
	movwf	oldState

	; increment by 1 and check to see
	; if bit 1 is set
	incf	oldState, 1
	btfsc	oldState, 1
	goto	IncrementCounter

	; decrement counter
	decf	counter, F

	goto	EncoderUpdateDone

IncrementCounter
	incf	counter, F

EncoderUpdateDone
	movf	encoderState, W
	movwf	oldState

Update 3:

This could be even simpler. When rotating in one direction the msb in the previous and lsb in the current are the same value, when rotating in the opposite direction they're different. Only one bit from the previous value would need to be compared to one bit from the current value.

It's getting late and I've thought about this single issue way too much.

JimG

Wed Jun 07 2006, 02:29PM

Registered Member #52 Joined: Thu Feb 09 2006, 04:22AM
Location: Austin TX
Posts: 57

The solution that I came up with for the lsb and msb compare had the same number of instructions as my previous solution so I may just stick with this one.

Using the encoder feels a lot better than using buttons. The encoder that I have has 16 positions per revolution so it's a little slow to do large changes. I may do something where I detect how fast the encoder is changing and increment more if the duration is short. It may also be possible to just save all of the values to the eeprom so that it doesn't have to be setup every time the power is turned back on.

rupidust

Thu Jun 08 2006, 12:57AM

Banned
Registered Member #110 Joined: Fri Feb 10 2006, 12:23AM
Location: Banned City
Posts: 85

I always save the last settings in EEPROM so that on boost and load re-adjusting of any buttons or pots are not necessary unless the design dictates other wise. You can have buttons run just as smooth as an encoder by having good code to know difference between single and double tap, auto increment and auto acceleration of increments. Problem with buttons is that if you need multiple controls, you run out of i/o lines fast. Now as for a Potentiometer, I always use a pot instead of an encoder and use the pot with A2D lines by detecting change in pot voltage and not use the actual pot voltage value. Because coding is what determines the smooth natural feel of dec/incrementing a pot or button both work out good. Pots use less i/o lines but the drawback of a pot is that you need available A2D lines, which may not be available or non existanting for a particular PIC.

...

Thu Jun 08 2006, 01:24AM

Registered Member #56 Joined: Thu Feb 09 2006, 05:02AM
Location: Southern Califorina, USA
Posts: 2445

Actually you don't need a a2d line for pots, a normal i/o works fine... (I explained how to do this here in the 8th post) The only thing I have against them is that they only have a limited amount of possible motion, making them tricky to use for things requiring a large dynamic range (although that can be solved with good code)

rupidust

Thu Jun 08 2006, 08:40AM

Banned
Registered Member #110 Joined: Fri Feb 10 2006, 12:23AM
Location: Banned City
Posts: 85

... wrote ...

Actually you don't need a a2d line for pots, a normal i/o works fine... (I explained how to do this here in the 8th post) The only thing I have against them is that they only have a limited amount of possible motion, making them tricky to use for things requiring a large dynamic range (although that can be solved with good code)

True, no A2D needed for less demanding control, but using the old external capacitor discharge is slow, unreliable and not digitized which is what is needed here, predictable incrementations.

...

Thu Jun 08 2006, 02:02PM

Registered Member #56 Joined: Thu Feb 09 2006, 05:02AM
Location: Southern Califorina, USA
Posts: 2445

By selecting a decent cap you can make it go pretty fast... Just depends on the speed of the uC and the needed accuracy... If you want 100counts of information you only need a few hundred cycles of the processor to read the value... How is the result not digitised? A number is a number in my book... Admitidly, it is still p3ned by a simple rotary encoder for this project.

previous 1 2 3

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob