pulsin problem using IOC with DT_int14.bas

Hi guys , not sure why this problem is happening but appears to be fixed by using rctime instead of pulsin in section 1 when using IOC and DT_int_14.bas

background
-----------
chip 12F683, compiler 3.0.6.1

. pulsin is to capture a IR signal which has a 9ms low going header pulse then a 4.5ms high pulse , then 32bits of data , then sends a 2nd 9ms low pulse followed by 2.5ms high pulse for the 2nd key data

test1 - using section 1( using pulsin) and section 2 (rctime) of the code does what is expected and works when setup using as normal subroutine , eg called in main program not using the IOC and not enabling the subroutine via DT_int_14.bas

test2 - If i change the code in section 1 to from pulsin to use rctime instead and IOC and enable the subroutine using DT_int_14.bas it works ok and data is captured ok ,

problem - when i use pulsin in section 1 as per original subroutine using IOC and DT_Int14.bas - the data section of the IR string is not captured

think it has to be the way pulsin and IOC int flag is treated by DT_int_14.bas when looking at 2 signal within the same routine , but i am guessing ,

any clue why ,what am i missing on why this works ok in rctime and not pulsin for section 1 of the pulse check test


cheers

sheldon

Code:

---

' code to allow use of IOC
 
INCLUDE "DT_INTS-14.bas"
INCLUDE "ReEnterPBP.bas"
ASM
INT_LIST macro        ;      IntSource,        Label, Type, ResetFlag?
                  INT_Handler TMR0_INT, _Timer0_Count,  PBP,  yes    ; call Timer0_Count subroutine
            INT_Handler  GPC_INT,  _GetIRcode,  PBP,  yes    ; call GetIRcode subroutine on Interupt
    endm
        INT_CREATE                                                                ; Creates the Interrupt Processor
ENDASM

---

i have enabled IOC prior to getircode

Code:

---

IOC.0=1                        ' Enable Change in Interrupt on GP0.0  for when its a input in GetIR routine

---

Code:

---

GetIRcode:
     

    TRISIO.0  = 1                            ' setup input=1,output=0 GPIO.0 = 1 to input
 
' --- section 1 , ---
  PULSIN IR,0,Leader                        ' get leader low pulse time value in on GPIO.0  ( pulsin_max set to 21600 = 108ms )
    IF Leader < 1700 or  Leader > 1850 tHEN  ' look for 9000us Low pulse of header for 1st or 2nd key area pulse 
    test =1  'debug                          ' reject if < 8500us  or > 9250us (1700^ 5us= 8500us)
@ INT_RETURN 
return
    endif
 

' --- section 2 ---
    RCtime IR,1,Leader                        ' check for 1st key seq high pulse for 4.5ms after the 9ms low pulse so no repeat headers or 2nd key
    if Leader < 850  or Leader > 950 then      ' if high for < 4250ms  then its the 2nkey or > 4750us ( invalid pulse) ( 850 * 5us = 4250us)
test = 2  'debug
@ INT_RETURN     
return
  endif

                             
  test = 3  ' debug
' - is valid data for collection at this point       
 
 FOR X = 0 TO 31                  ' grab 32 incoming pulses
      PULSIN GPIO.0,1,leader      ' now measuring high-going pulse widths
      BtnVal(x) = leader/2        ' leader divide by 2 so Btnval(x) is byte (<255) not word value 
  NEXT X

---

also is there a define rctime_max statement simular to define pulsein_max for time out ?

PULSIN has to see the edge of the pulse, but since you are using GPC_INT, the interrupt saw the edge before PULSIN started.
RCTIME does not need to see an edge.

DEFINE PULSIN_MAX affects both PULSIN and RCTIME.

thanks Darrel , as always your help is very much appreciated ,
could not see anything in any manuals searched that said that defined pulsin_max affected rctime max ,
since rctime is half a pulsin , does this mean that the half the max of pulsin is applied to RCtime max value ?

cheers

Sheldon

I think the statement in the manual that says "It is basically half a PULSIN", is refering to the operation of the commands, not the resolution of them.
PULSIN has to see both edges of a pulse, RCTIME only needs to see the trailing edge.

Both commands have 10uS resolution with a 4Mhz oscillator.
And DEFINE PULSIN_MAX places the same limit on both commands, which is the number of "Periods" until it times out.

But really, since you are using interrupts ... measure the pulses with a Timer, or the CCP module.
Let the Hardware do the work, and your program can be off doing other things.

thanks DT for clearing that one up, cheers

sheldon