You could be right - So it's going to be challenging for MicroPython and similar interactive languages to deal with whatever users may throw at it at run time, trying to figure out 'if you did that you can't now as for this".I don't think that it reasonably can - from my understanding of what the erratum note says, this isn't fixable in a general way.I had assumed the Pico SDK would mitigate RP2350-E9 by handling the situation itself, silently applying the fix so existing code which uses pull-downs work just the same when compiled for an RP235X as an RP2040.
That is what I was thinking.The easiest case is if the SDK knows that the GPIO in question is only being used for polled input. In that case, gpio_set_dir() could, instead of setting the pin to input, set it to disabled - then in gpio_get() briefly enable the input just for long enough to sample it.
Modify the SDK "gpio_*" functions to leave the pin in an errata fixed state when input and pull down. Then 'gpio_get' can do as you say, return it to the errata fixed state when done.
That should solve things for most casual users without them having to worry about it but will not solve the issue for others.
I believe it would be worth doing that for those casual users even if it doesn't fix other cases. Otherwise those users have to alter their code and they will likely the least capable when it comes to doing so.
Unfortunately I think you are right.And some things just won't work at all with no straightforward software workaround
Some sort of analysis of the source at build time might be able to determine when there isn't problem, when it can be fixed by the simplistic changes to 'gpio_*' functions as described, and those cases where the user has to refactor their code or change the hardware.
MicroPython and other interactive languages and shells will have to do that analysis at run-time based on GPIO state to say "Can't do that" or simply let it fail, risk letting code which worked on the RP2040 behave differently on the RP235X.
I have always advocated using short-to-0V buttons with an internal pull-up to 3V3 and if others have done that they will have side-stepped the issue. But there are other cases where I have used pull-downs; in keypad matrix scanning, for UART to produce that 'break' as you noted, and PIO code because active high is easier to use there and pull-down is needed to prevent floating.
Food for thought - and I haven't gone further than thinking of it - what about, instead of enabling pull-down when requested, enable pull-up and pin inversion ? That won't help when there's a button between 3V3 and the pin, but might help for other cases where the pull-down was only used to create a not-connected low.
I would agree with that.I think the descripion in the erratum notice is pretty clear as to what the problem is, but it seems like it needs fairly inventive and application-specific workarounds.
What I am going to do is hack the 'gpio_*' functions which MicroPython uses to work as above, as per the errata fix, and see what fails.
I am thinking of looking to see if there's a 'fix it by unlatching a lock-up' option to minimise changes to when it's read though that might not play nicely with anything else using that pin.
But I am wondering if it's even worth fixing or working around ?
If A3 stepping is going to arrive before RP235X enters mass-production, gets included with the next revision of Pico 2 and subsequent Pico 2W, and it's fixed in that, everything will just work as it should without any hacks, kludges or changes.
Until then the Pico 2 is going to be less of a "drop-in replacement for the Pico" for some people than they were hoping for.
Statistics: Posted by hippy — Sat Aug 24, 2024 4:41 pm
