Why a Raspberry Pi shouldn't be powered through its GPIO pins | Hacker News Reader

Why a Raspberry Pi shouldn't be powered through its GPIO pins

82mhz.net

24 pointsspeckx17 comments

This is incorrect advice. It's fine to power via the header power pins (these are NOT gpio pins as the author claims, but are instead power pins on the pin header). The transient suppressor the author mentions isn't as valuable when you are hard wired via the header power pins, the TVS is necessary when you are plugging and unplugging the usb cables and there could be significant voltage differences in the cable vs. your PI that could cause damage. If you are direct connected and not plugging / unplugging there isn't an issue if the TVS components are bypassed because there aren't transients like that occurring.

Are the headers not connected to that same filter net anyway?

Wait a sec. Apart from the fuse, those protective elements are all in parallel with the 5V rail and they would work as intended. The drawing order is irrelevant.

The physical proximity of the TVS diode is relevant for protection purposes. By placing the TVS diode physically close to the USB port, it does a better job at protecting than if you placed it further away. That's because there's impedance of the trace that isn't shown in this circuit diagram that has to be considered for extremely fast transients like what a TVS diode aids with.

Yesn't. They don't operate at DC, so things like placement do matter. TVS diodes should be placed right next to the connector so it has the lowest possible inductance - which means the downstream hardware will see a less intense voltage spike. See [0], for example.

It's a similar story with capacitors, which should be placed as close to the power-consuming part as possible, with the capacitor in-between the voltage rail and the component. See [1], for example.

That doesn't mean it isn't going to do anything, though! It'll still work (especially bulk capacitors aren't very critical when it comes to placement), it'll just be less effective.

[0]: https://fscdn.rohm.com/en/products/databook/applinote/discre...

[1]: https://www.renesas.com/en/document/apn/an105-pcb-design-and...

This should be the top comment.

For the more literal people: in some weird scenarios you can actually power an MCU via its actual GPIO pins! See [0] and [1] for example.

The trick here is that most MCUs have integrated ESD protection diodes on all IO pins: there's basically a diode from the pin to the VCC rail, and a diode from GND to the pin. During normal operations this limits the voltage the gpio circuitry is exposed to within the 0V - Vf to VCC + Vf range, where Vf is the diode's forward voltage - usually about 0.7V or so. But if the VCC rail is floating, this means a high GPIO pin will now feed VCC - Vf to it, and similarly a low GPIO pin will drain a floating GND rail to GND + Vf.

Got 5V external IO signals? Your "unpowered" MCU is now getting 3.6V, which is plenty to run it! The pins aren't going to be very happy if you try to draw nontrivial current through it, but it will work.

[0]: https://electronics.stackexchange.com/questions/300866/mcu-g...

[1]: https://community.st.com/stm32-mcus-products-25/what-might-h...

For a standalone Pi power via USB is fine. As soon as these devices get embedded or you're running more than two in proximity the USB spaghetti gets pretty miserable.

There are so many quirks with the Raspberry Pi that make it a pain to work with, from the lack of mainline Linux support on the Pi 5 to the awkward by default power arrangement to the fact that the architecture is a GPU with a CPU glued onto the side. The Raspberry foundation made SBCs much more ergonomic and kudos to them but working with them still feels like walking through a field of tiny rakes.

TFA has a few red flags exposing a lack of knowledge in the subject matter.

First, the fuse used on the Pi is actually a polyfuse, a type of slow-resetting PTC thermistor. A high current causes a temperature rise that changes it into a metastable high-resistance crystalline structure or something, and it resets over a few hours or days with the power disconnected. It does not need to be replaced.

The polyfuse also causes a voltage drop that can noticeably cut into the Pi's very tight margins, so there is a reason to deliberately bypass it.

Second the capacitors do the same no matter where the power is from. Presumably the capacitors are placed near the chip. It does not matter that the schematic shows them between the power source and the chip because that is just showing logical connectivity. Placement of the TVS diode matters and that's presumably near the USB port.

Third none of this is about powering through the GPIO pins. It's about powering through the power pins next to the GPIO pins.

The pi 4 did away with the polyfuse so the VBUS at the USB port is the same node as the 5V pin on the GPIO.

I have many 3d printers powered pi's via the GPIO strip and I haven even made a HAT that does this. It isn't an issue if you do it right. As far as I remember the PI PoE Hat does it as well.

Is normal DC-DC fine? It gets ~22-25V on input and produces 5V on output and is rated at 5A. That's the way i use it and i had all kinds of problems in the project but not RPi power problems.

Like a switching regulator? That would be fine, a linear regulator though definitely not from those kind of voltages! Such a huge voltage drop would make a lot of waste heat.

What kind of issues are you talking about?

Oh well, it's a drone interceptor. It was never meant to be easy.

If by chance the supply is a transformer and its secondary has a center tap, you could use a center-tapped full wave rectifier (two diodes) which will yield a reduced voltage compared to a traditional full wave bridge across the entire secondary.

Aren’t there like pogopin pads or whatever they are called exactly for this purpose? Pretty sure my battery “hat” connects to those

503. Serving websites is a solved problem since 30 years. Even RPi powered via GPIO pins should be able to serve that website... /s

Reply on news.ycombinator.com