Darrel Taylor Elapsed Timer


Closed Thread
Results 1 to 15 of 15

Hybrid View

  1. #1
    Join Date
    Oct 2005
    Posts
    74


    Did you find this post helpful? Yes | No

    Default

    I did check, and I do have the following fuses set in my programmer.

    Osc = HS, FSCM = on, Brown Out = Enabled,
    Low Power Timer1 Osc = Low Power ??? Was default

  2. #2
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    Try it like this, and see if the Low Priority RX_INT helps.
    Code:
    DEFINE  USE_LOWPRIORITY  1
    INCLUDE "DT_INTS-18.bas"       ; Base Interrupt System
    INCLUDE "ReEnterPBP-18.bas"    ; Include if using PBP interrupts
    INCLUDE "ReEnterPBP-18LP.bas"  ; Include if using Low Pr. PBP INTS
    INCLUDE "Elapsed_INT-18.bas"   ; Elapsed Timer Routines
    
    ;----[High Priority Interrupts]-----------------------------------------------
    ASM
    INT_LIST  macro    ; IntSource,        Label,  Type, ResetFlag?
            INT_Handler   TMR1_INT,  _ClockCount,   PBP,  yes
        endm
        INT_CREATE               ; Creates the High Priority interrupt processor
    
    ;----[Low Priority Interrupts]------------------------------------------------
    INT_LIST_L  macro  ; IntSource,        Label,  Type, ResetFlag?
            INT_Handler     RX_INT,     _Receive,   PBP,  no
        endm
        INT_CREATE_L             ; Creates the Low Priority interrupt processor
    ENDASM
    
    @    INT_ENABLE  TMR1_INT     ; Enable Timer 1 Interrupts  
    @    INT_ENABLE  RX_INT       ; Enable USART Receive interrupts
    DT

  3. #3
    Join Date
    Oct 2005
    Posts
    74


    Did you find this post helpful? Yes | No

    Default

    That works better.


    Is this causing my problem since they are PBP Interrupts, it's not exiting like it should...

    AdcMaxReads is at 64, Each time I loop I increment the channel, that way I only do 64 reads per loop.


    GetADC:
    ADCVAL = 0
    ADCAVG = 0

    For AdcCnt = 1 to AdcMaxReads
    ADCIN NextChan,ADCVAL
    ADCAVG = ADCAVG + ADCVal
    Next AdcCnt
    Reg[NextChan] = ADCAVG / AdcMaxReads

    NextChan = NextChan + 1
    If NextChan = 10 then 'Cycled thru all 9 analogs
    If (LowBatSP > 0) Then
    BatVolts = Reg[8]
    GoSub CheckBat
    EndIf
    NextChan = 0
    EndIf
    Return





    Main:
    Gosub GetADC
    Goto Main

  4. #4
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    Those A/D statements are in the Main Loop, they will not have any affect on the interrupts.
    However, you haven't initialized the NextChan variable before starting. It may take several thousand readings from invalid channels before falling back into line when it rolls over.
    But much like the RX handler, you may not have included that part of the program.

    That works better.
    Does that mean it's counting at 1 second intervals now?

    If so, then the problem is in your RX handler. If you have a Timeout value in the HSERIN statement, it sits in the interrupt until it either receives ALL the data, or it times out. Or if there's no timeout, it simply waits until it's received enough data before returning.

    If that handler is a High Priority interrupt, then no other interrupts can occur until it's returned from that handler. Timer1 would then probably miss many interrupts.

    By making the RX handler a Low Priority interrupt, it allows the (high priority) TMR1_INT to continue on without conflict.
    <br>
    DT

  5. #5
    Join Date
    Oct 2005
    Posts
    74


    Did you find this post helpful? Yes | No

    Default

    Oh, I have lots of initilized variables in my Init: routine before it drops into the Main. But thanks.

    Yes, it's counting properly now. You 100% correct, I moved my prewritten HSerIn call from the previous main loop and copied it up there. I did not think about the time out but the timeout is only set to 5.

    Holy Cow, Also on timeout, I have it going back to the Receive label as well, I think that is the issue.
    Better make that the Interrupt Exit...
    WAS


    'Receive Interrupt
    Receive:
    'Clear the buffers before anything
    GOSUB ClearBuffers

    HSerIn Timeout,Receive,[WAIT(MyID)] <---- Opps
    For Cnt = 1 to 7
    HSerIn Timeout,Receive,[BufRX(Cnt)] <---- Opps
    Next Cnt
    Gosub ProcessData
    ExitRx:
    @ INT_RETURN




    Changed to

    'Receive Interrupt
    Receive:
    'Clear the buffers before anything
    GOSUB ClearBuffers

    HSerIn Timeout,ExitRx,[WAIT(MyID)]
    For Cnt = 1 to 7
    HSerIn Timeout,ExitRx,[BufRX(Cnt)]
    Next Cnt
    Gosub ProcessData
    ExitRx:
    @ INT_RETURN
    Last edited by rwskinner; - 12th March 2008 at 04:15. Reason: Added more comments

  6. #6
    Join Date
    Oct 2005
    Posts
    74


    Did you find this post helpful? Yes | No

    Default

    Would it be better to do something like this and get rid of the WAIT?
    Just Grab the first byte and see if it's for me, if so process, else Exit Interrupt....

    'Receive Interrupt
    Receive:
    'Clear the buffers before anything
    GOSUB ClearBuffers

    'Instead of waiting, grab the first byte and see if it's for me or Exit
    HSerIn Timeout,ExitRx,[BufRX(0)]
    If (BufRx <> MyID)
    Goto ExitRx
    End If

    For Cnt = 1 to 7
    HSerIn Timeout,ExitRx,[BufRX(Cnt)]
    Next Cnt

    Gosub ProcessData
    ExitRx:
    @ INT_RETURN

  7. #7
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    It might be a little better, but there's a much better way.

    Receive 1 byte at a time in the handler

    If you get an interrupt from the USART, you are guaranteed that there is at least 1 byte in the USART's buffer.

    So when you get to the handler, just get the byte that you know is there. No Timeouts, no sitting around waiting for the next byte to finally come in. Serial data is Really slow compared to the speed of the processor. It doesn't make sense to waist millions of instructions sitting around waiting for serial data.

    After getting the byte, exit the Handler. If there is another byte still in the buffer, then DT_INT's will automatically loop back around to grab the next one, without ever leaving the interrupt processor.

    Then all you need to do is watch for the synchronizing character, and count how many bytes have been received. If you get a sync byte, reset the count. If you count the correct number of bytes received, set a flag to tell the main loop that the receive succeeded.

    Something like this off the top of my head...
    Code:
    TempByte  VAR BYTE
    RXdone    VAR BIT
    
    'Receive Interrupt 
    Receive: 
        HSERIN [TempByte]          ; Get the byte
        IF (TempByte = MyID) THEN  ; is it the sync byte?
            Cnt = 0                ; Yes, reset the counter
            RXdone = 0             ; indicate, RX not finished
            @  INT_RETURN          ; Return, and discard the sync byte
        ENDIF  
    
        BufRX(Cnt) = TempByte      ; Not a sync byte. save it.
        Cnt = Cnt + 1              ; increment buffer pointer
    
        IF (Cnt = 7) THEN          ; If all bytes are received?
            RXdone = 1             ; Tell Main loop to process it.
    
                                         ; If the main loop cannot process
    ;       FOR Cnt = 0 to 6             ; the data before the next sync byte?
    ;          RX_Data(Cnt) = BufRX(Cnt) ; Copy it to another "Working" buffer
    ;        NEXT Cnt                    ; Reception will continue while the 
        ENDIF                            ; last packet is processed
                                         
    @ INT_RETURN
    
    ;---------------------------------------
    Main:
    ;   ...
        IF RXdone then Gosub ProcessData
    ;   ....
    GOTO Main
    
    ;---------------------------------------
    ProcessData:
        RXdone = 0
    ;   ....
    ;   ....
    RETURN
    This will use the least amount of time required to receive serial data. And the main loop has much more time to do whatever it needs to. And allows many more interrupts to happen too, if needed.

    Just make sure that the Sync byte can NEVER be found in the data bytes. This goes for the way you had it too.

    If you are sending data in the form of Bytes, it's likely that a data byte will have the same value as the sync byte. If that's possible, you'll need to develop a multi-byte synchronization, or transmit the data in plain text (HEX is the easiest).

    HTH,
    <br>
    DT

Similar Threads

  1. Elapsed Timer Demo
    By Darrel Taylor in forum Code Examples
    Replies: 111
    Last Post: - 29th October 2012, 17:39
  2. High Resolution Timer & Speed Calculator
    By WOZZY-2010 in forum Code Examples
    Replies: 4
    Last Post: - 7th February 2010, 16:45
  3. Timer interrupt frequency
    By Samoele in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 17th January 2009, 23:49
  4. using darrel taylor's instant interrupts
    By Michael Wakileh in forum mel PIC BASIC Pro
    Replies: 13
    Last Post: - 31st July 2007, 04:07
  5. timer interupt help 16f73
    By EDWARD in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 3rd July 2005, 08:41

Members who have read this thread : 0

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