Not working on Teensy 4.1

[RoyalFoxy]

I'm using a teensy 4.1 and when using a small sketch with fastled it works but when using this library to control the same hardware setup it does not work. Below is the rough code that I used. I'm using and older version of this library tho as the newer one doesn't compile due to dependency version mismatch – however I have tried just copying the current code of the library and adapting it to the older traits and it still didn't work.

let resources = t41(cx.device);

let lpspi4: board::Lpspi4 = board::lpspi(
    resources.lpspi4,
    board::LpspiPins {
        sdo: resources.pins.p11,
        sdi: resources.pins.p12,
        sck: resources.pins.p13,
        pcs0: resources.pins.p10,
    },
    4_000_000,
);
        
let apa102_writer = apa102_spi::Apa102::new_with_options(lpspi4, 4, false, apa102_spi::PixelOrder::BGR);

apa102_writer.write([RGB8::new(255, 0, 0)].into_iter()).unwrap();

I hope I just switched up two pins or something different.

Here is also the most simple code that I recreated after this library which also doesn't work but might help debug some things

use cortex_m::prelude::_embedded_hal_blocking_spi_Write;
use teensy4_bsp::board::Lpspi4;

#[derive(Clone, Copy)]
pub struct Pixel {
    red: u8,
    green: u8,
    blue: u8,
    brightness: u8,
}

const MAX_BRIGHTNESS: u8 = 0x1F;

impl Pixel {
    pub fn new(red: u8, green: u8, blue: u8, mut brightness: u8) -> Self {
        // Only 5 bits are allowed for brightness control
        if MAX_BRIGHTNESS < brightness {
            log::debug!("Brightness value {brightness} exceeds 5 bits (31+)");

            brightness = MAX_BRIGHTNESS;
        }

        Self {
            red,
            green,
            blue,
            brightness,
        }
    }

    pub fn to_words(self) -> [u8; 4] {
        const BASE_FIRST_BYTE: u8 = 0b1110_0000;
        const BRIGHTNESS_MODULATOR: u8 = 0b0010_0000;

        [
            BASE_FIRST_BYTE + self.brightness % BRIGHTNESS_MODULATOR,
            self.blue,
            self.green,
            self.red,
        ]
    }
}

pub struct LedWriter {
    spi: Lpspi4,
    number_leds: usize,
    end_frame_length_bytes: usize,
}

impl LedWriter {
    pub fn new(spi: Lpspi4, number_leds: usize) -> Self {
        let end_frame_length_bytes = number_leds.div_ceil(16).max(4);

        Self {
            spi,
            number_leds,
            end_frame_length_bytes,
        }
    }

    /// Check out https://cpldcpu.com/2014/11/30/understanding-the-apa102-superled/ for more information
    pub fn write(&mut self, mut buffer: &[Pixel]) {
        if self.number_leds < buffer.len() {
            log::debug!("Exceeded amount of leds to write");

            buffer = &buffer[0..self.number_leds];
        }

        const ZERO: u8 = 0x00;
        const START_FRAME: &[u8] = &[ZERO, ZERO, ZERO, ZERO];

        self.spi.write(START_FRAME).unwrap();

        for pixel in buffer {
            self.spi.write(&pixel.to_words()).unwrap();
        }

        for _ in 0..self.end_frame_length_bytes {
            self.spi.write(&[u8::MAX]).unwrap();
        }
    }
}

These are the crates I use:

[dependencies]
rtic = { version = "2", features = ["thumbv7-backend"] }
rtic-monotonics = { version = "1", default-features = false, features = [
  "cortex-m-systick",
] }
imxrt-log = { version = "0.1", default-features = false, features = [
  "log",
  "usbd",
] }
log = { version = "0.4", features = [
  "max_level_debug",
  "release_max_level_off",
] }
teensy4-panic = { version = "0.2", features = ["log"] }
teensy4-bsp = { version = "0.5", features = ["rt"] }
nb = "1.1.0"
cortex-m = "0.7.7"
apa102-spi = { path = "apa102-spi-rs" }
smart-leds-trait = "0.2"

And this is the git commit I checked out for this library to make it compile 1ca02fd (version 0.3.2)

Thank you a lot in advance for helping.

[Be-ing]

I'm using and older version of this library tho as the newer one doesn't compile due to dependency version mismatch

Could you elaborate on this? Much has been changed in this library since 0.3.2. I'm not inclined to volunteer to help debug already outdated code.

[RoyalFoxy]

Thanks for the answer. I get what you mean, I have used quite an old version of this library. The primary reason behind that was some version conflict of embedded-hal.

I found a template for the teensy4.1 to use as a base which includes everything from a hal to the building and flashing but sadly one of the main crates cortex-m uses an old version of embedded-hal, 0.2.7 to be exact and that old version is nowhere near compatible with the 1.0 version that this library uses atm so I used an older version.

However my main focus lies in actually getting to just have 1 led light up. I've struggled in the past weeks to make this happen with anything other than fastled in c++.

Initially I thought it was as simple as getting the spi, writing some bits to it and the led lights up if the bits are correct but it didn't work so far. Now I wondered considering the maintainers of this crate surely have experience with driving apa102 in rust if any of you could help me figure out whats wrong or what Im potentially missing.

I tried making the actual most basic code that should drive a single apa102 led to turn on as red.

let resources = t41(cx.device);

let pins = resources.pins;

let lpspi4: board::Lpspi4 = board::lpspi(
    resources.lpspi4,
    board::LpspiPins {
        sdo: pins.p11,
        sdi: pins.p12,
        sck: pins.p13,
        pcs0: pins.p10,
    },
    1_000_000,
);

Systick::start(
    cx.core.SYST,
    board::ARM_FREQUENCY,
    rtic_monotonics::create_systick_token!(),
);


use embedded_hal::blocking::spi::Write;

// Startframe 32 x 1
lpspi4.write(&[
        0b0000_0000_u8,
        0b0000_0000_u8,
        0b0000_0000_u8,
        0b0000_0000_u8,
    ])
    .unwrap_or_else(|error| {
        log::error!("spi write error: {error:?}");
    });

// Ledframe 32 x bits per led
lpspi4.write(&[
        0b1111_1111_u8, // 111x_xxxx = 3 mandatory bits + 5 bits brightness
        0b0000_0000_u8, // Blue
        0b0000_0000_u8, // Green
        0b1111_1111_u8, // Red
    ])
    .unwrap_or_else(|error| {
        log::error!("spi write error: {error:?}");
    });

// Endframe 32 x 1
lpspi4.write(&[
        0b1111_1111_u8,
        0b1111_1111_u8,
        0b1111_1111_u8,
        0b1111_1111_u8,
    ])
    .unwrap_or_else(|error| {
        log::error!("spi write error: {error:?}");
    });

Now this is somewhat specific to the teensy4.1 but it still uses embedded_hal under the hood for all traits and such. I already thought to open a different issue on their github to look at the actual implementation detail but I'd like you to look at the bytes that are sent and if they look fishy in any way or form.

Help would be greatly appreciated

[Be-ing]

I found a template for the teensy4.1 to use as a base which includes everything from a hal to the building and flashing but sadly one of the main crates cortex-m uses an old version of embedded-hal, 0.2.7 to be exact and that old version is nowhere near compatible with the 1.0 version that this library uses atm so I used an older version.

Ah, yeah the cortex-m crate is a bit of a mess right now and imxrt still doesn't implement embeded-hal 1.0 SPI traits 😵

If your use case is simply lighting a single LED red, this crate isn't really necessary. The bytes you are sending look reasonable, though I'd suggest using 0s for the endframe instead of 1s to match what this library does (I don't think it really matters either way if you only have a single LED; extra 1s on the end can light up LEDs past the end you intended to write but that's irrelevant when there's only one LED).

I suspect something is going wrong at a lower level. Are you able to use any other SPI peripherals? Have you tried different SPI bus frequencies?

[RoyalFoxy]

Thanks for the response. I was so unsure if it was the bits sent or if it's something else. I'd debug the processor but sadly the teensy4.1 does not support debugging for whatever reason...

Well my use case is more complex but for now I do just want to get a single led to light up to make sure it works.

The article that I read talking about what data to send to apa102 leds said to send a certain amount of data at the end to basically push the actual led data to the end of the led chain so ye it shouldnt really matter if its zeros or ones. Ill try it with zeros regardless

The teensy4.1 supports up to 3 different spis with each one having different pins but I havent tried using a different one yet as the lpspi4 is (on paper at least) the spi with index 0.

I have tried using frequencies of 40MHz, 30MHz, 20MHz, 10MHz, 6MHz, 4MHz, 1MHz, 100KHz, 10KHz and 1KHz. None worked.

I did try and look at how fastled implements for apa102 but sadly their code is a mess and, atleast the version I named, this crate does what my example does, just with more configurability and so on.

I'll try and solder to a the second spi tomorrow.

Somewhere under the hood of this implementation of lpspi however, there seems to be a lot of code happening when calling write and I'll try and look at what it does as well. Maybe even go one step further and use the underlying dma directly instead of the abstraction...

[david-sawatzke]

For APA102, as long as the output isn't too fast and does SPI it should work. Your issues sound quite weird, especially since it works with FastLED. Have you tried using the "raw" approach in your C++ environment and seeing if that works?

Have you compared at the signals between FastLED and your Rust code with an oscilloscope or a logic analyzer?

This is usually my first step in debugging issues like these, since it's hard to know what went wrong when configuring the hardware without seeing what it outputs.

If you don't have access to either, I would highly recommend your either buy a logic analyzer from e.g. Amazon (anything with 24 MHz and 8 Inputs is the same hardware and will work with pulseview, should cost <10€) or use an Pi Pico as a logic analyzer, which is a bit harder to set up: https://github.com/pico-coder/sigrok-pico/blob/main/GettingStarted.md

[RoyalFoxy]

I didn't know that logic analyzers were this cheap. I will check if I can buy one locally cause Amazon doesn't like my country.

Also what do you mean by raw approach? I just used the 'spi.h' to write to the leds. This is the example code chatgpt gave me as I'm not the best at writing c++ code.

#include <SPI.h>

const uint8_t LED_COUNT = 8;
const uint8_t BRIGHTNESS = 31;     // 0..31 (max is 31)
const uint32_t SPI_CLOCK_HZ = 6000000; // 6 MHz (typical for APA102)
const uint8_t APA102_CS_PIN = 10;

void apa102_send_start_frame() {
  for (int i = 0; i < 4; ++i) {
    SPI.transfer(0x00);
  }
}

void apa102_send_end_frame(uint8_t countBytes) {
  for (uint8_t i = 0; i < countBytes; ++i) {
    SPI.transfer(0xFF);
  }
}

// Color order for APA102 is B, G, R after the 0xE0|brightness header
void apa102_write_led(uint8_t red, uint8_t green, uint8_t blue, uint8_t brightness) {
  SPI.transfer(0xE0 | (brightness & 0x1F)); // Frame header with 5-bit brightness
  SPI.transfer(blue);   // Blue
  SPI.transfer(green);  // Green
  SPI.transfer(red);    // Red
}

void setup() {
  // Initialize SPI (uses LPSPI4 on Teensy 4.x)
  SPI.begin();
  // Optional: configure a dedicated CS pin if you want to gate data
  pinMode(APA102_CS_PIN, OUTPUT);
  digitalWrite(APA102_CS_PIN, HIGH);
}

void loop() {
  // Begin an SPI transaction with desired settings
  SPI.beginTransaction(SPISettings(SPI_CLOCK_HZ, MSBFIRST, SPI_MODE0));

  // Optional: bring CS low if you use a CS pin (not required for APA102 normally)
  digitalWrite(APA102_CS_PIN, LOW);

  // Start frame
  apa102_send_start_frame();

  // Set 8 LEDs to full red
  for (uint8_t i = 0; i < LED_COUNT; ++i) {
    apa102_write_led(255, 0, 0, BRIGHTNESS); // Red = 255, Green=0, Blue=0
  }

  // End frame (latch)
  apa102_send_end_frame(4);

  // Optional: bring CS high back if using CS pin
  digitalWrite(APA102_CS_PIN, HIGH);

  SPI.endTransaction();

  // Hold the color for a moment
  delay(1000);
}

[RoyalFoxy]

This issue is still relevant but I left my home to work in a different company for half a year and forgot to take my hardware with me so I sadly cannot continue trying to figure out a solution.

[Be-ing]

I'm closing this issue as it's not clear there's anything wrong with this library that's causing your troubles.

If you do get back to your project and can't figure this out, I would suggest considering getting a different MCU development board. There are jillions out there, many work with Rust, and they're cheap. If you really want to get to the bottom of this for curiosity or whatever, go for it, but if you want to get your project done, it's probably easier to just get a different board.