PULSIN?

[retepsnikrep]

A question about Pulsin.

We know Pulsin watches a pin for a pulse and times it's length giving a value in units. Great it's a useful command.

However if we issue a pulsin command a timer must be started somewhere, as it times out after a period if no pulse received. No problem with that.


Assuming this 'timer' is a word (0-65535) what happens in the following scenario?

1) Pulsin command issued.

2) Pulsin sits waiting for a pulse (internal timer ticking away?)

3) Just before the timeout kicks in a pulse appears.

4) Does the hidden timer now restart to measure the length of the incoming pulse with a full (0-65535) available or does it start timing from wherever the hidden timer had got to by this time, say 65500 etc.

Resulting in a strange result as incoming pulse may not have finished before Pulsin reaches 65535 etc.

I imagine it must be interrupt driven and restart timer when pulse start is detected.

 

[hippy]

There are effectvely two timers. The first times how long until the pulse starts and if it overflows back to zero the command aborts returning a value of zero. If a pulse is seen a second timer times the pulse and also aborts if the timer overflows back to zero and returnes zero.

No interrupts used, timing is done by simply polling the input, incrementing the timer in a loop which takes 10us ( 5us on X2 ).

 

[kamilan]

Thats actually a very good question.

From the PDF(s) it is suggested that if a high is detect on the PIN within the 0.65536s of the timeout then it will record the length of the pulse. It will measure the pulse and then go on to the next line of code.

But honestly, I'm not sure what happen internally.

 

[westaust55]

Hippys clarification needs to be added to the manual

 

[kamilan]

i second that!

 

[retepsnikrep]

So at 4mhz the pulse must appear before the no Pulse timeout (0.65536S) is reached, and it can be a max of (0.65536S) in length once detected.

The command could take upto 1.3S to execute if a full length pulse appeaerd just as it was going to time out.

Interesting. Thanks for clarification re timers.

 

[hippy]

The manual seems quite clear to me ...

Function: Measure the length of an input pulse.

Information: The pulsin command measures the length of a pulse. In no pulse occurs in the timeout period, the result will be 0. If state = 1 then a low to high transition starts the timing, if state = 0 a high to low transition starts the timing

That clearly states that if no pulse arrives within the timeout period a result of 0 is returned. A pulse, when detected within the timeout period, "starts the timing" and measures the pulse length as kamilan has interpreted correctly in post #3.

It seems self evident to me that a command which measures the length of a pulse does not measure the length of a pulse less the time from when the command commenced execution or, as noted, the command would be entirely useless for its intended purpose. However, it is not unreasonable to seek clarification when some query arises, though in this case it appears to be based upon an assumption of how the command may work which is not the way it does. My description in post #2 is equally not correct in the way the software actually works but is a description of how the software appears to behave. The same way as the manual describes its function.

 

[manuka]

As mentioned before, this "sleeper" PULSIN shows promise for beating wireless SERIN hangups.

'Simple HopeRF HM-TR TTL half duplex data exchange-Stan Feb.09
'PICAXE08M "Pin"1 -HopeRF TTL pin 6 (ENABLE),and status LED
'PICAXE08M "Pin"2 -HopeRF TTL pin 4 (DRX) data input from 08M
'PICAXE08M "Pin"4 -HopeRF TTL pin 2 (DTX) data output to 08M
'Uses PULSIN command as a handy timed out signal sensor.
'Consider PICAXE brown out detect (BOD) if v9.2 08M firmware
'Ref.schematic=> www.picaxe.orconhosting.net.nz/hopettlapp.gif
'Breadboard=> www.picaxe.orconhosting.net.nz/hopettlapp.jpg

hopettl:
high 1                   'bring HopeRF out of hiberation
serout 2,t2400,(85,85,85,85,"ttl",b0) 'tx beacon
pulsin 4,0,b1            'listen & briefly await any reply
if b1=0 then hopettl     'if nothing heard then resend beacon

serin 4,t2400,("ttl"),b0 'if signal heard then accept serial data 
low 1                    'enter low drain TTL sleep 
sleep 13                 'PICAXE low current SLEEP (~30 secs)
goto hopettl             'repeat routine

 

[MartinM57]

...is there a chance that the reply could come back before the pulsein gets itself up and running - so would never detect anthing as it has already missed it?

Maybe OK with the HopeRF models but I'm playing with an external device at 115400 baud and it also replies "pretty darn quick" to anything I send it.

EDIT: could the SRLatch in the X2 range be used to catch a returning reply? (somehow - I've never used that feature)

 

[westaust55]

The manual seems quite clear to me ...

Function: Measure the length of an input pulse.

Information: The pulsin command measures the length of a pulse. In no pulse occurs in the timeout period, the result will be 0. If state = 1 then a low to high transition starts the timing, if state = 0 a high to low transition starts the timing

That clearly states that if no pulse arrives within the timeout period a result of 0 is returned.

Fully agree that part is absolutely clear.

A pulse, when detected within the timeout period, "starts the timing"

Fully agree that part is absolutely clear.

and measures the pulse length

Now that is the part for me was not absolutely clear without assumption or testing.
i.e. Did the timing still stop 0.65 seconds after the command started or does it continue for up to another 0.65 seconds.

All it takes is another sentence in the manual to totally remove ambiguity for all in the future


Maybe the typo can be fixed at the same time:

Information: The pulsin command measures the length of a pulse. If no pulse occurs in the timeout period, . . . .

 

[retepsnikrep]

I agree about PULSIN/PULSOUT being a sleeper command as I am just about to implement it on my BMS project instead of hserin/hserout.

Basically I have 50 Lithium cell slaves (08M at 8mhz) on an opto isolated BUS, each one will now in future output it's cell voltage as a PULSOUT command.
Voltage being a value between 200-450 and used as the length of the Pulse

Pulsout MasterBus, CellV	        ;Ouput Pulse equivalent to CellV x 5us

The Master 28X1 running at 8mhz sits on the bus receiving the pulses via

Pulsin MasterBus,1 ,CellVoltage		;Read data pulse on MasterBus CellVoltage = 5us Pulse x CellVoltage

Very easy and more noise resistant, as I can use harder pull down on the Bus and even some capacitance If I want. I can also multiply the voltages x 10 to get a longer perhaps more accurate Pulse as well if I wanted.

Interestingly at 8mhz with the highest reasonable cell voltage (4.5V = 450) it would take 2.25ms to transmit each pulse. That's quicker and simpler than the serout commands I was using before. I'll be testing this next week on the bench!

 

[Dippy]

Author's who are 'close' to the product often find it tricky to put themselves in the position of Newbie.


Keeping the (unknown to me) technical details aside, this is how I interprate it:-
After starting the command, if the state on the pin changes to the state specified, the clock starts counting.
When the state on the pin changes again, the clock stops.
If the state of the pin doesn't change (even if it is already in the state specified in the Pulsin instruction), the clock won't trigger.
Pulsin waits a maximum of 0.65535 seconds for a trigger (i.e. the 'timeout' period) , then returns with 0 in variable if it hasn't been triggered.

Is that about right?
In fact a small drawing or two would make things clearer and unambiguous.

 

[westaust55]

My interpretation as an extended description:

After starting the PULSIN command, if the state on the pin changes to the state specified, the timer is triggered and starts counting.
When the state on the pin changes again, the timer stops.
If the state of the pin does not change (even if it is already in the state specified in the Pulsin instruction), the timer will not start.
Pulsin waits a maximum of 0.65535 seconds (i.e. the 'timeout' period) for a trigger to start the timer and then returns with 0 in variable if it hasn't been triggered.
Once the timer has started, it will time the duration of the pulse to a maximum of 0.65535 seconds. If the duration of the pulse exceeds 0.65535 seconds the command returns with 0 in variable.​

I agree that authors can be too close and may not provide sufficient clarity. Been there myself in the past when writing a Scope of Work telling the contractor what to do for a project I have designed in detail.
"Erect the 132kV switchyard" would be entirely clear to me but tell others virtually nothing.

 

[hippy]

and measures the pulse length

Now that is the part for me was not absolutely clear without assumption or testing.
i.e. Did the timing still stop 0.65 seconds after the command started or does it continue for up to another 0.65 seconds.

I cannot see how "measure the pulse length" can mean anything other than "measure the pulse length". In the first case where timing stopped prematurely it would not do that, ergo a command which measures the pulse length could not work in that manner, but perhaps I am too close to the issue. I will pass the suggestion for clarification along.

 

[BeanieBots]

It will measure a pulse width of up to 0.65535s providing the pulse start is recieved within 0.65535s.
Otherwise, zero will be returned.

 

[MartinM57]

^^^^^
Yay!

 

[westaust55]

It will measure a pulse width of up to 0.65535s providing the pulse start is recieved within 0.65535s.
Otherwise, zero will be returned.

concur!

 

[Dippy]

Nice precis, except maybe use time units?
And a little table of unit vs Xtal speed.
After all, it is crystal speed related.

A little drawing like Manuf's do for I2C and SPI timing might help.