sharpdisplay: Prevent 'ValueError: <pin> in use' exception #3277
Conversation
|
Which of those two cases didn't work? Do we have this issue with FourWire displays too? This feels weird. |
|
Neither case worked. I did not test with FourWire displays. I also didn't test with a different platform than nrf52. |
|
Fourwire buses are not affected according to my testing (6.0.0-a.1 on particle xenon) |
.. for the case where the bus was not in use
jepler
force-pushed
the
sharpmemory-bugs
branch
from
46722ba to
0bec391
Compare
| @@ -148,12 +153,19 @@ void reset_board_busses(void) { | |||
| bool display_using_spi = false; | |||
| #if CIRCUITPY_DISPLAYIO | |||
| for (uint8_t i = 0; i < CIRCUITPY_DISPLAY_LIMIT; i++) { | |||
| if (displays[i].fourwire_bus.bus == spi_singleton) { | |||
| mp_const_obj_t bus_type = displays[i].bus_base.type; | |||
| if (bus_type == &displayio_fourwire_type && displays[i].fourwire_bus.bus == spi_singleton) { | |||
There was a problem hiding this comment.
This is ready for a fresh look! Instead of adding a special case I removed one, so it's sure to be right(-er) this time.
@tannewt Is this specific change (to check the type of the bus before checking its bus property) right? I assume it's right (because if it's, say an I2CDisplay then the content at that address is unrelated but also would never equal the spi_singleton) but if it's intentional I'd change it back and add a comment explaining it.
There was a problem hiding this comment.
Ya, this looks correct to me. We check the type to know which union entry to use.
| @@ -148,12 +153,19 @@ void reset_board_busses(void) { | |||
| bool display_using_spi = false; | |||
| #if CIRCUITPY_DISPLAYIO | |||
| for (uint8_t i = 0; i < CIRCUITPY_DISPLAY_LIMIT; i++) { | |||
| if (displays[i].fourwire_bus.bus == spi_singleton) { | |||
| mp_const_obj_t bus_type = displays[i].bus_base.type; | |||
| if (bus_type == &displayio_fourwire_type && displays[i].fourwire_bus.bus == spi_singleton) { | |||
There was a problem hiding this comment.
Ya, this looks correct to me. We check the type to know which union entry to use.
.. when constructing the SPI bus again after reset.
Testing performed: on nRF52840, that these sequences would work repeatedly when soft-resetting in between invocations:
and
.. and that an actual demo would work across soft resets as well.
This feels a bit ad-hoc. Better would be to make "never reset bus" be a counted thing and add some "un-never-resets" in the right spots. An area for future improvement.