I would suggest the first thing to do is to add diagnostic reports to the on-Pico code so it can report back when it has set GPIO2 high or low, and what it thinks GPIO15 is then reading as. And diagnostic reports as to what GPIO15 is when it's being sent back. Do both by checking the physical hardware registers, not using any functions in the code. It will be worth checking any function returns do match what the physical status is.I noticed something strange. If I keep read the value of gpio15 immediately after switching
gpio2 from low to high, gpio15 reports low. However if I keep reading gpio15 continuously
say like for 20 seconds it does report high as expected.
That way you'll be able to better determine -
- If GPIO15 is tracking GPIO2 when GPIO2 changes, whether there's a delay to setting GPIO2 when commanded to change
- Whether the issue comes in setting the LED, what the host is being told, or in the host itself.
Code:
Got LED setting commandSelect LED 1 (GPIO2)GPIO2 is set lowReading GPIO2 shows output lowReading GPIO15 shows input lowCode:
Got SWITCH reading commandReading GPIO2 shows output lowReading GPIO15 shows input lowReplied indicating SWITCH ONI have seen USB be sluggish when sending serial data from a Pico to Thonny so it's probably worth adding timestamps as well so you can check it's not just a flood of things causing USB packet processing to grind to a halt under a backlog of packets or similar.
Statistics: Posted by hippy — Sat Sep 06, 2025 7:15 pm