Zephyr OS LED Colors: Build the Array from the Controller Mapping Instead of Assuming RGB
An array containing red, green and blue values is only correct when its order matches the LED controller's declared mapping. Zephyr OS exposes that mapping through LED information. The color-setting API expects the caller to supply values in that order.
If a device's status indicator shows the wrong primary color after a board or driver change, inspect the mapping before adjusting color calibration. This review follows v4.4.0 and uses the LP50xx driver as a concrete implementation example, not a promise about every controller.
Keep a semantic color separate from its transport array
The versioned LED interface defines LED information with a color count and color_mapping. led_set_color() requires its input array to follow that mapping. led_get_info() is optional, and the wrapper reports an unsupported operation with a null information pointer when the callback is absent.
An application can keep a semantic color as named components, then construct the controller-specific array at the boundary. Do not make a global assumption that element zero always means red simply because a UI library or image format uses RGB order.
For a hypothetical mapping ordered blue, green, red, a semantic red-only request needs its nonzero red component in the final position. The precise values and brightness policy remain product choices. This example illustrates ordering only; it does not establish perceptual brightness or calibrated chromaticity.
Check what the driver does with the bytes
The tagged LP50xx implementation obtains LED information, checks the supplied color count and places the input elements into consecutive output-register bytes. Its color function does not reinterpret an assumed RGB tuple on the caller's behalf. The generated LED information obtains its mapping from devicetree.
That means a correctly sized array can still have the wrong semantic order. A successful bus write will not detect that mistake: the bytes can be valid for the registers while describing a different visible color from the application's intent.
When diagnosing a board variant, compare the generated mapping, actual LED wiring and the array sent by the application. Changing byte order in several layers at once can create two compensating mistakes that work only on one variant. Prefer one clearly owned conversion boundary.
Do not substitute absolute-channel indexing accidentally
The interface also offers channel-writing operations with absolute channel numbers. Those are not the same argument domain as the LED identifier accepted by led_set_color(). A helper that receives an LED number should not pass it unchanged as an absolute channel unless the selected controller's layout explicitly makes that correct.
Keep the two operations visibly distinct in application code. One names an LED and supplies its ordered color components; the other names a controller channel range. Mixing them can modify a different output while still producing an otherwise successful driver result.
If information retrieval is unsupported, stop assuming the mapping can be discovered through that optional API. Use a reviewed controller-specific configuration path or report the unsupported capability. Do not dereference the information pointer after an error.
Test single components before mixed colors
A useful board test drives one semantic component at a time using a safe, deliberately modest brightness setting. Check which physical emitter responds, then repeat for the other mapped components. Mixed colors are less revealing because two swapped components can produce a plausible-looking result.
Also test a deliberately incorrect component count in a disposable software test and verify that the application handles rejection. Keep that validation separate from actual optical measurement. A count check proves the number of elements, not the correctness of their meaning.
Once the mapping is established, test the product's named indicator states across board variants. Calibration, brightness scaling and blink behavior can then be assessed on top of a correct channel order. They should not be used to disguise an unresolved mapping error.
