DT Elapsed Timer Question

[rocket_troy]

I've experimented with DT's elapsed timer on a PIC18F26K22 @16MHZ and modified the code to send the output to a serial port as opposed to LCD screen. I've found that the timer is counting perfect time, but much of the serial data is constantly corrupted. Is this to be expected? If I send data via the same serial command with the timer and all the interrupts disengaged, there's no corrupt data.

Thanks,

Troy

[richard]

Is this to be expected?

yes , any software timed process can be adversely affected by the huge overhead imposed by a dt int style pbp interrupt.
there are many solutions :-
in no particular order
1. lower the baud rate till errors minimised
2. disable interrupt during transmission
3. run chip at 64mhz to minimise isr latency
4. use the eusart
5. send 1 chr at a time with isr disabled to minimise "lost" interrupts

[rocket_troy]

yes , any software timed process can be adversely affected by the huge overhead imposed by a dt int style pbp interrupt.
there are many solutions :-
in no particular order
1. lower the baud rate till errors minimised
2. disable interrupt during transmission
3. run chip at 64mhz to minimise isr latency
4. use the eusart
5. send 1 chr at a time with isr disabled to minimise "lost" interrupts

Richard,
I suspected so and thanks for the great tips! Which raises another question: so the end goal was to run the DT elapsed timer in the background for another application (same chip) with lots of processing going on (constant I2C sensor acquisition from 2 devices, EEPROM writing, constant A>D conversion, a fair chunk of numerical processing). So, there's no serial comms during this, but lots happening, so is it likely to expect the elapsed timer to corrupt some of this processing or acquisition? - I'm using PBP3's I2C commands for the I2C comms but doing the A>D acquisition via direct register access.

Thanks again,

Troy

[richard]

so is it likely to expect the elapsed timer to corrupt some of this processing or acquisition?

not really , i2c command is software timed but a synchronous process so not overly disturbed if pic is master.
eprom write command disables interrupts anyway so unaffected.
adc should be ok too conversion is done in hardware, acquisition time may be affected but not in a bad way [aq time is a minimum EXTRA WON'T HURT]
edit , I should qualify that statement with "unless you are doing some advanced sampling eg .like a fft "

its a trade off for elapsed timer accuracy with async processes worst affected

[richard]

if all you want is time keeping ,then a long var can used as an elapsed millisecondx10 counter and updated in an asm isr say every 10ms
for practically no overhead. its then pretty simple math to convert to H:M:S when needed for display

[rocket_troy]

Yeah, it's basically to generate a time stamp in say (1/10 sec resolution) for the data being sensed and packaged. The entire duration of the acquisition period won't be any more than 5 minutes and I'm quite happy to post process a single number into something more meaningful also. So, it sounds like I'll need to learn some assembly interrupt service routines Thanks again for the great advice - much appreciated!