Is using GPIO 0 and 1 for custom sensors risky?

Using pin 0 and pin 1 for standard digital input sensors is totally fine, even if you aren't using the device for USB communication. The setup on the RP2040 chip is diferent from platforms like the Arduino Uno, so those concerns about conflicting serial data aren't relly warranted.

Those pins are integrated into the USB controller, but that integration doesn't mean they are shared in a way that breaks general-purpose input/output tasks. The USB functionality runs through a specific communication protocol, often referred to as CDC, which uses the chip's internal resources without requiring those specific GPIO lines to be constantly dedicated to it. The physical USB interface just handles the data exchange when it's active. As long as your code isn't actively trying to initiate a USB firmware transfer or flash a new sketch while the sensor is providing a signal on those pins, you shouldn't see any issues. The pins are dedicated GPIO lines and they aren't tied to some hidden background serial process that would interfere with a simple digital read from your sensor. If you are only using them for inputs and your main data stream is going over ethernet, they should be rock solid for your automation project. You can proceed with using them for your digital sensor inputs without worry about unexpected resets or communication drops from the Pico itself.

I've run several automation sensors on these pins for a job I did last month. The signal integrity was solid, but you definitely need to monitor the debouncing time if your sensor is mechanical. I always set my input delay to 5 milliseconds minimum when pulling state from pins 0 or 1. Dealing with a failing digital input is annoying, but the RP2040 handles the rapid switching much cleaner than some of the older ARM chips I've worked with. If you're using a Hall effect sensor for your project, just make sure your pull-up resistor value isn't too high or low. This prevents floating signals when the sensor isn't active.

I found that while those pins work fine for digital input, the pull-up/pull-down configuration really matters for noisy environments. If you're dealing with loose wires, you might be seeing false triggers. For me, the specific 10k Ohm resistor I used during my initial tests was what made the difference. It settled the signal right where I needed it to be. My project runs fine on a stable 3.3V setup, but if your sensor is sitting far away, that resistor helps keep the signal clean. Also, depending on what kind of sensor you are using, you might need to check the input voltage range before powering up the Pico. Some common sensors operate at 5V, which is too much for those pins.

I don't really trust the idea that the USB integration is completly isolated from low-level operations. The earlier post says the pins aren't shared, but that sounds a little too clean for how embedded chips work during startup. Even if my data is going through Ethernet, the bootloader still has to initialize everything. What if during that initial firmware flash or state check, it briefly toggles those lines in a way that messes with my simple input sensor? I've seen some chips behave strangely just waiting for thier primary peripheral to settle.

Update: It turns out pin 0 and 1 are totally usable. I found that implementing a five millisecond input delay completely fixed the sensor chatter. It seems the RP2040 handles these pins for standard digital input much better than I expected.