Fix FrameBufferDisplay, displayio_display_core_start_refresh & bus_free #3508
Comments
|
Edit: running latest 6.0.0 beta 2, and sharp display is sole device on hardware SPI bus Edit2: I picked up python about 2 weeks ago, so i'm still learning. Added board.SPI().deinit() after displayio.release_displays() and It no longer holds onto spi. still this seems like odd behavior that in a soft reboot spi clock remains locked. is this by design? Edit3: is there any way to release/deinit the chip select pin or entirety of a framebuffer easily? I want to de initialize the sharp displayto speed up runtime code, then with an appreciable delay, reinitialize, and redraw from scratch if I need an update. while I can release clocks and SPI native lines, I cannot manage to release the chip select pin even when using digital libraries. I can confirm some issues with the sharp display not able to access spi in certain conditions. I have a project with a bluefruit sense nrf52840 and a 2.7 sharp memory display. I have code that runs through a menu to inspect and run sub files, and each sub file has a routine with supervisor to issue a soft reboot. Oddly if i use displayio.release_displays() and issue the reboot, on soft reboot it claims spi bus is busy when the display is initialized. If i hard reboot, the code functions as intended. I also leveraged the gc library to check memory at certain points in my code and found that on a hard reboot i get roughly 7,000 more bytes of free memory available on initialization. on EVERY soft reboot, i loose 7000-10,000 bytes of memory at the start of my code where only libraraies have been called. Not sure what is being held on to but the impact is significant where certain code can only run on a fresh power cycle and not on a ctrl d or softreboot with code. |
|
@tannewt Is this still an issue? |
|
I don't think so. It looks like SharpDisplay knows to bail if the SPI lock fails: circuitpython/shared-module/sharpdisplay/SharpMemoryFramebuffer.c Lines 162 to 166 in f3920c4
|
#3507 papers over a problem where we called
self->bus_free(self->bus);whenbus_freewas a NULL function pointer. In the case of RGBMatrix, this is fine. In the case of SharpDisplay, however, there is the possibility that the underlying SPI bus will be locked and we need to deal with it.This could be done by
self->busPresumably, without this fix, it is possible for a lockup to happen with an auto-refresh SharpDisplay and another foreground use of the SPI bus, including SD cards. However, I did not actually test anything in this area.
The text was updated successfully, but these errors were encountered: