On Mon, 28 Dec 1998 10:46:51 -0800 "Mitchell D. Miller" writes: >Wouldn't this also work? It doesn't have the GOTO, but seems to >acomplish the task ...?? > > org 4 > bcf INTCON, TOIF > incf Counter_Lo, f > btfsc Z > incf Counter_Hi, f > retfie No, it won't work, because it changes the Z flag. The main program will fail because the Z flag changes unexpectedly. There are a lot of ways to do it. I would suggest incfsz counter_lo,f retfie incfsz counter_hi,f retfie retfie If counter_lo is not zero after incrementing, the first return is taken. Otherwise counter_hi is also incremented and one of the other returns taken. (The count can be expanded simply to any number of bytes by replacing the last return with another increment.) Returning as soon as possible saves time. However, it may be desirable that the ISR always take the same amount of time, so it uses a constant percentage of the CPU's instructions. In that case, the one already presented is good: incfsz counter_hi,f nop incfsz counter_lo,f decfsz counter_hi,f nop retfie Here, we increment counter_hi and increment counter_lo always. If there is not a carry out of counter_lo, we decrement counter_hi. The net result is that counter_hi is usually unchanged, unless counter_lo increments to zero. In that case counter_hi is left incremented as it should be. The routine always takes the same amount of CPU time (7 cycles) The original poster's first routine, which he thought was unusable, is actually the fastest way to do it. The trick is that the count can't be interpreted conventionally. Here's that routine: incfsz counter_lo,f incfsz counter_hi,f nop ;For ultimate speed, retfie here too. retfie This one always increments counter_lo, and increments counter_hi unless counter_lo rolls over. So the count goes (in decimal) Lo Hi Total counts 0 0 0 1 1 1 2 2 2 ... 255 255 255 0 255 256 1 0 257 2 1 258 ... 255 254 511 0 254 512 1 255 513 ... 255 0 65535 0 0 65536 At this point, the 16-bit count has rolled over and started again. Counter_lo is already the correct low byte of the 16 bit count. To derive the high byte, do an 8 bit subtract of counter_hi from counter_lo: Hi byte = counter_lo - counter_hi A similar approach decrements counter_hi in the ISR instead of incrementing it. The correction is similar, just subtract in the reverse order. It makes a little more sense. In all cases of a 16-bit count, the main program has to be sure an interrupt dosen't occur and change the count inbetwwen reading (or writing) the two bytes of the count. Also of course there is a big problem with all of these on PICs with multiple *data* memory pages, since it can't be certain that the page select bits are set properly to access the counter variables. One workaround to that is for the main program to use indirect access for all data the page other than the one with the counter varaibles. Then the RP bits can remain set for the counters. ___________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com/getjuno.html or call Juno at (800) 654-JUNO [654-5866]