EnotionZ / gpio

Talk to your Single Board Computer's gpio pins
MIT License
393 stars 57 forks source link

gpio.open should accept array of pin options #56

Open EnotionZ opened 5 years ago

EnotionZ commented 5 years ago

gpio.open should support an array of config objects in order to export multiple ports and have an elegant callback that ensures all those ports are available to use.

Contract should look something like...

gpio.open([
  { pin: 4, direction: gpio.DIRECTION.IN },
  { pin: 17, direction: gpio.DIRECTION.OUT }
], function(err, gpioPins) {
  if(err) return console.log(err);

  var gpioPin4 = gpioPins[0];
  var gpioPin17 = gpioPins[1];
});
rzr commented 5 years ago

what open is supposed to return here ? an array of gpio instance (to be closed using close() ) ?

EnotionZ commented 5 years ago

If it adheres to the current contract, then it should return the same variable as gpioPins (array of GPIOPin instances). If we want to be future proof, then it should return a promise (I'm leaning towards this).

I know the current API returns the created instance, but that original contract was created a long time ago without a lot of thought put in. export (and now open) is an async function call, there's no point in returning something that you can't use immediately. For example, this will never work...

var pin = gpio.open(...);
pin.set(); // throws error since open isn't done

We should advocate for all gpio operations to run inside the callback.

That's why I was checking the node version on your board. I think we should make the minimum engine be something like v4.0.0 and support promises now. I just booted up my original raspberry pi (used when I created this library) which has v0.6. It's completely unusable now bc it didn't meet npm min version requirement (therefore unable to perform npm install).