Hmmm... still tinkering with C18 and ran into this oddity...

#define S2_MIN 90
#define S2_MAX 125
#define S2_STEP 5
....
void main(void)
{
	...
	S2 =3D S2_MIN;				// Initialize
	...
	// (In button responder routine...)
	S2 +=3D S2_STEP;				// Increment to next value
	if (S2 >=3D (S2_MAX + S2_STEP))		// If max passed...
		S2 =3D S2_MIN;			// ...cycle back to start
	...
}

Every time S2 is incremented, the comparison checks to see if the max =20
value has been exceeded, and if so, it will reset it to the min value. =20
  But it fails.

If I change the comparison to this, it works...

	if (S2 > S2_MAX)
		S2 =3D S2_MIN;			// Cycle back around to start

Disassembly of the non-working code (with comments I've now added).  =20
0xc0 and 0xbf are the upper and lower bytes of S2 resp.  Computations =20
in comments are at S2=3D130.

845:               			if (S2 >=3D (S2_MAX + S2_STEP))
   0B16    0E82     MOVLW 0x82			// 130, correct.
   0B18    5DBF     SUBWF 0xbf, W, BANKED	// Result=3D0, so C=3D1, Z=3D1
   0B1A    0EFF     MOVLW 0xff
   0B1C    59C0     SUBWFB 0xc0, W, BANKED	// 511-0 is +ve, so C=3D1, Z=3D0=
..
   0B1E    E303     BNC 0xb26			// So this should not branch...?
847:               				S2 =3D S2_MIN;
   0B20    0E5A     MOVLW 0x5a
   0B22    6FBF     MOVWF 0xbf, BANKED
   0B24    6BC0     CLRF 0xc0, BANKED


If I understand what's happening here, the lower bytes are subtracted =20
first, and C is carried over into the next operation where the upper =20
byte is subtracted.  Not sure why 255 is being used for that though.  =20
But at S2=3D130, C should be 1 when it reaches the BNC instruction.  =20
But's it's skipping the code after that branch.  What's really =20
confusing me here is the SUBWFB instruction.  I've looked at the =20
datasheet for it and the examples provided for its use, and can't see =20
how they get those results.

Huh?



--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.