pewpew10 - use _pew.get_ticks() for time tracking

[deshipu]

Somehow PR #4200 got
reverted, repeating it, with a proper tag.

[tannewt]

Sorry for the regression! Submodules are a bit tricky.

[deshipu]

It's my fault for failing to tag it correctly.

By the way, this interrupt disabling in the time functions may still be affecting other modules, like pulseio, pwmio, or audioio, so maybe it would be good to revisit it when there is some time.

[dhalbert]

By the way, this interrupt disabling in the time functions may still be affecting other modules, like pulseio, pwmio, or audioio, so maybe it would be good to revisit it when there is some time.

Could you elaborate on this? I am thinking there might be issues about this elsewhere as well. What did you fix in your own code? Thanks.

[deshipu]

I basically count the frames in _pew and use that for timekeeping in the pew library, so that I don't have to use time.monotonic() or time.sleep(), which both have code that disables the interrupts for a time to read a multi-byte register atomically.

[dhalbert]

Are you saying the interrupt disabling in time.sleep() etc. loses ticks, or just delays them?

[deshipu]

What's the difference between a lost timer tick and a delayed one?

[dhalbert]

If the tick incrementer loses ticks, then the time "clocks" will run slow. If the time incrementer ticks are delayed, then there will be jitter in the time reporting, but we won't lose time in the long run. But I think I may be missing your point.

[deshipu]

Oh, so you would get clumps of ticks, but on average the number of ticks would be correct? Considering that the brightness of the LEDs is affected (see the horizontal lines on the last video), I would say they are getting lost, but I can't be certain if the background flicker that is also present is not due to them also being delayed/clumped.

[deshipu]

I made some signal captures on the original issue #3504 — maybe that will be helpful.