(Original email from Scott follows my reply) Well, I'm finally ready to start playing with this code. The boards are done, The main USB stuff seems to be working ok, and I have the encoders all up and running. It's not in a case yet, but Spehro will be helping me with that, and we've both been too busy to connect. So I guess I have no excuses...I must get on with the debouncing! I've been reading over the following routine, and before I implement it, I just want to be sure of a couple of things. 1. At the end of the macro, the changes will be in W and I can save them out. A 0 bit would mean the corresponding input has changed, while a 1 bit means it's held steady, correct? This will only happen when it changes state, right? For example, if I hold down a key for 100 iterations of the macro, I will get a 0 at the first transition, then it will all be ones, then a 0 at the end when I release, correct? 2. My inputs have pull ups, so when no buttons are pressed, I should end up with 0xFF in all the CVA registers. Would a good way to check if I have a key pressed in that bank (not a transition, one that is held, depending on the answer to the above question) just be to add one to the CVA and see if I trip the Z flag? Thanks! Josh -- A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. -Douglas Adams On 1/2/06, Scott Dattalo wrote: > > Hi Josh, > > My routine requires 3-bits per switch, or 4-bits if you wish to track when > a switch changes states (which is something you requested in your original > post). You have 64 switches, so 64*4 = 256 bits = 32 bytes are required. I > don't think you need to bother saving the raw, scanned values. The > de-bounce routine is so short that you can just call it whenever a scanned > value is obtained. > > I think the easiest approach is to turn the routine into a macro and > in-line it with your scan code. Unroll the scan loop to simplify things > even more. I don't know the details of your code, but you probably can > even write a macro to scan your matrix. > > > mMatrixScan 0 > mDeBounce PORTB, clock_A0, clock_B0, cva_0 > movwf changes0 > > mMatrixScan 1 > mDeBounce PORTB, clock_A1, clock_B1, cva_1 > movwf changes1 > > .... > > mMatrixScan 7 > mDeBounce PORTB, clock_A7, clock_B7, cva_7 > movwf changes7 > > The mMatrixScan macro scans one group of 8 switches. Here it's assumed > that PORTB contains the un-filtered switch state. The mDeBounce macro > filters one group of 8 switches. Its inputs are the variables needed for > the algorithm. At the end of the macro W will contain the change of state. > And this is stored in the 'changesX' variable. > > Here's the routine in macro form > > mDeBounce macro _csa, _count_A, _count_B, _cva > > ;Increment the vertical counter > MOVF _count_B,W > XORWF _count_A,F > COMF _count_B,F > > ;See if any changes occurred > MOVF _csa,W > XORWF _cva,W > > ;Reset the counter if no change has occurred > ANDWF _count_B,F > ANDWF _count_A,F > > ;If there is a pending change and the count has > ;rolled over to 0, then the change has been filtered > XORLW 0xff ;Invert the changes > IORWF _count_A,W ;If count is 0, both A and B > IORWF _count_B,W ;bits are 0 > > ;Any bit in W that is clear at this point means that the input > ;has changed and the count has rolled over. > > XORLW 0xff > XORWF _cva,F > endm > > If you're using an 18F device, then it would be reasonable to use indirect > addressing. For the mid-range family, this routine will get a little > unwieldy with indirect addressing and double in size. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist