Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
System and Application code can both use the LED with well-defined results #569
There are these issues relating to the LED not functioning correctly when used by both system and application code:
Essentially, when the system wishes to use the LED (listening mode, SOS, OTA update) the LED color isn't respected.
We will split the system LED notifications into various levels of increasing importance - background, normal, important, critical, and two sources system and application, with system notifications taking precedence over application notifications of the same level.
Normal System notifications:
System background notifications
System critical notifications
These are critical notifications because the block user code from running, so have the highest priority to ensure they are seen. When multithreading is added, setup mode and OTA in progress will execute alongside application code and will be reduced to background priority.
A new system service will provide the primary access to the LED, which is used by all aspects of the system (apart from perhaps the SOS handler since it has to be simple.) The LED service allows system and application code to request a LED color with a given priority, brightness, and pattern (steady, blink, fade etc..). The LED service places this request in a list of LED requests, sorted by priority, and uses the head of the list to compute the current "winner". For example, n application attempting to set the LED to blue for a normal notification doesn't replace the LED color of the system which is displaying a critical notification.
For each source (application/system) and urgency (background/normal/important/critical) there can be at most 1 unscoped request and 0 or more scoped requests. The unscoped request has a lower priority than scoped requests, and each scoped request has a higher priority than any scopes already existing for the given source and urgency. Scoped requests are typically short-lived requests that span a given action (such as entering listening mode) which is why they are given higher precedence than unscoped requests.
The enter/exit scheme works well for LED statuses with well defined scope. There are cases where we want to set the led with indeterminate scope, such as with the existing