pulsin: how is it used

[xnihilo]

Hello,

I would like to use pulsin to record the length of a positive pulse, thus I would use

pulsin trigger,1,pulse_length

if trigger is a pin name and pulse_length is a word variable

As I don't know when the trigger will happen, can I jump to the pulsin when I detect a low to high change on a pin (using a polling loop or an interrupt) or is PULSIN expecting to see the rising edge.
As I understand it from the manual, it will record the pulse even if already on and will stop recording once the pin goes low, it it right?

I don't know if my question is clear enough?

'*******************************************************************************
'preset the pic specs and config words at chip programming time
@        device  pic16F684, intrc_osc_noclkout, BOD_OFF, PWRT_OFF, wdt_off, mclr_off, protect_off
'*******************************************************************************


'*******************************************************************************
DEFINE OSC 8			'set OSC value to 8MHz for instructions PAUSE, PAUSEus and SOUND
'*******************************************************************************

'*******************************************************************************
'VARIABLES declaration
'IF VARIABLES USED FOUR COUNTER GO OVER 256, USE WORD INSTEAD

pulse_length var word
'*******************************************************************************


CLEAR                     'clears all data ram (128 bytes) and initialize variables (this should however be done in software)

INTCON = 0              'disable interrupts and reset int flags
IOCA = %000000

'*******************************************************************************
'PWM (single output mode) related registers for porta.5.
'PWM is not used. We use normal output on C5.

T2CON = %00000000			'value:4, 1:1 postscale (unused), Timer2 is OFF, Timer 2 Clock prescaler = 1
PR2 = %00110001			'value: 49, PWM Period: 40.0KHz
CCP1CON = %00000000		'capture/compare/PWM module OFF, no pwm signal on portc.5 at this time
CCPR1L = %00001111		'value: 15, PWM Duty Cycle 8 MSB of 10 bits (2 LSB in bits 5 and 4 of CCP1CON), total: 60d
'*******************************************************************************


'*******************************************************************************
'Setting registers

OSCCON = %01110001
CMCON0 =  %00000111			'comparators OFF, val = 7
ANSEL = %00000000			'choose digital i/o, val = 0
OPTION_REG = %01111111 			'enable porta weak pullups (no weak pull-up available for porta.3), p12
'*******************************************************************************


'*******************************************************************************
'Setting ports states, direction and internal weak pull-ups
'USE 10K WPU on RA3 if used as input !!!

TRISA = %000001 				'set porta pins directions (1=input, high impedance),portA.3 is always input pin (datasheet p5)
TRISC = %000000
'use 10K WPU on A3                              
WPUA =  %000000 			

PORTA = %000000 			'set port pins logic, A0 will be a default LOW with 100K WPD
PORTC = %000000 			'set port pins logic
'*******************************************************************************
'*******************************************************************************
'aliasing pins

Symbol trigger = PORTA.0
SYMBOL led = PORTC.3
'*******************************************************************************

PAUSE 3000             'let the power level stabilize if not already done

'flashes at 5Hz
for i = 0 to 4
    High led
    PAUSE 100
    LOW led
    PAUSE 100
NEXT i

PAUSE 2000

start:

While (trigger == 0) : WEND        'while pin is low (no pulse on pin)

'a pulse has been detected (at this step the rising edge is over, the pin is high)
PULSIN trigger,1,pulse_length   '16 bits

WRITE 0,pulse_length.lowbyte
WRITE 1,pulse_length.highbyte

'flash when recording occured and finished (max 327ms with 8MHz 5 us resolution 65536 increments)
HIGH led
PAUSE 2000
LOW led

goto start

END                     'end of program

[dhouston]

... can I jump to the pulsin when I detect a low to high change on a pin (using a polling loop or an interrupt)...

Yes, it does not look for the leading edge. An interrupt will be more precise but a tight loop works almost as well.

[Bruce]

I'm pretty sure it does wait for the idle state, and then look for the starting edge to begin
timing, so you might want to test this.

The library routine indicates this, and the manual also states; if the pulse edge
never happens or the width of the pulse is too great to measure, Var is set to zero.

        call    STATECNT        ; Wait for idle state
        btfsc   STATUS, Z       ; If timeout then it's over
        goto    DONE
        call    STATECNT        ; Wait for starting edge
        btfsc   STATUS, Z       ; If timeout then it's over
        goto    DONE
        call    STATECNT        ; Do the count

[xnihilo]

Dhouston you think it does not expect a rising edge while Bruce you are pretty sure it does.
When I read the manual info about PULSIN it looks like there is an EDGE detection...

The manual says that it waits for and EDGE, you're right but the I don't know how I am supposed to start PULSIN if I don't know when the EDGE will appear on the line and PULSIN has a timeout.

Something very weird:

To do some experiment, I've tested the code I've posted above (a polling loop). In this configuration, PULSIN will NOT see a rising edge but will start no matter what, so I assume PULSIN begins and runs until it sees a falling edge (which is not the way you tell me PULSIN works) or until the timeout happens because the pulse is too long.
I connected my application circuit to the tespin and I trigger my application circuit where I set the pulse pin HIGH at the begining of the code section for which I want to mesure the execution time then set the pin low when I reach the end of the section. This way, I expect PULSIN to tell me how long it takes to execute a section of a program.

I get a value of 14925~14927.
If I read well PBP manual, as I'm using a PIC16F684 (with DEFINE OSC 8) the resolution should be of 5US per iteration of the PUSLIN internal counter. Which makes 74ms.
What a surprise because in the application circuit in the section of code I'm testing, I use a 80ms pause, so the mesured execution length should be of AT LEAST 80ms...
How is it possible???

[dhouston]

As I wrote, PULSIN does not wait for a leading edge. If the pin is already in the the state of the defined "pulse", it starts counting as soon as PULSIN is called and stops counting when the trailing edge is detected. If the pin is initially in the non-defined state, the count starts at the leading edge. The disparity between your readings and your expectations is just due to the limits of accuracy using this method.

However, you cannot use it to time any execution other than itself as it does not return until it detects the trailing edge.

The manual is ambiguous, referring to an edge but not specifying both edges must be detected. Initially, I interpreted it as you (and Bruce) have but found, through experience, that was not the case. Other PBasic derived dialects for PICs that I've used are explicit about waiting for a leading edge.

@BRUCE: If you look at the NEC RF example i posted to Code Examples, removing the statements that wait until the initial space (trailing the long starting pulse) ends, the loop will detect that first space, giving an invalid code as a result.

[xnihilo]

Dhouston: So if I get you right, you DON'T need a rising edge for PULSIN?

I connected 2 PICS together so the 690 for which I want to time a code chunk sends a pulse to the 684 that will record the pulse length and then display the value to an LCD.
Obviously I cannot use PULSIN the way you thought I do

"The disparity between your readings and your expectations is just due to the limits of accuracy using this method."
-> This is not really a problem. Although I'm disapointed by the strange value I get, the method will always be the same so I only want to compare the execution duration of two different chunks of code. I already noticed that the second chunk I'm timing leaves a led on for about 1s which is far beyond the timeout of PULSIN, no wonder it returns a value of 0... This is because I have LCDOUT and WRITE that may take some time to execute.