I'm trying to put some GPIO pin related code into a class object, when I realized that when I, while initializing the object, use
import RPi.GPIO as GPIO GPIO.setmode(GPIO.BCM)
I could be overriding a previously set mode, or my setting could be overruled by a later on in the code. Which would mean that either my object or some other code would be referencing the wrong GPIO pins. :-(
I already tried
import RPi.GPIO as GPIO1 GPIO1.setmode(GPIO1.BCM) import RPi.GPIO as GPIO2 GPIO2.setmode(GPIO2.BOARD)
, but that threw an error on the second ".setmode()"
So my question is: Can I use two different pinnumbering schemes at the same time ? And if so, how ?
Maybe by instanciating RPi.GPIO as an object (making all settings local to it) ?
On Fri, 15 Nov 2019 20:49:08 +0100, "R.Wieser" declaimed the following:
GPIO1 and GPIO2 are "local" names both bound to the same, single RPi.GPIO module. The second import will find that RPi.GPIO has already been imported and will use that copy. The above code is equivalent to
import RPi.GPIO #loads the module, creates local name RPi.GPIO GPIO1 = RPi.GPIO GPIO2 = RPi.GPIO #create two local names bound to the module del RPi.GPIO #remove RPi.GPIO from local names -- module is #still bound to other names, so is not garbage #collected.
{Yes, the discussion on how Python name-binding differs from common language assignment has spread here}
What documentation I can find does not state if .setmode() is one-time-only call; only states that one must call it before using any pins. Unfortunately, this is one case where read the package source is not readily viable. The Python RPi.GPIO imports a binary _GPIO library to implement the actual operations.
Downloading the source code from SourceForge one finds: """ // python function setmode(mode) static PyObject *py_setmode(PyObject *self, PyObject *args) { int new_mode;
if (!PyArg_ParseTuple(args, "i", &new_mode)) return NULL;
if (gpio_mode != MODE_UNKNOWN && new_mode != gpio_mode) { PyErr_SetString(PyExc_ValueError, "A different mode has already been set!"); return NULL; } """ Which confirms that setmode is a one-time operation, and can not be changed later.
My suggestion... Don't use RPi.GPIO directly. GPIOzero seems to be the current package pushed by the R-Pi Foundation. It wraps over various of the GPIO libraries available.
formatting link
formatting link
"""
2.2. Pin Numbering
This library uses Broadcom (BCM) pin numbering for the GPIO pins, as opposed to physical (BOARD) numbering. Unlike in the RPi.GPIO library, this is not configurable. However, translation from other schemes can be used by providing prefixes to pin numbers (see below). """ """ If you wish to use physical (BOARD) numbering you can specify the pin number as ?BOARD11?. If you are familiar with the wiringPi pin numbers (another physical layout) you could use ?WPI0? instead. Finally, you can specify pins as ?header:number?, e.g. ?J8:11? meaning physical pin 11 on header J8 (the GPIO header on modern Pis). Hence, the following lines are all equivalent: """
formatting link
""" GPIO Zero was originally just a layer on top of RPi.GPIO, but we later added support for various other underlying pin libraries. RPi.GPIO is currently the default pin library used. Read more about this in Changing the pin factory. """
It is recommended that you do not mix "pin factories" in the application, but you can control if RPi.GPIO, pigpio, or RPIO is used.
You likely won't have as many places where you need to specify the pin. Instead of RPi.GPIO's functions that all need pin numbers (as in)
gpio.setup(pin, gpio.OUT) gpio.output(pin, gpio.HIGH) gpio.output(pin, not gpio.input(pin)) #toggle pin state (where pin depends on what setmode had been used -- and the above uses pin FOUR time)
GPIOzero would use
myOutput = gpiozero.LED(pin) myOutput.on() myOutput.toggle() (where pin could be xx, "BCMxx", "GPIOxx", "BOARDyy", "J8:yy" for xx being the BCM number, yy being the BOARD number -- and pin is only used ONCE)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Yep, I came to the same conclusion. Its just one of those obvious things I felt I had to try before posting my problem here (and used it to indicate that I did try to solve it myself first).
That feels like a bit of a ham-fisted approach to me. :-\
:-) If its just /me/ I need to think about I could simply choose to use a single pin-numbering scheme throut all my programs. Problem solved.
The thing is that I tend to go for a broad-as-possible usability. In this case that means that I would like to be able to use the class as a drop-in (by import or simple copy-pasting) in other peoples code (no, don't wake me yet mum...), which could also be doing GPIO.
Shucks. No .outputBCM() and .outputBOARD or BCM.ON/OFF and BOARD.ON/OFF constants or an even a non-required pin-scheme override argument in the .output() command itself ?
Asking for a method that will do a pinnumber translation (using its internal tables) is probably too much to ask for too ?
So many possibilities, so many lost chances ...
Oh well.
It will probably mean I'll just write two classes for it - and try to get it to auto-select the correct one.
Just make one yourself, if you really need it. I suspect you don't really need it, though; all your problems seem to stem from inflexibility and bad research. First command probably not necessary, second gives a handy overview of BCM/WiringPi/physical pin numbers and their modes and values.
I've been told that saving the same data at multiple places is bad. /Especially/ when you do not control all of those places (read: stuff can get outof sync).
Also, I should do that for /all/ current boards as well as future ones ? Yes, I also take that into consideration. You don't ?
Ah yes, my wish to see if I missed something in what I'm trying to do or if what I already got could be used to solve a problem instead of just thowing whatever "lets use something totally different" is nearest at it (dumping evermore software into the Pi in the process) must stem from "inflexibility". Sure.
I think I'm going to carry that classification as a batch-of-honor. :-)
Yep, thats where I eyeball my pinnumbers from. I consider it easier to use than the images you can find all over the 'web.
Regards, Rudy Wieser
P.s. Did you this morning step outof bed with the wrong foot first ?
But the problem (to me) was not how to get a list ("gpio readall" returns the in-use one), but make sure that whatever I would be using would match whatever was in use (by RPi.GPIO) on the Pi the code would be used on.
To me the best way to do that is to ask the software I'm already using for its list - even when there would be a translation mistake somewhere calling that method instead of doing it with a seperate list would mean the pin-translation output would stay in sync.
By the way, I downloaded RPi.GPIO-0.7.0.tar.gz , which showed me that the whole pinnumber translation is just a thin layer, with technically nothing stopping anyone from using BCM and BOARD pinnaming/numbering at the same time.
On Sat, 16 Nov 2019 22:13:11 -0500, Dennis Lee Bieber declaimed the following:
Oh -- my purpose in pointing that out...
There are NO "internal tables". The only "internal" scheme is the Broadcom numbering system. EVERY GPIO library that allows for alternate numbering schemes has to implement the translation -- which requires identifying which board it is running on, using that information to select the subset of its own table that applies, and only then being able to convert to Broadcom numbers (I don't recall seeing any that do the reverse translation -- given a Broadcom number, return the representation of the alternate naming).
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
On Sun, 17 Nov 2019 12:16:22 +0100, Tony van der Hoff declaimed the following:
gpiozero:
1 allows use of alternate pin naming schemes without being locked into one mode
2 allows use of alternate low-level GPIO libraries (default is still RPi.GPIO, but if one sets it to use pigpio then one has the ability to have kernel/DMA based PWM rather than fully software based)
3 includes a module for a wide set of SPI-based MCPxxxx ADC chips, along with classes specific to servos, motors, etc.
4 has a 240 page manual -- RPi.GPIO has a short set of example usage.
5 Class-based (RPi.GPIO is just bare functions except for the PWM) -- one specifies the pin only when instantiating a class, and from then one uses methods of the instance; reduced risk of mistyping a pin number.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
The "internal tables" I was trying to refer to are the ones (I "guessed" to be present) in the RPi.GPIO extension. And they are: The "pin_to_gpio_rev?" ones, used by the "get_gpio_number()" function in "common.c" in RPi.GPIO-0.7.0.tar.gz .
Currently I cannot reach those tables (from within Python), even though they are there. And in my book that makes them 'internal'.
Correct. And now the only thing I need to do is to convert the pinnumbers I preset in my class object into the ones that are valid for whatever numbering scheme the user has chosen.
I do NOT want to do that with some "it works on my Pi, I don't care about the other boards or tomorrow" whipped up table. Hence my wish to have acces to those "internal tables" - or better yet, the conversion routine itself
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.