Camera LED and Shutdown Direct Control on Pi 3B+

[jventerprises]

Hi all,

I found multiple ways on this forum to control the Camera LED and Shutdown lines on a 3 B+, but all the posts were old, and they all warn about the GPU possibly overriding my settings.

6by9s driver to control these GPIO seems the best bet:

Code: Select all

./rpi3-gpiovirtbuf s 133 {0/1}

and it works very well. I could even call the mailbox direct via linux:

Code: Select all

/opt/vc/bin/vcmailbox 0x00038041 8 8 133 {0/1}

but I am still worried about begin overwritten. Do I need to really worry about that, and is this still the best way to set these GPIO?

My pi 3 B+ is running the latest Raspian Buster. I am just a little concerned about another peripheral stomping on my settings.

Thanks for any help.

[6by9]

Why are you trying to directly manipulate them? What's your use case?

- If you run any of the GPU driven camera apps then it will try and power on the camera. Nothing else from the GPU will alter them.
- The Linux kernel also has a driver for them (generally registers as gpiochip1), so you could write a kernel driver that claims them to stop kernel users twiddling them.
- There is no way to stop a random app making the relevant mailbox calls to change the GPIO state, so you'll need to be a little cautious of what is running (although things tweaking the expander GPIOs directly are few and far between).

[jventerprises]

Hi 6by9,

Basically, I am designing my own IR illuminator replacement for an Arducam NOIR camera. I don't like their implementation of the illuminator as far as IR intensity control goes, nor the control of the cut filter motor itself, so I am toying with various ideas to get control to my circuitry over the standard 15-pin cable.

My thought was to hijack the LED and SHTDWN lines and bit-bang an I2C interface to talk to a custom CPLD which would then control IR intensity (via digital pot/LED driver), control the cut filter motor, plus a few other enhancements.

Barring this, I would have to run additional wires up to the camera board to run my circuitry. I would like to avoid the extra wires if possible, but it would not be the end of the world if I had to run them. I did not attempt to inject my control into the existing camera I2C since I would rather not touch the camera module itself.

Nothing is super critical here, and i have control of the overall system, so it sounds like my fears of the occasional 'bit stomp' should not be an issue if i design my protocol correctly. I think I will go ahead and try it.

thanks again.

[6by9]

You can stop the firmware doing anything with regard those GPIOs if you create a custom dt-blob.bin file in /boot based on https://github.com/raspberrypi/firmware ... t-blob.dts with CAMERA_0_SHUTDOWN and CAMERA_0_LED under pins_3b2 set to

Code: Select all

type = "absent"

See https://www.raspberrypi.org/documentati ... uration.md for more details of that file. It's not the nicest of interfaces as it overwrites the whole of the embedded version of that file, so it does become a maintenance burden.

Please note that the Pi4 has had the camera LED GPIO line removed as it is not used on the V2.1 camera module. If you bitbang or similar up the pair of GPIOs, then your solution will not be forward compatible with the 4.