0

I'm building a little audio streamer box, using a Rpi4. This box has a few buttons, such as play/pause, next track, previous track, etc, as well as a power button that I want to use for turning it on (by shorting pins 5 and 6) and for sending a shutdown command.

I'm also using a small OLED display that is connected to the I2C bus (pins 3 and 5).

Is there a way to either move the I2C bus to other pins, so I can free up pin 5 for the power button, or can I somehow safely use pin 5 for both the I2C bus and the power button?

starfly
  • 3
  • 2

2 Answers2

0

The only pins usable for hardware I²C are 3,5.

You should be able to also use pin 5 to reboot (but AFAIK not shutdown).

See Will pulling pin 5 low will make the pi boot up again

You can use other pins to shutdown dtoverlay=gpio-shutdown.

Frankly there is little point. Reboot only works after a soft shutdown, which leaves most of the Pi running but still using significant power.

Milliways
  • 54,718
  • 26
  • 92
  • 182
0

You cannot share pin 5, but the RPi 4B has several hardware-based i2c channels, and at least one software-based i2c (i2c-gpio), available for use. These GPIO channels are listed and defined in your local /boot/overlays/README file; there's also a copy of this README file on RPi's GitHub site. These additional channels are declared and configured in your /boot/config.txt file as overlays.

I was forced to relocate my RTC from i2c1 because I also needed to use GPIO3 for another purpose. I chose to move my RTC from i2c1 to i2c0, and it has worked fine for months now. I wrote up the procedure I followed on this GitHub page.

Note that not all of the RPi's alternative i2c channels have pullup resistors (i2c0 & i2c1 have on-board pullups), and they may need to be added if your OLED display does not have them.

Seamus
  • 18,728
  • 2
  • 27
  • 57
  • I read this and your GitHub page and was intrigued. I haven't been able to use i2c0 for years. After reading the (rather confusing) `/overlays/README` I tried `dtoverlay=i2c_vc=on` on Bullseye and found `/dev/i2c-2` showed something on address 50 but no i2c0. I note I have been successful in using uart2 on GPIO0,1 – Milliways Jan 29 '22 at 04:16
  • @Milliways: IIUC, you've tried using `i2c0` on Buster also, but it wouldn't work?? I've reviewed some of this just now: The `i2c0` configuration is still in use on my RPi4/Buster/Lite machine. I didn't try it on my RPi3B+/Buster/Lite. I've recently "upgraded" RPi3B+ to Bullseye. Would it "*advance the cause*" if I tried to use `i2c0` on RPi3B+/Bullseye/Lite... would that tell us anything? – Seamus Jan 29 '22 at 12:07
  • I just tried on Pi4 running Buster. This shows i2c-22 i2c-0 i2c-10 but nothing connected - on Bullseye (Pi3B+) shows i2c-2 with address 50. In both cases no I²C devices actually connect to GPIO 0,1 – Milliways Jan 30 '22 at 03:52
  • @Milliways: I never tried it with nothing connected to the bus - in my case the slave device was an RTC w/ pullups on SDA & SCL. How would it even work with nothing on the other end of the bus? I mean, there's got to be something connected to get a result from `i2cdetect`. Are you referring to the output from `ls /dev/*i2c*`? If so, I think that only means the kernel has [*provisioned* a node](https://unix.stackexchange.com/questions/241173/how-are-dev-linux-files-created) in the device tree. Not sure we're on the same page??? – Seamus Jan 30 '22 at 13:58