pulsin: how is it used

[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.

[dhouston]

You don't need either a rising or falling leading edge for PULSIN depending on the pin state when PULSIN is called.

I didn't read your code so my comments were based purely on the content of your posts. It wasn't clear that you were using separate PICs.

Another way to do this type of measurement is by using a soundcard as an oscilloscope. See...

• http://davehouston.org/learn.htm

While the URL deals with IR & RF codes, they're just pulsestreams so the principle is the same.

[Bruce]

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.

Sorry, but I respectfully dissagree with this.

Try this;

    DEFINE OSC 20
    DEFINE LOADER_USED 1

    PTIME VAR WORD
    PTIME2 VAR WORD
    
    SYMBOL PIN_PIN = PORTB.0
    TRISB = %11111101 
    
    PTIME = 0
        
MAIN:
    WHILE PIN_PIN = 0        ' wait for PIN_PIN to go high
    WEND
    
    HIGH 1 ' indicate PULSIN start
    PULSIN PIN_PIN,1,PTIME   ' this reads the pulse after the pin is already high
    LOW 1 ' indicate PULSIN complete
    
    PULSIN PIN_PIN,1,PTIME2  ' this reads it after the rising edge
    HSEROUT ["Pulse 1 width = ",DEC PTIME,13,10]   ' result = 0
    HSEROUT ["Pulse 2 width = ",DEC PTIME2,13,10]  ' result = 25419
    
    GOTO MAIN

I have a 12F675 programmed to output a train of pulses. 50mS high with a low period of
250mS between each high pulse.

See the analyzer capture below. P1A is the pulse train being read with PULSIN. P1B is RB1
going high just prior to the 1st PULSIN, and low when the 1st PULSIN completes.

Look at the A & B markers. Now look at the time A-->B: 181.9mS. 50mS of this period is
the 50mS pulse shown by P1A at the top. P1B is the high period RB1 stays high once the
1st PULSIN executes. Subtract 50mS. The remainder is the time-out period at 20MHz.

If PULSIN were not waiting for the leading edge, then it should always return the remainder
of the high time period in PTIME, but it doesn't. It returns zero.

Now if you shorten the low period between each high-going pulse to < the PULSIN time-out
period, it will record the 2nd high-going pulse. Not the first if started when the pin is in
the state to be measured.

So, what I'm seeing is - PULSIN does need to see the leading edge. It will however appear
to work, even if started after the leading edge, but will only record the time of the 2nd
pulse - if it happens prior to the time-out period.

I have tried several variations, and I just can't get any results if I start PULSIN after
a leading-edge transition. Except for it locking onto & recording a 2nd pulse that happens
before the time-out period expires.

[Bruce]

Here's a 2nd graphic showing how PULSIN records the 2nd high-going pulse. Note how P1B
doesn't return low until after the 2nd high pulse.

PULSIN didn't record the 1st because it started after the leading edge. It does grab the 2nd
since it happens before the time-out period. The delay between high pulses was shortened
to the time period shown at B-->C:

[xnihilo]

This is a lot of information, I will read it carefuly tomorrow, thanks a lot.
In, the meantime, I noticed a strange thing (I will also post my code tomorrow):

My routine reads 16 bits signal (PWM at 40KHz and TSOP4840 sensor-demod) through IR link using pulsin (each bit is 600Us either HIGH or LOW followed by a spacer of 600us LOW). The 16 bits are announced by a 2400 us HIGH followed by 600 us low. This header is ignored by the routine that waits for the header to end. The total length of the IR signal is (should be) about 22ms but when timing the routine that reads the signal, it takes (visualy, with a led) about 1 second!!! It is probably related to all the stuff we are talking about in the posts above.