esp32 service routine 20ms with gc not possible?

[pumelo]

Hi

I'm on a esp32 wrover module. I have an accelerometer which is attached over spi to the module. the accelerometer has a fifo which is to be read about every 20ms in order to not overflow. The accelerometer can signal a fifo watermark with a pin. I use this pin to call an interrupt service routine. This works fine and the service routine usually reacts within a few ms to the pin change. However, once in a while the it takes about 200ms to service the request. which makes the fifo of the accelerometer overflow ... :-/

I think this is related to the gc, as gc.collect() takes about 200ms ....

Is it correct, that with the current implementation of soft irq on esp32 there is no workaround to this? Not even the thread modul will help as there is still one common gil? Is the gil released during a gc run?

Any solution or suggestion to this problem?

BR This

[mattyt]

Perhaps try to confirm your suspicion: Disable the GC and see if you still get the 200ms pauses.

[pythoncoder]

200ms seems a long time for gc.collect(). On a Pyboard 3ms is more typical. I suggest you try regularly calling gc.collect() in code. If collections occur at a relatively high frequency, the time each collect takes is reduced (because it has less work to do).

[pumelo]

Thank you for your answers and suggestions.

@pythoncoder
Well the following code snippet prints about 38 continuously. Which means, that a gc run where the gc doesn't have anything to do takes about 38ms.

Code: Select all

import gc
import utime
while True:
    old = utime.ticks_ms()
    gc.collect()
    print(utime.ticks_diff(utime.ticks_ms(), old))

maybe this is due to the huge amount of ram available? ~4MB?

@mattyt
Well this is really interesting. Disabeling the gc did not solve the problem ... which means its something different hwich takes cpu time. No clue what that could be ... I'll investigate further.

Still the main problem presists. If my main python code uses memory at some point the gc will have to run collect and this takes at least 38ms

[kevinkk525]

Are you using the wifi/sockets in your application or just the SPI?

[jimmo]

maybe this is due to the huge amount of ram available? ~4MB?

Yes, I have the same results (38ms) on my 4MiB PSRAM ESP32, but back down to (3ms, similar to PYBD) on a generic internal-RAM-only board.

This makes sense -- the GC's mark phase scales with the working set, the sweep phase scales with the total RAM size.

[pythoncoder]

That is a very interesting observation, and a reason to avoid SPIRAM for some applications.