On Sun, 17 Nov 2019 20:58:08 +0100, "R.Wieser" declaimed the following:
There are NO internal tables... And no global conversion routine. Tables and conversion are specific to the GPIO library one is using.
And... if you intend your code to be used by others (via import and calling functions) you are going to have to document which library you are using, and for those where it matters, which pin naming structure you expect them to be using.
Again -- gpiozero SIMPLIFIES a lot of this... It accepts multiple naming styles without locking the user into a single style. It accepts multiple back-ends (RPi.GPIO, pigpio...). Set up your module on the basis that the end-user should initialize gpiozero with their preferred back-end, and everything else should be transparent. Any pins that are to be controlled both within your module and by the end-user SHOULD be something they provide to your module as an initialization. Any pins your module dedicates should be documented so the end-user doesn't attempt to use them.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Please re-read my definition of 'internal'. That you have your own (which you have not mentioned yet) should not be the basis of an argument.
That I never even suggested.
True. Sow, how about that GPIO library exposing what it uses ? So that I/we can convert from one of its pinnaming schemes to its other one(s) ?
No. I expect my code, if possible, to adapt to whatever the user wishes to use, not the other way around.
[snip]
Actually, this is the fricking *first time* anyone has tried to tell me WHY I should be using gpiozero over a RPi.GPIO, without just appearing to order me to do so.
I'll most likely take a look at it. ... after I've finished with what I'm currently busy with.
Sounds good. And thats all that I tried to do (for my class module using RPi.GPIO) too.
Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/gpiozero/pins/data.py", line 1158, in physical_pin raise PinMultiplePins('multiple pins can be used for %s' % function) gpiozero.exc.PinMultiplePins: multiple pins can be used for 5V
Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/gpiozero/pins/data.py", line 1158, in physical_pin raise PinMultiplePins('multiple pins can be used for %s' % function) gpiozero.exc.PinMultiplePins: multiple pins can be used for 3V3
I have been talking about the RPi.GPIO module only ... As mentioned, I will take a look at other possibilities /after/ I've finished with the current one.
(And yes, I understood that you wanted to show me that the gpiozero module can do what I was asking for. Don't worry about that)
That might mean that gpizero is part of the NOOBS 3.2.0 package, as its a valid command on my Pi, returning what you've shown - including the ASCII art.
By the way, I've been adding functions to what is present in the RPi.GPIO-0.7.0.tar.gz file. Currently just a 'setupBCM' and 'outputBCM', but when I figure out how the CPython code behaves (there is ofcourse lots of code overlap between the origional "xxxx", "xxxBCM" and "xxxBOARD" functions, and I'd like fold them together) I will probably add the others too.
Yeah, I know that that will cause my Python scripts using those new methods not te be sharable with others anymore (for the duration of this experiment). Thats just not to be helped. :-)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.