settimer and hi2c on 28X1

[matherp]

I know this has been discussed before but I can't find the answer to my specific question.

I need to run the timer to provide a long-term timebase for an application. In the main program loop I'm using many hi2c commands, I'm not using any of the timing sensitive non-hardware commands (e.g.readtemp). At the moment every so often the i2c bus becomes corrupt. My 28X1 is version A.5

I assume that this is because an i2c interrupt is lost during the processing of a timer interrupt as per previous posts on the forum

I'm also assuming that the internal hardware timer interrupt occurs when the minor tick variable overflows from 65536?

I'm using the t1s_16 set up for the timer but running the processor at 4Mhz so the timer variable updates every 4 seconds.

My main processing loop takes just over a second to complete.

My question therefore is:
If I wait in code for the timer variable to have just ticked as follows:

w0=timer
do
w1=timer
loop until w0<>w1

Can I then be certain that for nearly 4 seconds there will be no underlying timer interrupts that can conflict with the hi2c commands allowing me to process my main loop before going back into the wait loop

Thanks

Peter

 

[Technical]

I'm using the t1s_16 set up for the timer but running the processor at 4Mhz so the timer variable updates every 4 seconds.

That doesn't work. The timer overflow needs to be set for the resonator speed in use. They ae not straight multiples at different resonator speeds. You need to setup a 4 second delay at 4MHz, not a 1 second delay at the 16MHz setting.

Is your i2c work as a master or as a slave?

 

[matherp]

The 4 seconds count for 4Mhz is = 4s/64us = 62500, therefore pre-load is 65536-62500 = 3036 which is the same as literal value of t1s_16. That bit works OK.

I'm using the hi2c as master.

regards

Peter

 

[Technical]

You are correct in this case. But the maths doesn't always work out like that at different frequencies due to word overflow issues.

If there is no other internal interrupts going on (as with an i2c slave into scratchpad) then the timing should be fine.

This is a bit shorter!

w0=timer
do
loop until w0<>timer

But remmber this will not give you 4 seconds - it will give you anything up to 4 seconds. This is because you don't know when you enter the existing timer tick - ie if you enter only half way through you will only have 2 seconds to the next tick.