problem timer0 interrupt simulation for 12f675

[sachin]

Hi,

I want timer0 interrupt of 254us using 4 Mhz clock.
I have written small progam as given below,when I tried to
simulate it gives 283 us.I am using PCM 148.

/*************************************/
#include <12F675.H>
#use delay(clock=4000000)

int int_count;

#INT_TIMER0
_TMR0()
{
set_timer0(0);
}

void main()
{
set_timer0(0);
//setup_counters(RTCC_INTERNAL,RTCC_DIV_1);
setup_timer_0(RTCC_INTERNAL|RTCC_8_BIT|RTCC_DIV_1);
enable_interrupts(INT_TIMER0);
enable_interrupts(GLOBAL);

while(1)
{
int_count=1;
}
}

/*************************************/

Thanx,
sachin
___________________________
This message was ported from CCS's old forum
Original Post ID: 12696

[Tomi]

<font face="Courier New" size=-1>Imagine this:
- You set timer0 to 0. The next IT is fired after 256 cycles.
- At the ISR you have context saving instructions. This is approximately 25 cycles. In normal cases it is not a problem because the timer continues running.
- In the ISR you overwrite the content of the timer to 0 (with your settings the previous content of the timer reg. was cca. 25)

So if you want to make 256us periodicity then just remove your set_timer0(0) call from your ISR.
If you want to make 254us period then use set_timer0(27) at first sight then find the exact number .

:=Hi,
:=
:=I want timer0 interrupt of 254us using 4 Mhz clock.
:=I have written small progam as given below,when I tried to
:=simulate it gives 283 us.I am using PCM 148.
:=
:=/*************************************/
:=#include <12F675.H>
:=#use delay(clock=4000000)
:=
:=int int_count;
:=
:=#INT_TIMER0
:=_TMR0()
:={
:= set_timer0(0);
:=}
:=
:=void main()
:={
:= set_timer0(0);
:= //setup_counters(RTCC_INTERNAL,RTCC_DIV_1);
:= setup_timer_0(RTCC_INTERNAL|RTCC_8_BIT|RTCC_DIV_1);
:= enable_interrupts(INT_TIMER0);
:= enable_interrupts(GLOBAL);
:=
:= while(1)
:= {
:= int_count=1;
:= }
:=}
:=
:=/*************************************/
:=
:=Thanx,
:=sachin</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 12702

[R.J.Hamlett]

:=Hi,
:=
:=I want timer0 interrupt of 254us using 4 Mhz clock.
:=I have written small progam as given below,when I tried to
:=simulate it gives 283 us.I am using PCM 148.
Welcome to the world of latency...
The problem is that when the ISR occurs, there is a short delay before the actual response, and then quite a lot of code to save critical registers, before you enter the routine itself. Unfortunately, this implies that when your 'set_timer0' instruction is called, several uSec, will have allready passed.
There are two solutions.
The first is to manually 'tweak' the set_timer value, as needed, either using a real measurement, or by taking the assembler code, and calculating the delay. This is OK, but is hard work.
Your version, will have the ISR called when the timer is at 0 (on the wrap from FF to 0), and then it will have counted up by about 27, before you execute the 'set'. Hence you are actually slowing the response by this amount...
The second (I think better), is instead, to move the timer 'forwards' by the required amount. The only caveat here, is how much the value may change between the internal read and the write.
So:

#byte TIMER0=1
and then:

TIMER0+=4;

inside the interrupt handler,

Should give the required timing. You will still get a small 'jitter' between perhaps 253, and 255uSec.
This approach is _essential_, if your main code, has the interrupts disabled at any point, since when this happens, the latency to the interrupt event will change, and lead to cumulative errors, while using the 'increment' approach (provided the disabled period is still short enough to allow the seperate interrupts to be handled), will 'self compensate' for this change.
The value has to be incremented by more than it would appear to need, since the timer will increment during the addition, and this increment gets lost.

Best Wishes

:=/*************************************/
:=#include <12F675.H>
:=#use delay(clock=4000000)
:=
:=int int_count;
:=
:=#INT_TIMER0
:=_TMR0()
:={
:= set_timer0(0);
:=}
:=
:=void main()
:={
:= set_timer0(0);
:= //setup_counters(RTCC_INTERNAL,RTCC_DIV_1);
:= setup_timer_0(RTCC_INTERNAL|RTCC_8_BIT|RTCC_DIV_1);
:= enable_interrupts(INT_TIMER0);
:= enable_interrupts(GLOBAL);
:=
:= while(1)
:= {
:= int_count=1;
:= }
:=}
:=
:=/*************************************/
:=
:=Thanx,
:=sachin
___________________________
This message was ported from CCS's old forum
Original Post ID: 12703

[Tomi]

:=Should give the required timing. You will still get a small 'jitter' between perhaps 253, and 255uSec.

No 'jitter'. The input of the timer is the PIC's clockout itself.

:=since the timer will increment during the addition, and this increment gets lost.

Same conclusion: if the addition is executed under 3 machine cycles then the timer will incremented exactly (and always) by 3.
___________________________
This message was ported from CCS's old forum
Original Post ID: 12706

[R.J.Hamlett]

:=:=Should give the required timing. You will still get a small 'jitter' between perhaps 253, and 255uSec.
:=
:=No 'jitter'. The input of the timer is the PIC's clockout itself.
:=
:=:=since the timer will increment during the addition, and this increment gets lost.
:=
:=Same conclusion: if the addition is executed under 3 machine cycles then the timer will incremented exactly (and always) by 3.

No.
You will find that the increment doesn't behave as you expect (unfortunately...). Because the increments occur on the instruction 'edges', you miss both the increment at the start of the instruction, and the second one at the end of the instruction. This leaves you having to add 4 not 3 (which I would agree would instinctively seem to be the right value). Also the processor itself, has slightly different latency in some instructions. This depends on what is being done in the main loop, but even with interrupts permanently enabled, you will find that if the loop is running code (as opposed to just sitting in a 'while' loop), the interrupt response will vary by one instruction time.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12709

[Tomi]

Disagree. The increment is delayed by 2 cycles (historically, this delay was designed to get the right timer register value after executing a "save timer content into RAM" instruction pair:
movf RTCC,W
movwf RAM_location
)

The clkout signal is changed typically after 75ns after the rising edge of Q3 (rising edge) or Q1 (falling edge).

Note that I have a PIC-based frequency meter to calibrate the 32768Hz clock of RTC circuits. The F-meter gives me a typically 1ppm accurate output in every 2 seconds (and it works, our clocks have cca. 1ppm accuracy after fine tuning). So it _is_ possible to eliminate the jitters.

:=You will find that the increment doesn't behave as you expect (unfortunately...). Because the increments occur on the instruction 'edges', you miss both the increment at the start of the instruction, and the second one at the end of the instruction. This leaves you having to add 4 not 3 (which I would agree would instinctively seem to be the right value). Also the processor itself, has slightly different latency in some instructions. This depends on what is being done in the main loop, but even with interrupts permanently enabled, you will find that if the loop is running code (as opposed to just sitting in a 'while' loop), the interrupt response will vary by one instruction time.
:=
:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12711

[sar]

Hello Tomi
About the jitter; read this. I beleive this is what RJ is talking about. <a href="http://www.romanblack.com/one_sec.htm" TARGET="_blank">http://www.romanblack.com/one_sec.htm</a>
SAR
___________________________
This message was ported from CCS's old forum
Original Post ID: 12713

[Tomi]

I don't think so.
That document is talking about:
"Interrupt is every 256 counts.
We want to generate a 1 second event.
(24bit variable requires 3 PIC registers.)
"
The described jitter is comes out because of the 24-bit calculations (what is necessary because we want to make precision 1 second period) inside of the ISR (the execution time of the simplified addition/subtraction is depended on the content of the 24-bit time register). But the main concept based upon the fact "TIMER0 interrupt is set to occur every 256 instructions".

:=Hello Tomi
:=About the jitter; read this. I beleive this is what RJ is talking about. <a href="http://www.romanblack.com/one_sec.htm" TARGET="_blank"> <a href="http://www.romanblack.com/one_sec.htm" TARGET="_blank">http://www.romanblack.com/one_sec.htm</a></a>
:=SAR
___________________________
This message was ported from CCS's old forum
Original Post ID: 12714

[R.J.Hamlett]

:=Hello Tomi
:=About the jitter; read this. I beleive this is what RJ is talking about. <a href="http://www.romanblack.com/one_sec.htm" TARGET="_blank"> <a href="http://www.romanblack.com/one_sec.htm" TARGET="_blank">http://www.romanblack.com/one_sec.htm</a></a>
:=SAR
No, I'm talking about a difference in interrupt response that I have found on some PIC's in certain instructions. It probably does not apply here (it may not apply with any of the simpler chips), but (for instance), I have found that some of the instructions like CPFSGT, on the 18F chips, appears to require two instruction times to respond to an RTCC interrupt (this disagrees with what MicroChip say in their data sheet, where they state that one and two cycle instructions will have the same latency), but is the only way to explain the jitter I have observed. If I loop with this instruction inside the loop, there is a one instruction time 'jitter' in the resulting period. If I toggle an output pin in the interrupt handler, the frequency remains constant, but the high and low timer can occasionally change (if you get a 'long' time on one cycle, you get a short one next time, unless the main code is in exactly the same place).
It may be a fault with the silicon in this case, but it is something possibly to be aware of. It gave me a real problem...

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12720

[Tomi]

Sure, 18F chips are another story
The following instructions:
CPFSEQ,CPFSGT,CPFSLT,DECFSZ,DCFSNZ,INCFSZ,INFSNZ,TSTFSZ
is executed under 1, 2, or 3 machine cycles depending whether the condition is true or false and whether the next instruction right after these instructions is 1- or 2-word long.
(IMHO the 18F chips _aren't_ Harvard machines - they fit (sometimes hardly, that's true) all of requirements to be a von Neuman machine.)
However, the original thread is talking about a 12F675 which is an "ordinary" Harvard proc.

:=No, I'm talking about a difference in interrupt response that I have found on some PIC's in certain instructions. It probably does not apply here (it may not apply with any of the simpler chips), but (for instance), I have found that some of the instructions like CPFSGT, on the 18F chips, appears to require two instruction times to respond to an RTCC interrupt (this disagrees with what MicroChip say in their data sheet, where they state that one and two cycle instructions will have the same latency), but is the only way to explain the jitter I have observed. If I loop with this instruction inside the loop, there is a one instruction time 'jitter' in the resulting period. If I toggle an output pin in the interrupt handler, the frequency remains constant, but the high and low timer can occasionally change (if you get a 'long' time on one cycle, you get a short one next time, unless the main code is in exactly the same place).
:=It may be a fault with the silicon in this case, but it is something possibly to be aware of. It gave me a real problem...
:=
:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12730

[R.J.Hamlett]

:=Sure, 18F chips are another story <img src="http://www.ccsinfo.com/pix/forum/smile.gif" border="0">
:=The following instructions:
:=CPFSEQ,CPFSGT,CPFSLT,DECFSZ,DCFSNZ,INCFSZ,INFSNZ,TSTFSZ
:=is executed under 1, 2, or 3 machine cycles depending whether the condition is true or false and whether the next instruction right after these instructions is 1- or 2-word long.
:=(IMHO the 18F chips _aren't_ Harvard machines - they fit (sometimes hardly, that's true) all of requirements to be a von Neuman machine.)

Several instructions are two cycles long on even the 12 family chips. INCFSZ, DECFSZ, BTFSC, BTFSS, CALL, GOTO, all the return forms. Now the data sheets all say, that the latency remains the same on the multi-cycle instructions, yet this is not the case. The jitter exists.
It is the seperate data, and program memories that distinguishes the Harvard architecture. This allows instructions to be fetched, and memory operands to be fetched in the same machine cycle, _but the definition does not require instructions to be single cycle_. It makes this possible, but not compulsory...
The Von Neumann architecture, doesn't have this distinction, but again makes no direct reference to the number of cycles needed for an operation (but the shared single pipeline, _forces_ multiple cycles for any instruction requiring access for two purposes).

:=However, the original thread is talking about a 12F675 which is an "ordinary" Harvard proc.
:=
They are both Harvard architecture devices.

:=:=No, I'm talking about a difference in interrupt response that I have found on some PIC's in certain instructions. It probably does not apply here (it may not apply with any of the simpler chips), but (for instance), I have found that some of the instructions like CPFSGT, on the 18F chips, appears to require two instruction times to respond to an RTCC interrupt (this disagrees with what MicroChip say in their data sheet, where they state that one and two cycle instructions will have the same latency), but is the only way to explain the jitter I have observed. If I loop with this instruction inside the loop, there is a one instruction time 'jitter' in the resulting period. If I toggle an output pin in the interrupt handler, the frequency remains constant, but the high and low timer can occasionally change (if you get a 'long' time on one cycle, you get a short one next time, unless the main code is in exactly the same place).
:=:=It may be a fault with the silicon in this case, but it is something possibly to be aware of. It gave me a real problem...
:=:=
:=:=Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12732

[Tomi]

:=Several instructions are two cycles long on even the 12 family chips. INCFSZ, DECFSZ, BTFSC, BTFSS, CALL, GOTO, all the return forms. Now the data sheets all say, that the latency remains the same on the multi-cycle instructions, yet this is not the case. The jitter exists.

On 12 and 16 series PICs the 2nd cycle of a 2-cycles instruction (when the PC is modified or the condition is true so a skip involved) is executed separately as a NOP. E.g. a BTFSS instruction is executed as:
1. cycle: execute bit test and check for IT.
2. cycle: execute NOP to skip the next instruction. Check for IT under NOP. No jitter.

:=It is the seperate data, and program memories that distinguishes the Harvard architecture.

What means "data" and what means "program"? If I can save data into the program memory as real data and later I can jump onto that data to execute them as instructions then it is not a "pure" program memory anymore. You have a loader for flash devices, haven't you?
___________________________
This message was ported from CCS's old forum
Original Post ID: 12733

[R.J.Hamlett]

:=:=Several instructions are two cycles long on even the 12 family chips. INCFSZ, DECFSZ, BTFSC, BTFSS, CALL, GOTO, all the return forms. Now the data sheets all say, that the latency remains the same on the multi-cycle instructions, yet this is not the case. The jitter exists.
:=
:=On 12 and 16 series PICs the 2nd cycle of a 2-cycles instruction (when the PC is modified or the condition is true so a skip involved) is executed separately as a NOP. E.g. a BTFSS instruction is executed as:
:=1. cycle: execute bit test and check for IT.
:=2. cycle: execute NOP to skip the next instruction. Check for IT under NOP. No jitter.
:=
It happens...

:=:=It is the seperate data, and program memories that distinguishes the Harvard architecture.
:=
:=What means "data" and what means "program"? If I can save data into the program memory as real data and later I can jump onto that data to execute them as instructions then it is not a "pure" program memory anymore. You have a loader for flash devices, haven't you?

These do not affect the core processor architecture. In these cases the access to the program memory, by an instruction, are done by a separate path as a _peripheral_ operation. You do not do a data write to the program memory, but instead select the address you want to write to, and then trigger a write in the external hardware. This does not change the core architecture.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 12743