smart-leds-rs/smart-leds

The end user crate for smart leds (like ws2812)

Smart-leds

Use various addresable led like the ws2812 (neopixel) or apa102 (dotstar) in rust. As their protocol greatly differs and for some (like the ws2812) there are various methods, this crate doesn't implement any specific drivers by itself. It has to be coupled with a device driver that implements the smart-leds-trait, like the ws2812-spi, the ws2812-timer-delay or the apa102-spi drivers.

You can see some usage examples in the smart-leds-samples repo.

License

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

smart-leds's Issues

HSV to RGB conversion as a trait

Why is the hsv to rgb conversion handled by the hsv2rgb function and not by an implementation of the Into<RGB8> trait ?

It would mean that we can use it directly in write function of SmartLedsWrite, which would be really useful.

https://github.com/smart-leds-rs/smart-leds-trait/blob/2a082914382fc63e07681c8df28c13fc4dd72f21/src/lib.rs#L13

HSV to RGB conversion is wrong

Hi,

I think the HSV to RGB conversion is wrong. It also panics for hues above 190.

Testcode:

fn main() {
    for i in (0..=360).step_by(10) {
        let hsv_col = smart_leds::hsv::Hsv{hue: i, sat: 255, val: 255};
        println!("Hue: {} | {:?}", hsv_col.hue, smart_leds::hsv::hsv2rgb(hsv_col));
    }
}

Output:

Hue: 0 | RGB { r: 251, g: 0, b: 0 }
Hue: 10 | RGB { r: 211, g: 39, b: 0 }
Hue: 20 | RGB { r: 171, g: 79, b: 0 }
Hue: 30 | RGB { r: 131, g: 119, b: 0 }
Hue: 40 | RGB { r: 91, g: 159, b: 0 }
Hue: 50 | RGB { r: 51, g: 199, b: 0 }
Hue: 60 | RGB { r: 11, g: 239, b: 0 }
Hue: 70 | RGB { r: 23, g: 0, b: 227 }
Hue: 80 | RGB { r: 63, g: 0, b: 187 }
Hue: 90 | RGB { r: 103, g: 0, b: 147 }
Hue: 100 | RGB { r: 143, g: 0, b: 107 }
Hue: 110 | RGB { r: 183, g: 0, b: 67 }
Hue: 120 | RGB { r: 223, g: 0, b: 27 }
Hue: 130 | RGB { r: 0, g: 243, b: 7 }
Hue: 140 | RGB { r: 0, g: 203, b: 47 }
Hue: 150 | RGB { r: 0, g: 163, b: 87 }
Hue: 160 | RGB { r: 0, g: 123, b: 127 }
Hue: 170 | RGB { r: 0, g: 83, b: 167 }
Hue: 180 | RGB { r: 0, g: 43, b: 207 }
Hue: 190 | RGB { r: 0, g: 3, b: 247 }
thread 'main' panicked at 'internal error: entered unreachable code', /home/jonathan/.cargo/registry/src/github.com-1ecc6299db9ec823/smart-leds-0.2.0/src/hsv.rs:56:14
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Depending on how you interpret the hue type (degree as u16 or 360°/255) the values should be:
Degree:

Hue: 0   | RGB { r: 255, g: 0  , b:   0}
Hue: 30  | RGB { r: 255, g: 127, b:   0}
Hue: 60  | RGB { r: 255, g: 255, b:   0}
Hue: 90  | RGB { r: 127, g: 255, b:   0}
Hue: 120 | RGB { r:   0, g: 255, b:   0}
Hue: 150 | RGB { r:   0, g: 255, b: 127}
Hue: 180 | RGB { r:   0, g: 255, b: 255}
Hue: 210 | RGB { r:   0, g: 127, b: 255}
Hue: 240 | RGB { r:   0, g: 0  , b: 255}
Hue: 270 | RGB { r: 127, g: 0  , b: 255}
Hue: 300 | RGB { r: 255, g: 0  , b: 255}
Hue: 330 | RGB { r: 255, g: 0  , b: 127}

Fraction:

Hue:  0  | RGB { r: 255, g: 0  , b:   0}
Hue:  21 | RGB { r: 255, g: 128, b:   0}
Hue:  42 | RGB { r: 255, g: 255, b:   0}
Hue:  63 | RGB { r: 128, g: 255, b:   0}
Hue:  85 | RGB { r:   0, g: 255, b:   0}
Hue: 106 | RGB { r:   0, g: 255, b: 128}
Hue: 127 | RGB { r:   0, g: 255, b: 255}
Hue: 148 | RGB { r:   0, g: 128, b: 255}
Hue: 170 | RGB { r:   0, g: 0  , b: 255}
Hue: 191 | RGB { r: 128, g: 0  , b: 255}
Hue: 212 | RGB { r: 256, g: 0  , b: 255}
Hue: 233 | RGB { r: 256, g: 0  , b: 128}

Make named colors Deserialize

Hello :)
First of all, thank you for smart-leds, it's very convenient !

I'm using it in an embedded project that sends commands to an LED strip over Wifi/MQTT. I thus need to deserialize colors. You can check out the ugly From impl that allows me to do so for now.

Would it be possible to implement what's needed to "natively" deserialize named-colors directly from you crate, rather than having to implement that manually ?

Thank you, have a nice day !

HSV struct fields are named inconsistent

The RBG struct in https://crates.io/crates/rgb names the fields "r", "g" and "b". This crate uses "hue", "sat" and "val".

This is a change that would break dependent applications, but I it would be more consistent to use "h", "s" and "v".

[traits] Support RGBW as well as alternate orderings of channels

I have been tinkering with an sk6812 light strip (with about 500 lights) and also with ways to correctly address that.

The smart-leds-traits crate does provide for an RGBW type. However, the types like Gamma and Brightness specify an RGBW constraint.

In addition, sk6812 pulse ordering is R -> G -> B -> (W) instead of G -> R -> B for the ws2812.

In thinking about ways to support 4 channel, as well as different orderings. What we need is specialization :) . Since we don't have that, the only thing I can think of is to make traits that supply an iterator of iterators of values.

My thought is that we introduce a new trait called Channel which was just an iterator over ComponentType. So, effectively, we'd be supplying the "column" iterators, then the write/gamma/brightness functions would collect their set of iterators, and then poll each one, in order, as it is processing the colors.

One could also make a default implementation of the Color trait which produced a single iterator that just produces each ComponentType value, in order. So the existing implementations of write and friends don't have to change so much.

Thoughts?