debugprobe
debugprobe copied to clipboard
raspberrypi
Fix questionable onboard LED handling. Enforce/limit on/off time, extend to both SWD and UART read/write.
Fix questionable onboard LED handling. Enforce/limit on/off time, extend to both SWD and UART read/write.
Tested with LED on GP7 on a Waveshare RP2040-Zero.
This would benefit from attention from an expert to ensure that the LED is not triggered by the constant flow of SWD packets when OpenOCD is in the quiescent state.
The main project could usefully document that the Picoprobe's GP6 is reserved as a reset signal.
The PR comment should probably also mention that this adds optional support for a WS2812 LED too?
What needs to be done to get this lot resolved? I was discussing it with a journalist friend of mine who's writing on the Debug Probe, and it would be to everybody's advantage to get it sorted.
What needs to be done to get this lot resolved? I was discussing it with a journalist friend of mine who's writing on the Debug Probe, and it would be to everybody's advantage to get it sorted.
In the first instance, you need to rebase to get rid of the merge conflicts. Additionally, @lurch has made some suggested changes to your PR, which you haven't done as yet?
This PR also lacks a clear reason for its existence. What is "questionable" about the current state of affairs, and where in the commit messages is this addressed?
From reading the orginal intro message: A blinking led (on human timescale) gives the impression that something is happening. What @MarkMLl seems to have observed is that the led would flash so quickly that to a human it just looks lit. By enforcing a human noticeable off-time even when there is activity humans can observe "activity" better.
That's what I think this does.
I forget the detail, but my recollection is that the original author had tried to stretch the pulses but what he was doing quite simply couldn't work.
In any event I'm not able to put more time into this, and have fulfilled the conditions of the licence by contributing my changes. If the developers choose to sit on it for six months I'm afraid that I don't see that as my problem.
If the developers choose to sit on it for six months I'm afraid that I don't see that as my problem.
The developers haven't been "sitting on it for 6 months" - your code is currently unmergeable as it has file conflicts (as @aallan mentioned back in February) :