BCM pin numbering

[gbaman]

Might be an idea given that most other resources use the BOARD or physical pin layout for this one also to use it, for consistency. Had a kid today ask why this resource used BCM while another one didn't.

The other resources using BOARD are https://github.com/raspberrypilearning/morse-code/ https://github.com/raspberrypilearning/parent-detector https://github.com/raspberrypilearning/quick-reaction-game https://github.com/raspberrypilearning/screaming-jellybaby

The resources that use BCM are https://github.com/raspberrypilearning/push-button-stop-motion https://github.com/raspberrypilearning/networking-lessons

[waveform80]

The major reason I stick with BCM layout for anything involving picamera is that control of the camera's LED via GPIO (via the led attribute) only works when the RPi.GPIO library is in BCM mode (GPIO5 isn't mapped in BOARD mode). While most examples don't fiddle with the LED (as it also necessitates root access), I figure people may well take examples and extend them. If they extend them and wind up using the led attribute while in BOARD mode they'll suddenly find their code breaks (or worse!) because the picamera library reconfigures RPi.GPIO for BCM mode upon the first usage of the led attribute.

It sounds like this may change in future though - 6by9 recently announced some new firmware features for controlling a "privacy indicator" and apparently that can be configured to mean the LED. From what I understand, this new method wouldn't necessitate direct GPIO access which would mean I could ditch the dependency on RPi.GPIO and the requirement for root to control the LED.

[gbaman]

My worry though is it will confuse people. Personally I didn't even know you could control the LED on the Picam other than via the config.txt value (or tape). Have learnt something today. Today it confused a kid, so perhaps it might be an idea, for the Raspberry Pi official documentation to stick to one standard?

[gbaman]

Pull request created https://github.com/raspberrypilearning/push-button-stop-motion/pull/6

[LizUpton]

I'll leave the final choice on this one to @clivebeale, @MissPhilbin and @bennuttall, but FWIW, I'm very strongly in favour of @gbaman's approach here.

[MissPhilbin]

Personally I'm in favour of using BCM numbering (see Adventures in Raspberry Pi Chapter 8). From my own experience, BOARD numbering doesn't always work when you start to do more advanced things.

However this is a discussion that has been ongoing in the education team. It's very similar to the 'should we use python 2 or python 3' discussion. I don't think it is as simple as picking one and sticking to it at this time.

[waveform80]

Good idea to stick to one standard, but in that case I'd plump for BCM:

It may be more confusing than BOARD (given the non-sequential numbering) but I feel that's a minor hurdle, and teaches something useful when learning it (that the pin numbering has little to do with the header, and more to do with the chip serving it).

It's also "unrestricted", at least in the RPi.GPIO library, in that when in BCM mode the library simply checks the requested pin is within the bounds of the chip and passes the request along. In BOARD mode, a mapping is used to determine the "real" pin to operate on; if the mapping for a pin (like GPIO5) is missing, the library refuses the request. For example, the library needed updating to support the B+ in BOARD mode, but "just worked" in BCM mode. Then there's the aforementioned case that control the camera's LED simply isn't possible in BOARD mode (there was one case in a picamera workshop when a particularly enthusiastic and talented student hacked the example script we were doing to blink the LED during the delay before taking a picture!).

Finally, BOARD numbering doesn't apply on the compute module. Okay, that's also a pretty niche appliance especially as far as educational materials are concerned - but to me it all boils down to: BCM numbering may be a bit confusing but everything supports it because it's the "real" numbering. BOARD numbering is simpler, but is a rather artificial concoction of various libraries. The second one steps out of their comfy confines one finds it doesn't exist anymore. I suppose there's an argument that when someone's ready to ditch the library they're ready to confront the non-sequential BCM numbering, but personally I don't think non-sequential numbering is that hard to wrap one's head around.

Anyway, that's my 2 (or possibly 3) cents!

[LizUpton]

I think we (i.e. whole edu team and...hangers on - which is to say me ;) ) should sit down together and thrash it out properly; it could be that we decide there are projects in which BCM numbering does make more sense. I'm still iffy about BCM pin numbers particularly when the projects are aimed at beginners; from my perspective it's about removing barriers to getting started. I'm much less bothered when the projects are aimed at learners with a bit more experience.

[asb]

The worst thing about this decision is how binary it is - one or the other. Thankfully there's something that allows the debate to be extended even further: wiringPi introduces a third numbering scheme! http://wiringpi.com/pins/

[gbaman]

I guess the question is who are these guides aimed at? My assumption was complete beginners, and hitting them with BCM layout I personally think is a hurdle.

The other board out there, Arduino has a similar issue given that the numbered pins don't actually line up with the chip numbered pins, but they decided to go for physical layout in everything full stop and it worked. Although Pi is not completely comparable, it is partially.

When is a kid really going to need to access the builtin status LEDs or the camera LED? If they are at that stage, then you can teach them about BCM, but I don't see a need before that stage as a majority won't ever (I have yet to need either).

More though what I am after is consistency, the knowledge that if I point a kid at the Pi foundation resources, they will all use x or y, not mix and match like happened today. That way I only need to teach 1 standard and not confuse them with 2. And it does confuse kids, especially younger kids. This kid couldn't initially understand why one wouldn't use BOARD layout (he eventually got it)

As for wiring pi.. Just please no...

Second pull request done https://github.com/raspberrypilearning/networking-lessons/pull/6

[LizUpton]

We'll hold off on merging until we've had a chance to talk tomorrow (@bennuttall doesn't get a look-in because we won't see him for a few weeks) - but thanks very much for the request.

[waveform80]

@asb Bah ;) I think we can bring this back to a binary choice (I have enough of ternary logic in my day job!) by use of the following table:

Scheme	Consistent with header	Restricted functionality
BOARD	yes	yes
BCM	no	no
wiringPi	no	yes

But back to the debate on BCM vs BOARD: in answer to @gbaman's request for an example of a kid accessing the camera LED I return to my anecdote of a student in a picamera workshop implementing a blinking LED during the delay before capture. This was in the "selfies!" portion of the picamera worksheet - his point'n'shoot camera blinked an LED when in time-delay mode, so he wanted the Pi to do the same thing (and with a little tweaking of the script he managed it very quickly!). But I'll freely admit that's the only example I can come up with!

However, one other concern about BOARD mode (actually it's more about a deficiency in the RPi.GPIO library) is as follows (and I'll preface this by admitting it's an unlikely scenario, but nonetheless possible):

As mentioned above, in the picamera library when the led property is first accessed, I switch the RPi.GPIO library into BCM mode (because that's the only mode that the LED can be controlled from). I don't check whether the library was in BCM or BOARD mode before, because I can't: unfortunately RPi.GPIO provides no means of querying the current mode (I'd much rather just raise an exception if the library was in BOARD mode rather than force it to BCM).

This leads to a potentially nasty scenario: it's possible for the user to have rigged up stuff to the GPIOs in such a way that under their preferred BOARD numbering everything works happily, but under BCM numbering stuff gets physically damaged (given that certain indexes exist in both schemes but refer to different pins with different characteristics). The user has placed RPi.GPIO in BOARD mode but now tries to fiddle with the camera's LED via picamera. Without any kind of warning (other than the big orange box in the docs ;), the library gets switched into BCM mode, their code then goes to twiddle a few pin states but (through no fault of its own) winds up twiddling the wrong ones, and suddenly the magic smoke appears.

Again though, I'll admit this could be rectified quite easily: I really should get off my keister and file a bug report in RPi.GPIO to make the library mode readable (I meant to make a PR for it ages ago but it's yet another thing I've never found time for!)

[clivebeale]

Just repeating what's been said, but it's something that we need to sit down and talk about. There are profound pedagogical issues here (sorry for being so ... profound :)) My gut feeling is that it will be an easy call after a good old chat.

Personally I don't care how the pins are referenced as long as a) it provides the lowest barrier to learning and b) is consistent. I'd name them after cartoon characters if this was the best thing from a learning POV :) One confounding factor at the moment is Scratch GPIO.

[bennuttall]

[gbaman]

Any decision on this?

[bennuttall]

I'm still in America?. We'll discuss it when all the edu team are together in a couple of weeks.

P.S. BCM

[gbaman]

Another big reason against BCM is they moved between Pi revisions.. This may make diagrams compared to code wrong. In total 3 pins changed BCM name between B revision 1 and B revision 2. A lot of people (myself included) still have old revision 1s. I especially use mine for GPIO work as I have less of an issue if I blow it up.

Therefor is not consistent and is just confusing to try and explain to a kid why.

Physical layout of course stays the same. This in itself should be enough as if BCM is used, I foresee it causing more confusion. Remember, we are aiming these resources at kids and counting up just makes sense vs completely randomly laid out pins that you always need to check a diagram for. If it was written on the silkscreen perhaps, but it isn't so they need a diagram every single time and code won't just work on every Pi given the pin changes.

[LizUpton]

I do see where you're coming from, Andrew, but (like we said last week) the decision's been made: BCM won. Sorry!