If you're using RaspiOS 32 with the latest 5.10.11 kernel then you have /boot/overlays/spi0-1cs.dtbo and /boot/overlays/spi1-1cs.dtbo
Those free up the second CS pin. There's even an option to free up the MISO pin if you're doing send-only SPI transfers.
Info: Only use one CS pin for SPI0
Max input on VSYS (pin 39) is 5.5V (range 1.8V to 5.5V)
VSYS is the main system input voltage, which can vary in the allowed range 1.8V to 5.5V, and is used by the on-board
2.1. Raspberry Pi Pico Pinout 8
Raspberry Pi Pico Datasheet
SMPS to generate the 3.3V for the RP2040 and its GPIO.
From the Pico datasheet https://datasheets.raspberrypi.org/pico/pico-...
This answer does not address directly your question but it may solve your problem. After reading all suggested solutions it seems not to be simple task to have a save second boot option. A broken system may also affect the second boot option.
If you really want to have a fail safe system I simply would provide a second Raspberry Pi. This can be full tested ...
If you are not using them for SPI you can use them for any of their alternative functions. So yes, just set them to INPUT mode or OUTPUT mode using the GPIO library of your choice.
However the current Linux SPI driver leaves them in OUTPUT mode as it drives the select lines itself. You might have to use a different SPI driver.
If you are using pigpio set ...
If you have no experience in electronics, the easiest solution is to get a powerbank. There are even powerbanks which accept 18650 cells, such as this one (google "8pcs 18650 powerbank"):
Be careful when you put the cells in it: if you plug a cell which has a substantially different charge level it may get damaged, and plugging a cell with reverse ...
The broad approach is correct, although without detail of what you are planning to connect and transistor it is difficult to say.
You are driving the transistor with 3.3mA and it is probable that this would be insufficient to drive the transistor into saturation, which would lead to catastrophic failure at high load currents.
NOTE it is inadvisable to use ...
The circuit that you have drawn is correct for the Pi side. For the 1Ω in series with the LED , that would depend a bit on your LED strip. For a LED strip, I would use a 2N2222 (up to 500mA) or a TIP 120 if the current is larger (the TIP120 is a darlington, not a single transistor).
Alternatively, if you are very worried about your Pi, you can use an opto ...
For all Raspberry Pis I would assume the expansion header GPIO are always on /dev/gpiochip0.
It would be an extremely perverse decision to place them on any other gpiochip.
For reference the Pi4B has two gpiochips.
lines=58 name=gpiochip0 label=pinctrl-bcm2711
offset=0 flags=0 name=ID_SDA user=
offset=1 flags=0 name=ID_SCL user=
offset=2 flags=0 ...
Thanks to everyone's comments I've come to a solution. All comes down to not letting the wires float (as suggested by @Dougie). Connecting the wires in a breadboard does not guarantee that they be actually connected, so I soldered them, and that stabilized the address of the MCP23008 on the I2C bus.
Some pins are high at boot time. If you connected LEDs to each pin, you'd see which ones.
gpiozero will always turn a pin low when you initialise it, so if GPIO7 was on at boot, running led = LED(7) would initially set it to low (off) until you turned it on with led.on(). But when your script ended it would clean-up - and restore it back to its initial state ...
I believe the methods presented in those examples are still relevant.
libgpiod is the replacement for the sysfs method of directly talking to the GPIO as a Linux user. I.e. it replaces user functions to read and write individual GPIO and to be told about individual GPIO level changes.
It is not a replacement for all the kernel modules which currently talk ...
No. The GPIO are set to default values at power-down by the hardware. Those are the values that are set when the power is restored.
At power-up all GPIO are set as inputs. GPIO 0-8 have weak internal pull-ups enabled. The other GPIO have weak internal pull-downs enabled.
These settings may be overridden by software during boot.
If you want to defeat the ...
The odds of having a "bricked" system will be a product of the probability of a critical problem (P1) and the probability of the recovery mechanism not working as planned (P2). Designing a recovery mechanism lowers P2 (P2=1 if no recovery mechanism is in place), but at the same time it could increase P1 as your setup becomes more complex. As such, ...
Hip shot. You didn't share the device name.
1 - EN : Usually a high or low to enable the device. May be loose to default on. Basically an ENABLED or DISABLED feature. (locked or unlocked). You could try the three different states it can do,which is Ground, VCC or floating.
I'm sure you've figured it out by now.
Headphone-Right is connected to GPIO40.
Headphone-Left is connected to;
GPIO45 for Rpi-2B+ and earlier.
GPIO41 for RPi-3B and newer.
As with pretty much any connector, search for "[connector name] breakout board", and you'll see tons of adapters from that connector to some sort of GPIO breakout. For example, here's an RJ-45 breakout board: