dvhdr/launchpad-pro

LED flicker

Opened this issue · 5 comments

I've noticed all LEDs flicker significantly, even if they aren't plotted by app_timer_event. It's not enough to capture on my camera, but definitely visible to the naked eye. The LED states are not changing, I plot them once and don't re-draw anything while it's flickering.

This was not the case prior to merging #46, maybe it has to do with something that was changed when hal_read_led was implemented? I'm not using that HAL call at all in my code.

dvhdr commented

This is really odd - I can't reproduce (LEDs are rock solid for me). Can you send me a code snippet?

It's possible that the additional time in ADC scanning is holding off the LEDs in some cases. Might be load dependent - is it a minimal app or is there lots going on? Do you see the flicker by, for example, modifying the example app to display LEDs (and of course removing the ADC display code)? Any particular colour combinations that flicker more prominently?

I can't get it to happen by modding the example app at all. I do notice that dim colors (max value 15ish) are easier to notice.

There's a fair amount of stuff going on, and it happens in my custom firmware project in all use cases I've been able to check. You can easily notice the flicker on my Setup screen, where the dim LEDs can definitely be seen flickering.

I've pushed your upstream changes to the api-improvements branch in mat1jaczyyy/lpp-performance-cfw, should you want to take a look. The master branch uses the open-source base from prior to #46, and doesn't exhibit the issue.

I've isolated the issue to my tempo keeping mechanism for Channel 2 / Channel 3 recreation. If the call to this function in app_timer_event is removed, the issue disappears.

I'm assuming my for loops in that function are too costly after the HAL has changed? If I remove one of them, the effect lessens and is barely noticeable, and if I remove both the problem is gone. I'm certain that after entering Setup immediately after booting, the flash_screen and pulse_screen are filled with zeroes.

I've just pushed a commit to the branch mentioned above that splits up the 2 for loops that draw flash/pulse into 4 tick calls / frames. This gets rid of the issue, so it could be that the hal_plot_led function has gotten more expensive to call because of the internally managed buffer for hal_read_led returns. However, I don't think they're even called on the Setup screen where the flickering is noticeable, it's just the failing if statement that is getting processed.

Please check out my findings and let me know if there's anything we can do about it.