Post by thread:TMR0 Latency

I am looking at a project requiring a very tight timing loop. Ideally I would have it accurate to a single instruction but maybe 1 instruction error could be tolerated. What delays are present in a TMR0 interrupt on overflow driven loop. The basic idea would be (assuming TMR0 overflow is the only enabled interrupt): delay EQU ... int_latency EQU ... ORG 0x004 MOVF delay SUBLW int_latency MOVWF TMR0 where delay is the number of cycles (if prescaler = 1:1) and int_latency is the total latency of the interrupt occuring and of setting TMR0. In this case int_latency would be 3 inst (MOVF-MOVWF) + the delay for the interupt to fire + the delay for the setting of TMR0. From reading the MChip docs I think that there is a 4 inst delay for the interrupt to fire and actually execute 0x004 for real, and a 2 inst delay for the update of TMR0 to kick in. Hence I would set int_latency to 4 + 2 + 3 = 9inst. Is this correct? Is there any jitter in the internal interrupt handling?

Thomas Brandon wrote: > I am looking at a project requiring a very tight timing loop. If so, I'd avoid interrupts like the plague! > Ideally I would have it accurate to a single instruction but maybe 1 > instruction error could be tolerated. The plot thickens! > What delays are present in a TMR0 interrupt on overflow driven loop. > The basic idea would be (assuming TMR0 overflow is the only enabled > interrupt): The delays are: 1} an extra cycle if the presently executed instruction modifies PC. 2} Interrupt latency - an interrupt modifies PC too! 3} context saving. > ORG 0x004 > MOVF delay > SUBLW int_latency > MOVWF TMR0 No context saving! Not workable. Need to save STATUS, W, maybe other things. May need to clear bank select to access TMR0. > where delay is the number of cycles (if prescaler = 1:1) and > int_latency is the total latency of the interrupt occuring and of > setting TMR0. In this case int_latency would be 3 inst (MOVF-MOVWF) + > the delay for the interupt to fire + the delay for the setting of > TMR0. From reading the MChip docs I think that there is a 4 inst delay > for the interrupt to fire and actually execute 0x004 for real, and a 2 > inst delay for the update of TMR0 to kick in. Hence I would set > int_latency to 4 + 2 + 3 = 9inst. Is this correct? Sounds plausible. Honestly, I would take that as an indication to forget using an interrupt for this purpose. > Is there any jitter in the internal interrupt handling? Yes, depends on whether it happens to hit a branch instruction. It sounds like you plan to enter a tight loop and use interrupts to do your timing. That sounds crazy to me. Unless you context save, it will be very difficult to avoid crashing the loop badly. The only conditional you could use within the loop is BTFSx. The loop couldn't do any useful processing anyway. As such, you'd be far better off to do the timing in the loop, wouldn't you? Latency would be guaranteed constant and about six instructions at most. Like all such mind-bending problems, I would suggest you disclose your real objective for suggestions. There are techniques posted for coding single-cycle resolution counting loops IIRC. -- Cheers, Paul B.

---- Original Message ----- From: Paul B. Webster VK2BZC <spam_OUTpaulbTakeThisOuTMIDCOAST.COM.AU> To: <.....PICLISTKILLspam@spam@MITVMA.MIT.EDU> Sent: Monday, October 18, 1999 11:17 PM Subject: Re: TMR0 Latency {Quote hidden}> Thomas Brandon wrote: > > > I am looking at a project requiring a very tight timing loop. > > If so, I'd avoid interrupts like the plague! > > > What delays are present in a TMR0 interrupt on overflow driven loop. > > The basic idea would be (assuming TMR0 overflow is the only enabled > > interrupt): > > The delays are: > 1} an extra cycle if the presently executed instruction modifies PC. > 2} Interrupt latency - an interrupt modifies PC too! > 3} context saving. > > > ORG 0x004 > > MOVF delay > > SUBLW int_latency > > MOVWF TMR0 > > No context saving! Not workable. Need to save STATUS, W, maybe other > things. May need to clear bank select to access TMR0. That's purposeful, there's too much to do in the given time to waste 6inst. saving context, everything would happen in the TMR0 interrupt to prevent context saves, sorry for not making clear. {Quote hidden}> > where delay is the number of cycles (if prescaler = 1:1) and > > int_latency is the total latency of the interrupt occuring and of > > setting TMR0. In this case int_latency would be 3 inst (MOVF-MOVWF) + > > the delay for the interupt to fire + the delay for the setting of > > TMR0. From reading the MChip docs I think that there is a 4 inst delay > > for the interrupt to fire and actually execute 0x004 for real, and a 2 > > inst delay for the update of TMR0 to kick in. Hence I would set > > int_latency to 4 + 2 + 3 = 9inst. Is this correct? > > Sounds plausible. Honestly, I would take that as an indication to > forget using an interrupt for this purpose. Not so much interrupts, just PIC interrupts. Scenix interrupts with "determnistic jitter free 60ns int., 100ns ext" interrupts with hardware context saves would be much more acceptable. > > Is there any jitter in the internal interrupt handling? > > Yes, depends on whether it happens to hit a branch instruction. That could be a problem. I don't need to do anything in the main code, but to infinitely loop I need lots of jumps (well, just one, but it's executed a lot), so there would be a lot of 2 cycle inst.'s. {Quote hidden}> It sounds like you plan to enter a tight loop and use interrupts to > do your timing. That sounds crazy to me. Unless you context save, it > will be very difficult to avoid crashing the loop badly. The only > conditional you could use within the loop is BTFSx. The loop couldn't > do any useful processing anyway. > > As such, you'd be far better off to do the timing in the loop, > wouldn't you? Latency would be guaranteed constant and about six > instructions at most. > > Like all such mind-bending problems, I would suggest you disclose your > real objective for suggestions. There are techniques posted for coding > single-cycle resolution counting loops IIRC. > -- > Cheers, > Paul B. The application is multi channel serial comms. As such, the task must be run with accurate timing but there is a lot to do in the given loop time and the amount of processing varies dramatically (a lot of the time the loop will do nothing as no serial lines are active). Hence, the time taken to calculate a variable delay and implement it is a big problem. Anyway, as suggested above, the scenix's interupts and speed are much more suited to this task so I believe I will switch. Thanks, Tom.

At 09:31 19/10/99 +1000, you wrote: {Quote hidden}>---- Original Message ----- >From: Paul B. Webster VK2BZC <paulbKILLspamMIDCOAST.COM.AU> >To: <.....PICLISTKILLspam.....MITVMA.MIT.EDU> >Sent: Monday, October 18, 1999 11:17 PM >Subject: Re: TMR0 Latency > > >> Thomas Brandon wrote: >> >> > I am looking at a project requiring a very tight timing loop. >> >> If so, I'd avoid interrupts like the plague! >> >> > What delays are present in a TMR0 interrupt on overflow driven loop. >> > The basic idea would be (assuming TMR0 overflow is the only enabled >> > interrupt): >> >> The delays are: >> 1} an extra cycle if the presently executed instruction modifies PC. >> 2} Interrupt latency - an interrupt modifies PC too! >> 3} context saving. >> >> > ORG 0x004 >> > MOVF delay >> > SUBLW int_latency >> > MOVWF TMR0 >> >> No context saving! Not workable. Need to save STATUS, W, maybe other >> things. May need to clear bank select to access TMR0. > >That's purposeful, there's too much to do in the given time to waste 6inst. >saving context, everything would happen in the TMR0 interrupt to prevent >context saves, sorry for not making clear. > >> > where delay is the number of cycles (if prescaler = 1:1) and >> > int_latency is the total latency of the interrupt occuring and of >> > setting TMR0. In this case int_latency would be 3 inst (MOVF-MOVWF) + >> > the delay for the interupt to fire + the delay for the setting of >> > TMR0. From reading the MChip docs I think that there is a 4 inst delay >> > for the interrupt to fire and actually execute 0x004 for real, and a 2 >> > inst delay for the update of TMR0 to kick in. Hence I would set >> > int_latency to 4 + 2 + 3 = 9inst. Is this correct? >> >> Sounds plausible. Honestly, I would take that as an indication to >> forget using an interrupt for this purpose. >Not so much interrupts, just PIC interrupts. Scenix interrupts with >"determnistic jitter free 60ns int., 100ns ext" interrupts with hardware >context saves would be much more acceptable. > >> > Is there any jitter in the internal interrupt handling? >> >> Yes, depends on whether it happens to hit a branch instruction. >That could be a problem. I don't need to do anything in the main code, but >to infinitely loop I need lots of jumps (well, just one, but it's executed a >lot), so there would be a lot of 2 cycle inst.'s. > >> It sounds like you plan to enter a tight loop and use interrupts to >> do your timing. That sounds crazy to me. Unless you context save, it >> will be very difficult to avoid crashing the loop badly. The only >> conditional you could use within the loop is BTFSx. The loop couldn't >> do any useful processing anyway. This may sound crazy for a PIC but is common code practice in a DSP type aplication, e.g. G728 to G711 conversion where processing is performed in blocks, but data is input and output on an 8kHz cycle {Quote hidden}>> >> As such, you'd be far better off to do the timing in the loop, >> wouldn't you? Latency would be guaranteed constant and about six >> instructions at most. >> >> Like all such mind-bending problems, I would suggest you disclose your >> real objective for suggestions. There are techniques posted for coding >> single-cycle resolution counting loops IIRC. >> -- >> Cheers, >> Paul B. > >The application is multi channel serial comms. As such, the task must be run >with accurate timing but there is a lot to do in the given loop time and the >amount of processing varies dramatically (a lot of the time the loop will do >nothing as no serial lines are active). Hence, the time taken to calculate a >variable delay and implement it is a big problem. > >Anyway, as suggested above, the scenix's interupts and speed are much more >suited to this task so I believe I will switch. Yeh go there. You say that timing is critical, well maybe, but it is realy only is on receive, which is asynchronus and all transmit may be sychronus to each other. The main problem is the speed of the incomming data. Sampling at 3 times the expected incomming data rate will remove the need to trigger an interrupt and line up the receiver, however the second method uses less processing power as you can then start sampling in the expected middle of the data stream etc. Whatever, enjoy Dennis