Is there someway to make the changes from the GPIO utility permanent? Right now if I restart my RPi the changes revert back. I know I can use a script, but is there someway I can make the script start immediately at boot up since I'm using the GPIO to control motors and I don't want them to go crazy (100%) on bootup.
3 Answers
It is possible (but far from simple) https://www.raspberrypi.org/documentation/configuration/pin-configuration.md
answered Nov 11, 2015 at 22:00
-
Device tree blobs are not a magic bullet. They do not prevent contradictory state changes before and after the blob is run.– joanCommented Nov 11, 2015 at 22:08
-
-
State changes after the blob runs might be caused by the kernel loading, although I'd guess it doesn't actively do anything (i.e., the kernel doesn't set or assume default state). This is worth a try if a short delay is okay.– goldilocks ♦Commented Nov 12, 2015 at 13:05
-
Okay, so I tried this to light an LED on gpio 25. It happens within 1/2 second of powering on and stays on. As joan says, if that is potentially dangerous you would want a hardware solution. Caveats for posterity: The
dtcthat currently comes with Raspbian isn't any good for overlays, contra this doc (sec 2.1)...– goldilocks ♦Commented Nov 12, 2015 at 19:08 -
(one compiled using the kernel source tree works and it only takes a minute on the pi; you don't have to compile the kernel itself). However, the Raspbian
dtcis fine fordt-blob.bin. Just make sure that is literally calleddt-blob.bin(it doesn't exist in current installs). It is compatible with the existing dtbs in/boot.– goldilocks ♦Commented Nov 12, 2015 at 19:08
No, there is no way to guarantee the state of the GPIOs between power-up and the time your software runs (likely to be at least 20 seconds or so).
You will have to use external hardware to drive the GPIOs high or low if you want to control the GPIO state during that period.
-
All pins start off either high or low right? Its not random whether a pin is high or low? Commented Nov 11, 2015 at 21:55
-
-
You're right about there being some delay out of necessity (the kernel has to load first), but 20 seconds would be the end of a long boot time, vs. if you get it scheduled early it might only be 2 seconds. Of course Milliway's suggestion is better than that.– goldilocks ♦Commented Nov 12, 2015 at 13:03
-
There is potential for conflicting changes before and after a blob is run. The answer to the subject title is no. On the implied question I'd just choose GPIO which are pulled low by default and do not have more specialised usage, i.e. 12, 13, 22, 23, 24, 25, 26, and 27. Unless you are prepared to lock down the software and hardware there is potential for future conflict. A hardware solution is likely to be the only fail safe solution. A device tree blob solution fails if the SD card fails.– joanCommented Nov 12, 2015 at 13:20
You could use a tri-state buffer between the GPIO pins and your motor controller. Use a one-shot on the enable pin(s) to delay turn-on for long enough to complete the boot process. Resistors (~10K) on the output of the buffer can be used to set the initial state.
