You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The ADILed device setters appear to be broken in a few ways.
ext_adi_led_set_pixel returns the wrong port mutex on L493. It essentially tries to zero-index a port that was already converted to zero-index, since get_ports already transforms the smart port outvalue. As a result, it tries to release a mutex on the port below what the LEDs are actually plugged into. In many cases this can permanently deadlock the user program (from past testing).
All other setters have a strange bug where it takes calling them twice, with a delay between calls to properly update the hardware state. The minimum delays between two setter calls seems to be around 70mS.
Describe the bug
The
ADILed
device setters appear to be broken in a few ways.ext_adi_led_set_pixel
returns the wrong port mutex on L493. It essentially tries to zero-index a port that was already converted to zero-index, sinceget_ports
already transforms the smart port outvalue. As a result, it tries to release a mutex on the port below what the LEDs are actually plugged into. In many cases this can permanently deadlock the user program (from past testing).To Reproduce
This does not work
This does not work either
This does
This is likely an SDK bug. Sylib gets around this by updating LEDs in a daemon loop rather than just setting once.
Expected behavior
LEDs should update the first time the setter is called.
Screenshots
N/A
Desktop (please complete the following information):
Additional context
None
The text was updated successfully, but these errors were encountered: