How likely is a GPIO output to send spurious signals?

Question

I have hooked up my Raspberry Pi to allow opening my front door.

It was great fun. It works fine. But... now I am a little bit worried that some interference (solar flares, cat barfing on the pi, power outage, etc.) might cause accidental switching and that my front door might be left open.

How likely is something like that to happen?

More details:

GPIO -> transistor -> Reed relay -> door opener

Answer 1

After reading everything twice I guess you got the right gist of the whole thing. Based on my experience, I'd advise against doing stuff with RC filters. MCUs are totally overkill for GPIO use as well as I2C and SPI as far as I am concerned but can make sense for 9-bit serial as (again) the linux provisions are nonsensically slow.

Let's see if I can give you some more info I accumulated from work.

1. At runtime, gpio pins (as in the physical pieces of metal on the board) behave just as the software commands. The chance a bad signal gets out is essentially NIL. We could discuss their timing. Timing is THE issue yet in general GPIO at runtime 'works as expected'.
2. Wires can pick up noise. To further discuss this issue I'd suggest the electronics stackexchange.
3. There's no problem at runtime. Do we all agree on that? The problem is at rebooot / before your program initializes.
4. I initially used the device tree method. It works better than the config.txt method in the sense in my experience it is applied sooner. If you are controlling electromechanical stuff I'd expect it be sufficient but it's quite some work and for some reason we couldn't make it work with Buster so we tried...
5. the config.txt method. It is very easy to setup but it is slower to apply => useless.
6. In general, I've found all pins with low pull-down (from the broadcom document) to be usable reliably, even at boot.

After all the grind from the above issues I've reccomended all our future designs involving the Pi to evaluate the need of an Output Enable pin.

In your case the setup seems sensible (I consider using a transistor to be more resilient to noise than mosfet even with pulldown) and GPIO17 is safe to me.

If you are even more concerned, you might consider an extended I2C bus. Since you'll then be transacting data the chance of a spurious activation gets dramatically lower. For a single wire, it doesn't seem much of a deal.

Edit: once again, thanks for consolidating those links, they are great resources!

Edit2: incorporating some additional info from comments.

I'm a little confused what you would want me to put on the other side of that I2C other than an MCU?

Let's see. As a start, I wouldn't expect I2C cables over a few meters long to work. There might be a reason for high-power I2C drivers/repeaters/buffer to exist but let's assume the signal gets the other end. You want to drive a bunch of pins "remotely". Then what you want is an I/O Expander. You don't need to write a firmware for them and they're somewhat hardened.

Do you still want to slap there an MCU? Sounds to me like plenty of work but that's your time!

And what is wrong with RC?

Again, you can definitely hack something with them. And perhaps they'll work but 1) for starters, there exist a noise which is exactly what your RC let pass 2) noise as picked up by cables as far as I know is just overcome my drive strength 3) I don't recall this approach being ever used on any of our designs, nor in any example I've seen (for this purpose).

Answer 2

The pins should be in the state defined in this Broadcom document until they can be changed by the user using a device tree blob. (source)

If this is not enough there are two good options:

1. Mitigate by using external RC low-pass and multiple pins some of which must be low and some high.
2. Use another MCU. It's usually well defined for them. So add another MCU and talk to it via I2C, SPI, etc.

--

Research remnants for posterity:

1. There is no proper datasheet for the GPIO pins.
2. Here is some unofficial documentation of the GPIO pins.
3. On Arduino it's pretty clear: at startup ports are set to input and are floating so a pull-down will help. Then you can do whatever you want but if you use the boot-loader it will use some pins.
4. This states that all pins are in input mode on power up but doesn't say anything about the boot loader, Linux or later stages. This is documented in this Broadcom document on page 102.
5. According to this there seems to be a config option to control output pins during boot but according to the docs this does not apply immediately.
6. There is a ton of good information in these questions.
7. Most useful so far is this semi-official information unfortunately the only conclusion from it is "it's messy".
8. This thread seems very useful but I still need to distill the information out of it.