The whole point of RPi::WiringPi is to consolidate a whole bunch of other C and Perl (the only lib that isn't mine that I'm wrapping/including is wiringPi C library itself), with the goal to ensure all sub-objects have the same, consistent interface (where humanly possible at least).

I mean it's not bad, but I just know there's room for improvement. I'm not changing anything else (except for brokenness/bugs) until I'm done writing all of the tests for the suite I have in mind, as that'll allow me to get a better understanding and feel for any changes that may be made later.

The good thing is that I have very sane defaults in most cases, and currently, the API will be able to be finagled without breaking the way it currently works :)

I think it's not unreasonable in embedded systems to write a proof of concept code to help to understand what the datasheet is trying to tell you knowing full well that you'll probably have to junk it when you expand to the production app.

James

There's never enough time to do it right, but always enough time to do it over...