> From: Mark K Sullivan > > >3) I was planning on using TMRO but I'm not clear on how to use so it > >interrupts the main code every 600ms. (i.e the display will be updated every > >600ms). Of course if the "freeze" button is pressed the time will update > >internally but the display will not update until it is released. > > Since you say the 600mS is for display update (which I'm not sure I understand. > I would probably use the interrupt to keep time and let the main loop update the > display whenever it is idle.), it shouldn't be critical. Just set the prescaler > to 16 and let the timer overflow continuously. This will give you 500 mS with a > 32.768 KHz crystal. Also 500 mS is nice if you take my hint and use the TMR0 > interrupt for timing. If it has to be 600 mS, set the prescaler for 32 and load > 102 into the timer every time you get an interrupt. 32768/4/32*.6 = 154 and > 256-154 = 102. That'll get you about between 601.5 and 601.6 mS. Note: when a new value is loaded into TMR0, there is a 2-cycle latency before the counter starts updating again. Thus for a 154-cycle loop, load TMR0 with 256+2-154 = 104. As Microchip notes in the data sheet this will compensate for the latency. I have used this technique to generate exact 100us loops with no jitter. Another important note: do not merely load TMR0 with a new value, since the actual timings then become dependent on the number of cycles executed in the interrupt routine before the TMR0 reload (i.e. you will have to count cycles). It's a matter of taste, but I prefer to ADDWF a constant to TMR0 since it is then independent of interrupt latency etc. Use the following since it worked for me with a PIC16C84: CYCLES equ 154 ... movlw 259-CYCLES addwf TMR0,f The desired number of cycles are subtracted from 259 to compute the amount by which to bump the clock forward. As I mentioned on this list way back, there is a discrepancy between the 259 constant versus the expected 258. 259 is required (at least in the '84), implying that the device actually has a 3-cycle latency, not 2 as the doc would have it). At 32768Hz, 154 cycles is 601.56125ms. The 600ms required is quite extraordinary (why not use 500ms since it can be generated exactly?). If this is indeed required, one way I have used to generate timings at frequencies which are not simple divisions of the clock frequency is to generate 'corrections' every now and again. In this example, since the clock is running 'slow' at 601.6ms, every few times through the loop the timer should be cut short i.e. use loop delay of 153 cycles = 597.65625ms. Find the smallest integer constants A and B such that (A+B)*600 = A*601.56125 + B*597.65625. If A and/or B are too large, pick different loop times. Ideally, one of A or B should be 1 since this simplifies the loop logic. [Anyone got a good algorithm for finding A and B?] > > > - Mark Sullivan - > Regards, SJH Canberra, Australia