Open tjanson opened 10 years ago
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.
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 either0
or1
(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 forread
.
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. :)
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.
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.
I’ve cleaned everything up and opened a PR #27, please have a look. :)
Ah cool. Sorry for the delay. I'll review the PR soon.
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,
export
ing 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.:
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,
fs
calls; it provides the usual functions (read
,write
,export
, etc.), and parses queries likegpio readall
to JSON. I’d like it to mirror the original tool exactly.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.