Phil Coval
Phil Coval
IIRC unexport expects a pin number, while close knows its number (as created by open "constructor") my 0.02EUR
if close works same as unexport I dont see the point of adding it, in my mind I wished something like: ``` var port = gpio.open( ...); port.write(true, ...); port.close();...
BTW: gpio.close(PIN_NUM) can close a pin that wasnt open ... so I prefer to think OOP here and remove param, while unexport(num) can be used as static method.
This would be aligned to: https://github.com/Samsung/iotjs/blob/master/docs/api/IoT.js-API-GPIO.md ``` gpio.open( {pin: number ...} , function(err, gpiopin) { //... gpiopin.close(function(err) {...}) }); ``` and deprecate current: ``` gpio.unexport(number). ```
eventually then also add readSync and writeSync
I guess this is specific to hardware, for instance on RPi, you'll have to use http://wiringpi.com 's gpio command: gpio -g mode 11 down But there are other alternate gpio...
This could be added as a "plugin" feature, as we don't want to break generic support Relate to: https://github.com/EnotionZ/GpiO/issues/30
Maybe you'll be interested in: https://github.com/EnotionZ/GpiO/issues/42
For design concern, I would suggest to load mapping from a separate file matching the platform you are using. to keep genericity in gpio.js.
Is there any interest to upstream this for next release ?