Make GPIO pins configurable

[waveform80]

Per discussion with Ben and James, GPIO pins for camera LED on the compute module are potentially variable. Thus they need to be configurable in the PiCamera initializer.

[6by9]

Unless you have some other magic GPIOs, I thought the camera LED pin was assigned in the pins config for the GPU.

[waveform80]

I can't say I know anything about this (not having ever played with a compute module), but Ben Nuttall very kindly put me in touch with James Adams who had the following to say on the subject:

Hey James

Just talking to Dave (CC'd - author of Python picamera library) and he pointed out that the LED on the camera module is designated as GPIO pin #5 on Pi 1 Model B, then pin #32 on B+ and Pi 2. Do you know what it is on the compute module? (and what happens when you're using two cameras)

Thanks

Ben

Hi Ben/Dave the pins are moveable, see the docs here:

http://www.raspberrypi.org/documentation/hardware/computemodule/cmio-camera.md

Kind regards,

James

Looking at that page, the "Configuring default pin states" bit seems to be the relevant section. Based on James' assertion that the pins are moveable I'm guessing they're determined by the device tree configuration, but default to 2 and 30 for camera 0 and 1 respectively?

[6by9]

I hadn't noticed you had a Picamera method for setting the LED state so was a little confused as to why you cared.

Yes, your reading is correct if you think there is any such thing as a "default" config for the Compute Module. When creating the config blob they do also have the option for not defining an LED GPIO (same effect as setting "disable_camera_led=1" in config.txt) - not sure if you need to offer that too.
When tweaking the GPIO from the Picamera in any form I would suspect you need to disable the GPU control of the LED, otherwise you don't really know what it is up to any point in time.

[waveform80]

I must admit, adding control of the LED to the picamera library has bought no end of trouble; it was the only thing that broke with the release of the B+ (because the pin changed), it was the thing which broke Pi 2 compatibility (because of the reliance on the RPi.GPIO library which wasn't compatible on release) and it's caused the occasional issue with those using RPi.GPIO's BOARD mode (because I've no option but to force it to BCM mode for LED control). Looking back I probably shouldn't have added it!

Still, it's in there now so I need to support it at least until 2.0 (even then I probably won't remove it because it'd just cause a whole pile of "where's the led property gone?!" e-mails to come piling in ;). Anyway, given it's configurable I guess I should add an parameter to PiCamera.__init__ routine to cover that use case.

On the subject of disabling GPU control of the LED, I must admit I've no idea how to go about doing that (would that apply to the compute module platform only)? From playing with the property in the past (on my rev 2 model B; not sure if this still applies with later models) it seems that once GPIO is used to force an LED state, that state holds regardless of what the camera does (even something as major as changing modes doesn't seem to affect the LED).

Shutting down the camera causes the LED to switch off (even if the GPIO has forced it on) and re-initializing the camera causes the LED to switch on again (even if the GPIO has forced it off previously). In other words, the behaviour seems pretty predictable and conforms to the expectations set by led property (that whilst the camera is initialized, the property can be used to control the LED state). I'd love to know about any exceptions though!

[6by9]

On the subject of disabling GPU control of the LED, I must admit I've no idea how to go about doing that (would that apply to the compute module platform only)?

'disable-camera-led=1' in boot/config.txt (or rewrite the pins config to set "pin_define@CAMERA_0_LED" to (IIRC) INVALID - not many people rewrite the blob for things other than the CM though).

I'd love to know about any exceptions though!

I'd need to check firmware source, but on timeout of not receiving CSI-2 data (the one that eventually produces the dreaded "Unexpected control message 0x4f525245") the GPU does a full power down reset of the sensor. That probably includes resetting the LED line if defined. Hopefully not a common case, but one I can think of that may cause issue and think that only having one process/processor twiddling a GPIO.
User beware I think!

[waveform80]

'disable-camera-led=1' in boot/config.txt (or rewrite the pins config to set "pin_define@CAMERA_0_LED" to (IIRC) INVALID - not many people rewrite the blob for things other than the CM though).

Ah, of course, config.txt. Interestingly, that implies that the pin is actually configurable on all Pi's - I should've realized that. Oh well, all the more reason to make the pin configurable in PiCamera.__init__!

I'd need to check firmware source, but on timeout of not receiving CSI-2 data (the one that eventually produces the dreaded "Unexpected control message 0x4f525245") the GPU does a full power down reset of the sensor. That probably includes resetting the LED line if defined. Hopefully not a common case, but one I can think of that may cause issue and think that only having one process/processor twiddling a GPIO.
User beware I think!

Interesting; so far no-one's asked me about LED behaviour of this sort so I'm hoping it is indeed rare, but I should probably add something to the docs about it just in case anyone's relying on the behaviour.

[6by9]

config.txt is only for disable-camera-led. Pin configs used to go in /boot/dt-blob.bin as a device tree compiled thing, but that seems to no longer exist. I guess it has been merged into bcm2709-rpi-2-b.dtb and its siblings.

Always great if you can refer complainants to the docs. Works even better when customers have provided the spec and you can refer them straight back to it when they complain the functionality isn't as they desired :-)

edit Hmm, nope, I don't see the pins config in bcm2709-rpi-2-b.dtb. I wonder where that has gone then.