PULSIN - Logic Level Voltage Transiion

Might anyone be familiar enough with the PULSIN command to know the voltage level a "logic High" starts? Looking at the PIC documentation (18F4520) there are several levels listed for "Input High Voltage". In particular I am trying to see what effects signal rise and fall times are having on my measurements.

For example,
I am running at 32 MHz, therefore I expect the resolution of the PULSIN command to be around 1.25 usec. Looking at the pulse on the oscope, the positive pulse width is 6 usec. I take 100 PULSIN samples and then divide the result by 100 to get an average, as follows:

TRIGGER VAR PORTA.2
TRIG_FREQH VAR LONG
TRIG_FREQHA VAR LONG

For I=1 to 100
TRIG_FREQH=0
WHILE TRIGGER=1:WEND 'MAKE SURE I DON'T START IN THE MIDDLE OF A PULSE
PULSIN TRIGGER,1,TRIG_FREQH
TRIG_FREQHA=TRIG_FREQHA+TRIG_FREQH
Next I
TRIG_FREQHA=TRIG_FREQHA/100 'AVERAGE NUMBER OF HIGH COUNTS
TRIG_FREQHA=125*TRIG_FREQHA/100 'CHANGE TO USECs 1.25 USEC/CNT

The value I am getting is around 3, which makes we wonder if since this is a pretty small pulse width rise/fall times might have become an issue???? If it makes a difference, the pulse low time is 4995 usec which I seem to be measuring accurately using the same method.

If anyone can help, it would be greatly appreciated. CC

You need to look at the datasheet to see the details for the pin you are using. In this case PORTA.2 is TTL when used as an input. Then you look at the DC characteristics to see the input high level for TTL which depends on Vdd but should be about 2V or a bit less in any case.

Table 10.1 and Table 26.3 tell you what you need. You might also try measuring between rising edges to see if the period is what you think it is.

Thanks Dave,
I will try your recommendations when I get to work tomorrow. Looking at the rise time 9 ns today makes me think that that is probably not the problem. Takes a lot of 9 nsec to add up to 3 usec I am going to look at it closely so at least I understand more about what is going on and the effects of rise/fall times in general. Looks like you have a bunch of stuff I need to look at on your web site. So much to do, so little time. Thanks, again. CC

Hi, CC

@ First, you have to undersand how Pulsin works ...

1) input is set to an ... Input !
2) software counter is initialised and waits for the required edge to come ...
3) leading Edge detected ... the counter ... counts ( unbelievable, eh ? )
4) trailing edge detected ... counter stops counting ( see 3 )
5) counter value is transferred to the target variable.

from that ....

1) you need a little delay between the Pulsin command and the effective counting can start ( presetting delay )
2) you need a little delay between the counting is finished and a new command to be executed ...

after that ...

Code:

---

WHILE TRIGGER=1:WEND 'MAKE SURE I DON'T START IN THE MIDDLE OF A PULSE

---

is not useful ... as the pulsin command triggers ... on a level CHANGE ... :surprise:

If measuring very short times ... your result will be either 3 or 4 ( example ) ... and precision will be VERY, VERY bad ...

So, ... it appears this way of measuring is " not so good " and you'd much better use the CCP module,in capture mode, with the 1/16 predivisor ... or if more samples required, a CD 4520 as an external 1/100 divider.

AND ... YES, you've hit the Basic languages functions ( not only PBP ) limitations .... :chargrined: ... so, you have to directly drive the Pic registers !!!

Alain

Alain,
Thanks you very much for the clear explaination of how the pulsin function works! I will investigate the CCP capture mode method.
Thanks, again.
CC