BCM pinout calculation

[Tungsteno74]

Hello,
please can explain how you calculate BCM pinout mapping? I'm searching for it on the web all the day but found nothing about the link of physical with BCM pins.
(i'm trying to add pin mapping for NanoPi Neo board)

Thanks

[rm-hull]

@sgjava might be a good point of contact here as he did some pin mapping’s for the NanoPi duo.

[Tungsteno74]

@rm-hull thanks Richard. I found another person that can help here.
@5kft
How do you associate BCM pins in neocore2?
I'm not able to find a relationship between pins mapping and the table below... please can help me?

[5kft]

Hi @Tungsteno74, I can't speak to what WiringPi is doing as I've never tried using it, but the "BCM" pins are defined by Broadcom SoC GPIO channels exposed by the Raspberry Pi - e.g., see https://raspberrypi.stackexchange.com/questions/12966/what-is-the-difference-between-board-and-bcm-for-gpio-pin-numbering.

For the NEO Core2, take for example "BCM GPIO" 9, which is physical pin 21 on the board (also the SPI0_MISO line, which is the same for the Raspberry Pi) - e.g., see http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO_Core2#Layout. You can see that this is GPIOC1 or physical GPIO 65, using the standard Allwinner GPIO line calculation (noted in my changes). So, in the mapping table if you look up BCM pin 9 or BOARD pin 21 you'll see these map to Allwinner GPIO 65.

I hope this helps!

[Tungsteno74]

@5kft Thanks for your reply.
Thus, let me understand better, the association between BCM GPIO 9 and GPIOC1 is determined by other pin functions? (as you mentioned both have SPI0_MISO function too).
Did I get it right?

[5kft]

@Tungsteno74 - actually no, the association is the physical wiring of the pin for the board that you are using. The "BCM" designation is really just a reference or a label when you are using other boards (e.g., NanoPi NEO), but it should end up working correctly if you create the correct mapping in whatever GPIO library that you are using.

In order to create the mapping you have to associate the "BCM GPIO" value to the physical GPIO line for your board. You can do this using the schematics for the board that you are using. For example for the NanoPi NEO it looks like you could use this schematic: http://wiki.friendlyarm.com/wiki/images/e/ec/NanoPi-NEO-V1.31-1703-Schematic.pdf, found from FE's wiki for the board here: http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO - in this case you can find the GPIO connector pinout for the NEO on page 10 of the schematic (see connector "CON1").

[deece]

Is the BCM mapping intended to be a mapping to the pin on the chip, or the Linux GPIO number?

I'm asking as we want to fix up the BCM mapping on the Orange Pi PC (which is just a copy of the board array atm).

If it's a mapping to the pin on the chip, a RAW mapping with the linux GPIO numbers, as well as port/pin (eg. PA8) would be useful.

[5kft]

@deece - as noted earlier in this thread, the "BCM" pins are defined by Broadcom SoC GPIO channels exposed by the Raspberry Pi, so it's kind of an arbitrary standard (e.g., see https://raspberrypi.stackexchange.com/questions/12966/what-is-the-difference-between-board-and-bcm-for-gpio-pin-numbering).

[deece]

I'm digging through the Allwinner reference manual (http://linux-sunxi.org/images/a/a3/Allwinner_H5_Manual_v1.0.pdf) and it looks like Allwinner don't have the concept of a number for a GPIO line, just the standard ARM Port/Pin names (eg. PA10).

What use do you see for the BCM mappings in the Orange Pi world, and how have you determined them for ZeroPlus & friends? At best, I think the BCM naming of that dictionary is poorly named, and should reflect the origin of the mapping.

[later] The Pi Prime schematics (http://linux-sunxi.org/images/a/ae/ORANGEPI-Prime_V1_0.pdf) make reference to IO-0, IO-1, etc, but these are named by Xunlong, not Allwinner, and definitely not Broadcom. They also have no allocations for multiplexed ports (eg, I2C0-SCL is PA11, but there is no IO-x allocated to it).

As an aside, I can see a use for a generic 'RAW' mapping which uses the GPIO numbers that LInux uses (effectively a NULL mapping), as well as additional keys mapping the ARM Port/Pin.

[5kft]

Your "use" question is a good one...I've always looked at it as providing some level of portability. A BCM GPIO will map to the same physical pin across different SBCs (assuming there is a correct mapping implementation, of course).

As far as determining the mappings, I describe this in a comment above - it's pretty straightforward (e.g., see #27 (comment) for an example).

[deece]

I see, so you are labelling the pin in the header with the BCM assignments that were used on (some variant of) a raspberry pi, and then mapping that back to the corresponding pin on the Orange Pi?

If so, I'm not sure that makes sense, as those assignments vary between raspberry pi models.

The Board mapping should be used for portability, as that refers to the pin offset within the header.

[deece]

At the very least, the BCM dicts put forward for the Orange Pi PC & friends, which is just a copy of the board dict, is a red herring, and should probably be removed.

[5kft]

I haven't looked in a while, but I believe that all the "newer" Pi models use the same BCM GPIO "assignments" (not sure the Model A and first B version matter much in this regard). In any case, please understand that this isn't my project at all, I just implemented some additional mappings for a couple of boards that I am using :-) I would imagine that you could contribute to this project as well. (Side note: personally I also don't use these BCM mappings at all, nor do I see much use for them in a non-Raspberry context - I use the pin values as they relate exactly to the specific SBC schematic.)

[deece]

I'm just trying to get my head around the mappings :)

It looks like the SUNXI mapping is a good choice for me, since it uses the PA12 notation

[5kft]

Yes, it is kind of strange/confusing :-) Also, IMHO it is really worth checking out libgpiod https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/. I've had great success using it in several applications on H5-based SBCs using both the native library as well as the Python bindings (interfacing to custom H/W).

[deece]

@mikalstill & I are looking at this ATM as we're adding support for the Orange Pi Prime to Home Assistant, and the other Opi library used /dev/mem (which is a gaping security hole!).

The Linux docs say the sysfs interface is deprecated though, so we'll be looking at using the char dev interface in the future.

[ygoe]

Alright, after trying to understand the comments here, I assume that there is no mapping available and thus nobody knows what numbers to use for a certain pin on a board. The only system that is known is the BCM scheme for RPi.GPIO on a Raspberry Pi, anything else is "try them all and guess". Or have I missed the mapping tables somewhere here?

I'm interested in the Orange Pi Zero, but maybe also the NanoPi NEO. I'd wish for a set of tables, one for each board model, that explains which physical pin needs which number in this API. That's all I need.

I started to code something on a Raspberry Pi today but that needed to go elsewhere so I'm here with my Orange Pi and can't get it to do anything GPIO in Python.