Delay every 400ms when reading keys #10
Comments
|
The delay implies that something is blocking and preventing On some of my drivers for larger displays I provide an asynchronous |
|
Esp32 and i reducted own code just to HW setup and basic example from chapter 1. Nothing else. Even wifi is turned off. |
|
I've tested this using the ESP32 reference board and an Adafruit 1.8" ST7735R display. I modified the driver's def show(self): # Blocks 47ms on ESP32 reference board at stock frequency (160*128)
t = ticks_ms() # Added
wd = self.width
ht = self.height
lb = self._linebuf
buf = self._mvb
self._dc(0)
self._cs(0)
if self._spi_init: # A callback was passed
self._spi_init(self._spi) # Bus may be shared
self._spi.write(b'\x2c') # RAMWR
self._dc(1)
for start in range(wd * (ht - 1), -1, - wd): # For each line
_lcopy(lb, buf[start :], wd) # Copy and map colors (68us)
self._spi.write(lb)
self._cs(1)
print(ticks_diff(ticks_ms(), t)) # Addedchanging line 19 to read from time import sleep_ms, ticks_ms, ticks_diffThis showed blocking times of around 47ms. I suggest you check your SPI baudrate. My # Hardware SPI on native pins for performance. Check DRIVERS.md for optimum baudrate.
spi = SPI(1, 10_000_000, sck=Pin(14), mosi=Pin(13), miso=Pin(12))I tested with release firmware build V1.18 and current drivers and code. |
|
I've got around 35ms So this would not be source of blocking |
|
In which case I'm baffled. A lot of my development work on this GUI was with ESP32 and I never observed this behaviour. I performed detailed measurement of real time performance. The only code in the GUI which blocks for any significant period is Not having the hardware in front of me means I'm guessing wildly, but I'd start on the assumption that the GUI might not be the cause. Check for power supply issues: ESP32's can draw substantial current when connecting to WiFi causing voltage drops and odd behaviour. I know you're not using WiFi, but have you disabled AP mode? Another thing to try would be to write a simple I'm sorry I can't offer a clear solution to this. Something very odd is going on. |
|
Later I will try do clean flash, will try more revisions and will try to find it. Now I am at AP Mode I did not disable explicitly. I just did not done connect() what minimal uasyncio I can try - that flash LED or even some While true: print(hello) sleep 50ms? because if something will eat for 400ms time, it would be visible too. |
|
SPIRAM can cause substantial latency when GC runs. I have measured 100ms on various targets. I suggest you try this: from time import ticks_us, ticks_diff
import gc
def test():
t = ticks_us()
gc.collect()
dt = ticks_diff(ticks_us(), t)
print('GC time', dt) |
|
|
Well. if I will use stock stable 1.18 without SPIRAM then there is not that 400ms delay. with my build without SPIRAM it is fine too... Now why? But I think we can close this issue, because it's not problem with micro-gui library |
|
one more test without SPI RAM |
|
Well I found it.. Do not know why, but gc.collect() which is called from asyncio task in ugui.py took almost 300ms. So that will be source of that delay. And it's run every 500ms. So that is the reason of that blocking calling... But what now? Do not call gc.collect() too offten if SPI RAM is used? Actually it is not needed to call it such often because there are lot of memory available. |
|
I raised this RFC regarding GC time with SPIRAM. I think it's a big problem. The reason I explicitly run the You could simply not run Thank you for pointing out this issue, I'll make a note in the docs. |
|
For me is impossible run this project without RAM, because I use lot of cryptography libraries too, which took lot of resources aswell. So maybe solution for this would be disable yhis GC every 500ms and call it by own code with some longer delay, like 'screensaver' or so. In idle i have lot of time to do anything. But in user-input screens it must be responsive, so I can call gc collect when open some user interactive window, to prevent automatic upy collect. Maybe would be nice to be able disable that task other way than just fork code |
|
Agreed. # code omitted
from gui.core.ugui import Display, Screen
Screen.do_gc = False
# ...I've also updated the README. Please let me know what you think. |
|
Absolute good... |
|
Thank you for pointing out this issue and for testing. |
Some part of code causes keys are read like 7 times and then wait approx 400ms.
That causes little-bit strange lags during pressing keys
for test code I've used simple class TestPin instead pin to print ticks and calling "value"
Using simple demo from chapter 1 as main.py
using from drivers.st7735r.st7735r import ST7735R as SSD
The text was updated successfully, but these errors were encountered: