PULSOUT versus HIGH-PAUSE-LOW ?

BrianZ

If I want to program a pin on the BS2 to send out a signal for some period within the range of 10 to 100 milliseconds, does it make any difference whether I use the PULSOUT command versus the sequence of HIGH, PAUSE, LOW commands? I'm guessing it depends on the duration and level of precision you need in terms of being accurate to within a few microseconds versus milliseconds, and if I only need to be within a millisecond or two, then a PAUSE will do. But if I want greater reproducibility for the desired duration, then I should use PULSOUT, is that correct? Or is there something else to consider besides the fact that PULSOUT has a significantly more limited range? Thanks.

Mike Green

The pulse width timing using the PULSOUT statement is much more accurate than using HIGH / PAUSE / LOW. There's an unspecified overhead involved in each statement on the order of hundreds of microseconds that can vary depending on the type and complexity of the statement parameters (like pin number and PAUSE delay). All of that is absorbed into the overhead of a single statement in the case of PULSOUT and doesn't affect the pulse width.

One other small point ... PULSOUT reverses the state of the specified I/O pin. You'd have to use TOGGLE / PAUSE / TOGGLE to do the equivalent.

Along with lots of other useful information on the Stamps, EmeSystem's website has tables of execution times for many of the complex PBasic operations like PULSOUT. Use the App-Notes link.

Martin_H

PULSOUT is a PBASIC built in command and executes quickly and repeatably. Manually changing pin state is called bit banging and because PBASIC is interpreted it is much slower than built in commands. For example you can bit bang SHIFTOUT by changing a clock pin and data pin, but at much lower data rates.

Update Mike Green is just a bit faster once again.

BrianZ

Thank you, guys. The table of command execution times was interesting. What I gleaned from that page was that the High/Low commands each require 140 microseconds to start executing, while the Pause command needs 235 microseconds. Therefore, if one uses the commands High-Pause-Low, the voltage would be high for a total of the pause time plus its execution time of 235 microseconds, plus the time to execute the Low command, for a total of 375 microseconds or 0.375ms longer than the stated pause time.

I have written a program to turn on/off a solenoid valve twice, such that it will release two drops of water from a nozzle. A typical time that the valve needs to be open to release one drop might be, say, 40 milliseconds. So, if I use the High-Pause-Low commands using "Pause 40", then I figure I should expect the valve to be open for a total of 40.375 ms. Or if I use a smaller nozzle with a typical open time of 20ms, then it would be open for 20.375ms, or a larger nozzle might be open for 60.375ms instead of 60ms. Whereas, if I used the Pulsout command, then despite taking 230ms to read its variable and execute the command, once it started, it would keep the valve open for much closer to the exact time specified, correct?

While the Pulsout command seems to be more accurate, I'm not sure whether it would have any practical advantage to me in this situation, since a drop with a target value of 40ms for the valve open time may have an acceptable range of 30 to 50ms where it forms a perfectly suitable drop. So, if I'm dealing with an acceptable range of, say, plus or minus 10ms, then it wouldn't really matter if I was using 40.375ms instead of 40ms, would it? I think the more important question is how precise (ie, repeatable) is the result. If it's still within hundreds of microseconds, then that is fine with me, so no need to use the Pulsout command. And in order for that table of delays for the various commands to be published and have any reliability, then those times would have to be reproducible to within a much smaller range than their values, or else they would be rather meaningless. This tells me that, although the commands have a timing cost which can add up, particularly for something like a timing loop, that cost may be insignificant for a couple of commands, depending on what you need to accomplish. Would you agree, or do you think I really need to use Pulsout? Frankly, I would be happy if a target values within the range of 10 to 100ms for the pulse duration were anywhere within 5%, which appears to be the case. Or do you think that using High-Pause 40-Low commands would somehow vary wildly and not be within, say, 39 to 41ms? Moreover, wouldn't the error tend to be small and in a consistent direction rather than a lack of precision?

Probably more critical is the time delay between the two drops, and it is a bit longer, more like about 60ms. And consistency is much more important than the actual time achieved, since the target value can be adjusted, but I want to get the same interval between all pairs of drops. Well, this is interesting, because, I went back to my program and added up the command execution times within my subroutine for opening the valve and for the Gosub and For/Next commands, etc, and it appears that even just those few simple commands added up to 2.63ms (2632us). So, my time delay between drops for a 60ms pause setting is actually more like 63ms. Interesting, but still, reproducibility is what matters most to me, because I can adjust the delay setting one way or the other, as long as I'm not bouncing around with significantly different results each time.

erco

To be certain, you'd need to examine the output pulses on a scope. Instead of using the relatively slow pause command (millisecond timing), you could do a short dummy pulsout (microsecond timing) to an unused pin, such as

high 0:pulsout 1,3:low 0 ( or toggle 0:pulsout 1,3:toggle 0 ) to achieve a shorter simulated "pulsout" on pin 0, pin 1 used as a dummy pulsout here

BrianZ

Good idea to use that sandwich technique, but I don't have an O-scope.
Since I am using a pause command between the drops, I'm not sure how pulsout could even be used or how it would improve either accuracy or precision of this delay time, since pause command takes 140us while pulsout takes 230us to execute. And the precision of that delay time is more important for my purposes than its accuracy.
For now, I think I will keep my low-pause-high commands and see if my results are consistent, and if so, then I won't bother with rewriting my program to use pulsout with its conversion factor. At best, I could improve on the accuracy of my drop size, which isn't very critical, but I still doubt whether pulsout could offer anything better for creating the delay between drops.