no-std support

[mexus]

Hi @phip1611 and thanks for your superb library!

Are you interested in adding a no-std support to the crate? Or maybe splitting into a no-std crate + linux spidev adapter?

While using linux is good for prototyping, sometimes it's better to wire everything up into a microcontroller. As far as I can tell, only minor tweaks are required to make the encoding/timings part platform-agnostic, and I guess I can make an attempt to separate the stuff.

So, what do you say?

[phip1611]

Hi @mexus first of all, thanks for your interest in my library :)

Having a platform-agnostic version is a great idea. I tried to make my first attempt to make it #[no-std] but there are several problems:

• it probably will not work without splitting everything into two separate crates. My idea was to use Cargo-features (https://github.com/phip1611/ws2818-rgb-led-spi-driver/tree/dev). But this doesn't work/compiles with the SPI feature because the SPI-Adapter needs std to compile, because it usesstd::io::Write
• even if I can fix this problem: timings.rs is highly static and bound to a rate of 15.6MHz. I don't see a nice variant to make this dynamic, because:
  • WS2812_LOGICAL_ZERO_BYTESand WS2812_LOGICAL_ONE_BYTESalways must be a Multiple of 8

What are your additional ideas on that?

Please keep in mind: My main goal of this crate is to offer a very simple, stripped down, educational version of a driver so that everyone can understand it easily.

PS: In case you tried to make some changes by yourself. Please be aware of https://github.com/phip1611/ws2818-rgb-led-spi-driver/issues/4 - so don't wonder if the master branch is called main now :)

[chinoto]

I came up with a way to do dynamic timings a few months ago just for fun. I just rebased the branch to include a refactoring that makes the rest of it a bit easier to understand. https://github.com/chinoto/rainbow_emanator/blob/bool2byte/examples/rpi_ws2812/src/bin/rainbow.rs#L57

Edit: I think I decided to do the dynamic timings after learning that the timings have a fairly wide tolerance range and so you can aim for the lower bound to send RGB data faster. https://wp.josh.com/2014/05/13/ws2812-neopixels-are-not-so-finicky-once-you-get-to-know-them/

[phip1611]

@chinoto Thanks for the interesting links! I hope I can try to fix this issue soon! In a few days my big uni project is done and afterwards I have time.

Idea for the timing part:

• rename "timings.rs" into "static_timings_15600hz.rs" to have an easy to understand and readable file for educational purpose for everyone
• introduce a new "dynamic_timings.rs" module

Idea for the no_std problem:

• instead of using std::io::Write I use an embedded_hal abstraction

[phip1611]

By default, this crate has now the adapter_spidev-feature enabled which requires std. This can be deactivated and then this crate is really no_std. Current limitations: encoding.rs and timings.rs are still bound to the 15.6Mhz from the Raspberry Pi. As long as there are no dynamic versions of these modules it still should be really simple for everyone to adjust these values inside their project for the frequency they use by reading the code comments.