1

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.

2

It is possible (but far from simple) https://www.raspberrypi.org/documentation/configuration/pin-configuration.md

  • Device tree blobs are not a magic bullet. They do not prevent contradictory state changes before and after the blob is run. – joan Nov 11 '15 at 22:08
  • @joan true, but only for ~20mS rather than 20S. – Milliways Nov 11 '15 at 22:16
  • 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 Nov 12 '15 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 dtc that currently comes with Raspbian isn't any good for overlays, contra this doc (sec 2.1)... – goldilocks Nov 12 '15 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 dtc is fine for dt-blob.bin. Just make sure that is literally called dt-blob.bin (it doesn't exist in current installs). It is compatible with the existing dtbs in /boot. – goldilocks Nov 12 '15 at 19:08
1

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? – Peter Zhu Nov 11 '15 at 21:55
  • Sort of right. Most pins start off high or low. – joan Nov 11 '15 at 21:57
  • 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 Nov 12 '15 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. – joan Nov 12 '15 at 13:20
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.