Add an iterable source for the ws2812 led strip

[m5p3nc3r]

This allows for a 'swizzling' iterator if the led's are in a grid format without the need to create an intermediate buffer

Signed-off-by: Matt Spencer [email protected]

[m5p3nc3r]

I am working through using this for my use-case now, and I would like to make a further suggestion.

I would like to separate the sync and async part of the writing top the LED strip. This is because the context where I write to the back 'words' buffer may not be async friendly, and there is no need for the logic to be async.

The suggestion is to move words into the PioWs2812 struct. This should be net zero cost.

Then make the write and write_iter functions sync, storing the values in the words buffer. Something like this:

pub fn write_iter(&mut self, iter: impl Iterator<Item = RGB8>) {
    iter.zip(self.words.iter_mut()).for_each(|(color, word)| {
        *word = Self::pack_rgb32(color);
    });
}

Then add a flush function, which is the only async part of the operation

pub async fn flush(&mut self) {
    // DMA transfer
    self.sm.tx().dma_push(self.dma.reborrow(), &self.words).await;

    Timer::after_micros(55).await;
}

One last possible change - can we change the write function to make use of the write_iter as they have identical functionality?

pub fn write(&mut self, colors: &[RGB8; N]) {
    self.write_iter(colors.iter().cloned());
}

I am just unsure what the performance impact of the cloned is.

[m5p3nc3r]

Hey Guys

I came back to this today after a while away from the project. I am trying to tidy up the commit so it is in a better place to merge, but I don't understand the build and build-nightly failures. I'm pretty sure this is nothing to do with the minimal one file change I have made.

Can somebody explain why these tests are failing, especially seeing as all the other tests are passing.