Add support for procedures

[raintonr]

I am trying to read a DHT22 sensor remotely. Yes, I know it would be trivial to run code on the target Pi to do this, and in fact am doing that right now, but to simplify things I'd like to not run anything but pigpiod on that Pi and have rest of the logic on a central machine.

Using notify I can read the values sent from the sensor, as this notify provides levels and ticks which are accurate enough to decode the payload.

However, in order to trigger the DHT22 sensor one needs to send a pulse on the input GPIO. Ie. one needs to change the mode to output, send a pulse, then change back to input to read the response very quickly.

The trigger function does not work here because it does not change modes and using pigpio-client to change mode, trigger and change mode back is simply too slow.

This is not just limited to pigpio-client, trying to use the pigpiod utility pigs to do this is also too slow.

However, creating a procedure that does these steps and executing that with a single command is fast enough and does work.

Therefore, in order to use this from JS pigpio-client would need support for the commands to create and execute procedures.

[guymcswain]

Funny, I've been playing around with DHT sensors recently myself. For the start pulse, the following seems to work well for me:

// initialize pi as a pigpio-client somewhere

const gpio = pi.gpio(DHT_Data_Pin);
gpio.modeSet('input');
gpio.notify(alert); // the callback that receives (level, tick)

// Start a DHT cycle
gpio.write(0); // N.B. pigpio will safely change mode to OUTPUT when writing
setTimeout(() => {
   gpio.modeSet('input'); // let line go high to begin receiving data bits
}, StartPulseWidth);

This works because the mode change alone is what is needed to return the data bus to the high state. The DHT will not begin driving the bus until it detects a high condition which can only occur after the raspberry gpio has already been in the high impedance state.

[guymcswain]

I should add that the DHT timing of the pulse width is very liberal. I think the spec states that it be 'at least as long as xx milliseconds', or something to that affect. setTimeout is well suited for 'at least as long as' for units of milliseconds.