PDA

View Full Version : pulsin problem using IOC with DT_int14.bas



longpole001
- 1st December 2012, 15:26
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 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


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






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

longpole001
- 1st December 2012, 21:41
also is there a define rctime_max statement simular to define pulsein_max for time out ?

Darrel Taylor
- 1st December 2012, 22:01
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.

longpole001
- 1st December 2012, 22:57
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

Darrel Taylor
- 5th December 2012, 03:19
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.

longpole001
- 5th December 2012, 09:00
thanks DT for clearing that one up, cheers

sheldon