+ Reply to Thread
Results 1 to 12 of 12
  1. #1
    Join Date
    Dec 2010
    Location
    Melbourne Australia
    Posts
    51

    Default DT Elapsed Timer Question

    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

  2. #2
    Join Date
    May 2013
    Location
    australia
    Posts
    1,470

    Default Re: DT Elapsed Timer Question

    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
    This is more entertaining than Free to Air TV

  3. #3
    Join Date
    Dec 2010
    Location
    Melbourne Australia
    Posts
    51

    Default Re: DT Elapsed Timer Question

    Quote Originally Posted by richard View Post
    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

  4. #4
    Join Date
    May 2013
    Location
    australia
    Posts
    1,470

    Default Re: DT Elapsed Timer Question

    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
    Last edited by richard; - 8th August 2018 at 03:43. Reason: edit
    This is more entertaining than Free to Air TV

  5. #5
    Join Date
    May 2013
    Location
    australia
    Posts
    1,470

    Default Re: DT Elapsed Timer Question

    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
    This is more entertaining than Free to Air TV

  6. #6
    Join Date
    Dec 2010
    Location
    Melbourne Australia
    Posts
    51

    Default Re: DT Elapsed Timer Question

    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!

  7. #7
    Join Date
    May 2013
    Location
    australia
    Posts
    1,470

    Default Re: DT Elapsed Timer Question

    you may get some ideas here
    http://support.melabs.com/forum/picb...ond-pass/page2

    where I failed to convince longpole on the merits of timestamps over elapsed_int
    I think there is a 24 bit asm version somewhere too but I can't find it .
    This is more entertaining than Free to Air TV

  8. #8
    Join Date
    Dec 2010
    Location
    Melbourne Australia
    Posts
    51

    Default Re: DT Elapsed Timer Question

    Richard,
    so, the last link: take the stopwatch example (from a layperson's perspective), I can't see significant difference in overhead between say this and the elapsed timer example but I'm probably missing something? Like, am I correct in concluding there's a awful lot going on for when an interrupt is triggered like saving system variables and whatnot, or as in your stopwatch code, both the timer1 and timer3 interrupts call a PBP subroutine with assembler commands within and because of this, the system variables don't require backup and restoring after each interrupt activation? Apologies for what might be dumb questions, I'm trying to get my head around this.

    Troy

  9. #9
    Join Date
    May 2013
    Location
    australia
    Posts
    1,470

    Default Re: DT Elapsed Timer Question

    I can't see significant difference in overhead between say this and the elapsed timer example
    correct there is not much overhead difference when pbp interrupts are used , main point was to show that time accuracy using time stamps is easy versus trying to fudge clock counts
    so that elapsed_int could be used without modification and also to show that conversion to h:m:s is not too difficult

    the main difference between asm and pbp interrupts is whats entailed in ReEnterPBP.bas code . its up to the user to determine if the application can tolerate the overhead or a more efficient method need be developed
    This is more entertaining than Free to Air TV

  10. #10
    Join Date
    Dec 2010
    Location
    Melbourne Australia
    Posts
    51

    Default Re: DT Elapsed Timer Question

    So, if I was to make an interrupt routine that only incremented a... say 16 bit variable - say 3 or 4 lines of assembler and that's all it did - would I be risking too much to not back up the system variables?

  11. #11
    Join Date
    May 2013
    Location
    australia
    Posts
    1,470

    Default Re: DT Elapsed Timer Question

    if your isr's only use asm code then there is no need to back up any pbp working registers at all , mcu context must always be saved and restored in the isr process. most advanced core pic's have auto context save/restore otherwise that need to be added to the isr process too, refer to your datasheet
    This is more entertaining than Free to Air TV

  12. #12
    Join Date
    Dec 2010
    Location
    Melbourne Australia
    Posts
    51

    Default Re: DT Elapsed Timer Question

    Thanks again Richard. I might have crack at a bleeding minimum overhead routine over the weekend and see what happens.

Similar Threads

  1. DT Elapsed Timer
    By retepsnikrep in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 14th December 2017, 23:21
  2. Elapsed Timer findings
    By Art in forum General
    Replies: 40
    Last Post: - 18th June 2015, 19:14
  3. Elapsed Timer Demo
    By Darrel Taylor in forum Code Examples
    Replies: 111
    Last Post: - 29th October 2012, 17:39
  4. SPWM and Elapsed Timer
    By CocaColaKid in forum mel PIC BASIC Pro
    Replies: 12
    Last Post: - 8th May 2008, 03:16
  5. DT Elapsed Timer
    By rwskinner in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 9th March 2008, 23:17

Members who have read this thread : 18

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts