smart-leds-rs / apa102-spi-rs Goto Github PK

I'm trying to use the built-in DotStar led on the Adafruit ItsyBitsy nrf52840. I've confirmed on the pinout that it is an Apa102.

I initialize like so.

let port0 = hal::gpio::p0::Parts::new(cx.device.P0);
let port1 = hal::gpio::p1::Parts::new(cx.device.P1);

// Setup builtin dotstar led
let dotstar_pins = spi::Pins {
    // Pin numbers from <https://blog.adafruit.com/2021/05/26/pin-reference-adafruit-itsybitsy-nrf52840-prettypins/>
    sck: port1.p1_09.into_push_pull_output(Level::High).degrade(),
    mosi: Some(port0.p0_08.into_push_pull_output(Level::High).degrade()),
    miso: None,
};

let dotstar_spi = Spi::new(
    cx.device.SPI0,
    dotstar_pins,
    spi0::frequency::FREQUENCY_A::K125,
    apa102_spi::MODE,
);
// Not inverting end frame b/c adafruit does something similar in their bsp for other boards
// See <https://github.com/atsamd-rs/atsamd/blob/9495af975d6a35ae8bb455fae29ad0356fe20e09/boards/trinket_m0/src/lib.rs#L155>
let dotstar = Apa102::new_with_custom_postamble(dotstar_spi, 4, false);

I've tried varying the frequency and invert_end_frame. I'm running in release mode.

Here's how I try to actually set the led

cx.shared.dotstar.lock(|dotstar| {
    dotstar.write([RGB8::new(0, 0, 64)].into_iter()).unwrap();
});

This results in no visible change.

cc @therealprof, not sure whats going on here

I tested version v3 out on real hardware (ItsyBitsy M4). I was not able to get it working with the end frame polarity inverted - it would twitch blue and pink.

I could only get it working if I reset clock polarity back to all ones (0xff), which is no longer the default configuration.

This doesnt match my expectations.

Any chance you can try out the behaviour in v3 @therealprof ? would be interested to know how it behaves for your setup + if we can track down what its doing.

It was a shame to see that this library doesn't support setting the brightness of the LEDs; for my application I would appreciate it but I gather from the comments that this is an intentional omission because it didn't fit in with your application :).

I'd be happy to PR support for this, but I'm not sure how brightness fits in to the smart_leds_trait crate either.
It seems to have an RGBA colour type but I don't know if alpha truly corresponds to brightness...?
What would you accept?

Ultimately I can just run a fork with brightness support shoved in, but it would be nice to not fragment the system too much so that the next person who is happy to see an APA102 crate already exists won't find this feature missing :).

The code does send the "end frame" here:

But as a matter of fact that frame is bogus and will result in the first LED which not addressed by code to be fully lit after the second run of any sequence. This has also been confirmed a while ago here: https://cpldcpu.wordpress.com/2014/08/27/apa102/

Hi,

I have a led strip with 72 apa102, and I have to initialize an array with 73 colors to have the last one light up.
Either there's an off-by-one error somewhere, or the trailing frames are wrong.