Replacing quick2wire’s gpio-admin with Wiring Pi’s gpio utility

[tjanson]

Hi,

I’ve been using pi-gpio for a while (in the form of Heimcontrol), so first off thank you for your work.

There’s been only one issue: As described in #24, exporting pins is finicky and complicates things – which is a shame, because simplicity is really what I like about pi-gpio.

My vision of pi-gpio: A simple, beginner-friendly library providing basic read/write functions that can be used without worrying about exports at all, e.g.:

var gpio = require('pi-gpio');
gpio.write(15, 1); // auto-exported as output
console.log(gpio.read(11)); // auto-exported as input
console.log(gpio.read(15)); // auto-switch to input

The problem really lies in the underlying tool: quick2wire’s gpio-admin, which as far as I can tell has in practice been superseeded by Wiring Pi’s gpio utility. In order to make the switch,

• I’ve written a wrapper for Wiring Pi’s gpio util. It’s just one level over fs calls; it provides the usual functions (read, write, export, etc.), and parses queries like gpio readall to JSON. I’d like it to mirror the original tool exactly.
• I’ve rewritten pi-gpio to use that wrapper. This would wrap the wrapper, I suppose, with convenience functions: auto-export, pin scheme conversion, input sanitization, and so on.

I understand that you may want something very different from pi-gpio. That’s why I’m asking for your feedback!
As it stands, it’s a pretty massive change, with an entirely incompatible API, but I’d be willing to make it backwards-compatible, or modify it in any other way, if desired.

[rakeshpai]

Thanks, @tjanson! This is entirely in sync with what I've wanted to do. It's awesome that you coded it up! :)

How do you want to proceed? How hard do you think it will be to support backwards compatibility? Would you say it's worth sacrificing backwards compatibility (if, say, we do that with a significant version bump)?

I'm also open to hand over control over this repo to you, if you could help with on-going maintenance.

[tjanson]

How hard do you think it will be to support backwards compatibility? Would you say it's worth sacrificing backwards compatibility (if, say, we do that with a significant version bump)?

Not hard at all. Keeping in line with the old API, read/write could be extended as follows:

.read(pinNumber, [callback [, exportMode = 'auto']])

Reads the current value of the pin. Most useful if the pin is in the input direction.

• pinNumber: As usual.
• callback: Will receive a possible error object as the first argument, and the value of the pin as the second argument. The value will be either 0 or 1 (numeric).
• exportMode:
  • 'auto' (new default): Export pin before reading, unless it was previously exported.
  • 'force': Export pin before reading.
  • 'off' (old behaviour): Do not export pin, just read – even if we think it’s not ready for read.

Everything else could stay the same. Some methods would be rather pointless (e.g., export absorbs setDirection’s functionality), but we could point that out with a deprecation note.

I'm also open to hand over control over this repo to you, if you could help with on-going maintenance.

Thanks – I’d like that, I’m willing to put some effort into maintaining it. :)

[rakeshpai]

Sorry for the late reply. I've added you as a collaborator on this repo. Please let me know when you're ready, and I could test and push to npm.

[tjanson]

I’ve pushed to branch gpioutil-switch; it’s not quite finished yet, but ready to be tested.

Apart from adding tests for the auto-export functionality, I’m thinking about rewriting read and write to use bindings to the native Wiring Pi library (rather than the slow exec call of the gpio utility). That would speed up read/writes extremely. I think I’ll open an issue to discuss it.

[tjanson]

I’ve cleaned everything up and opened a PR #27, please have a look. :)

[rakeshpai]

Ah cool. Sorry for the delay. I'll review the PR soon.