6 ms·

For that to work correctly, the piece of code generating the signal should never be interrupted. To my knowledge, this is not possible with a Raspberry Pi. You

For that to work correctly, the piece of code generating the signal should never be interrupted. To my knowledge, this is not possible with a Raspberry Pi. You should see glitches on the output when your loop generating the 1s and 0s is interrupted. That may be ok it if you just when to send one static light pattern but the glitches should be more evident if you want to create beautiful, flowing light patterns. That's why it's better to drive those WS2812b with an Arduino that you code bare metal.

bitwize 7y ago
OP should consider installing a Xenomai kernel on his Pi, to handle the signal output in hard real time while still providing a nice Linux-based interface to his program.
Ao7bei3s 7y ago
APA102 is strictly better than WS2812B (standard SPI, much less sensitive to timing, way less PWM flicker, similar price/availability). When you still want bare metal, pick a modern uC like ESP8266 (cheap, 32 bit, integrated WiFi for trivial connectivity) instead of "classic" overpriced, outdated 8/16 bit AVR (Attiny/Atmega) based Arduino hardware. Arduino the software platform still works great of course, but so does NodeMCU which is the go to stack on ESP8266.
- zaarn 7y ago
  Arduino's still have a use, Atmega/Attiny in general, the chips are much cheaper, especially if you don't need connectivity.
- simcop2387 7y ago
  I'd recommend looking at some of the ARM dev boards instead of the ESP8266 for general purpose stuff and if you need the wifi, the ESP32. This is mostly because the ESP8266 is missing a lot of hardware functionality that you'll find in the ESP32 or any arm boards. In particular UARTs (serial ports), I2C, and SPI periphrials that can make working with other things like the APA102 a lot nicer to code for. With the arm chips you usually even can setup the SPI transfers as DMA so that you don't have to actually do any work on the cpu itself to drive the lights. That said the ESP8266 still has a place because of how cheap you can usually find them. Lowest price arm board that i know of from a manufacturer is the Teensy LC at ~$12USD, but there are cheaper ones out there on ebay and aliexpress. I just can't say anything about how well they work or are supported by anyone.
  - fluffything 7y ago
    The ESP32 is great. I love this board. The only thing that is missing is good Rust support.
    - AdrianoKF 7y ago
      IIRC, Espressif (the company behind the ESP32) is working on a clang/LLVM port to the Xtensa architecture, which would enable a Rust toolchain.
      - StavrosK 7y ago
        That would be a dream come true for me, but I've been hearing that for a few years, so I don't have much hope.
        AdrianoKF 7y ago
        They do have an issue for merging their fork back into upstream LLVM in their repo: https://github.com/espressif/llvm-xtensa/issues/8 https://github.com/espressif/llvm-xtensa/issues/8 Not sure how fast that's gonna happen, but one may hope!
  - wdfx 7y ago
    I bought a pair of esp8266 off Amazon for about £10 recently; they both look like some sort of knock-off, the PCBs are unbranded and the soldering looks somewhat less than perfect in places - however, both devices function perfectly. (WIP modular synth sequencer: https://photos.app.goo.gl/PcMqnUThygRG3T8v7 https://photos.app.goo.gl/PcMqnUThygRG3T8v7 ) I also have since bought a couple of ESP32 and think they are awesome.
    - codebje 7y ago
      Check the regulators on those cheap boards, they're often well under spec and cause brown-out reboots when the wifi gets working. If you don't use the more power hungry board features they still work fine.
theamk 7y ago
This uses hardware SPI module running at 3MHz. Those modules are buffered, and as long as there are no underruns, there will no glitches at all. And the userspace sends entire buffer in one syscall, so those underruns will have to be caused by kernel stall, which usually only happens when buggy device drivers are present.
- amelius 7y ago
  That seems like the right way to do it, but this piece in the article is a bit unclear: > Now taking a look at the duties of the PWM signal we need to send, we can approximate the highs and lows to some multiple of 1/3. This means that if we run a MOSI SPI signal at triple the frequency the lights expect, then we can send a single WS2812b "panel bit" using a combination of 3 SPI bits.
jamesfmilne 7y ago
It’s possible, using the isolcpus kernel command line argument, to prevent the scheduler from managing certain CPU cores. You can then manually assign a thread to an isolated core, and it will run there without any interruptions from thread switching. You can also map interrupt handlers away from those isolated CPUs. There may be architectural things that cause interruptions you can’t mitigate though (like SMIs on Intel).
amelius 7y ago
I think the RPi output ports should be equipped with a buffer. It could work just like the buffered output of audio signals, so if you write reasonably quickly, then there will be no loss in the signal. Of course, there will be some latency, but in many applications (including this one), that will not be a problem.
pjc50 7y ago
Unfortunately this is a "middlebrow dismissal": you know a fact, but not the whole context, and therefore end up claiming that something won't work when in practice it works fine. The code uses the SPI peripheral, it's not generating the 1s and 0s individually but handing a buffer of them over to the OS which will DMA them out.
- StavrosK 7y ago
  You do need the buffer to never underrun though, no? That having been said, if this works reliably, it's fantastic. The ESP32 is pretty great, but controlling WS2812b LEDs from a Pi Zero would be extremely convenient as well.
  - davemp 7y ago
    It’s not very hard to avoid under-runs with a ~125MHz SPI core vs a 1.5GHz quad core cpu.
  - pjc50 7y ago
    It only matters if the underrun is in the middle of a message, and the messages are short enough to fit in the buffer whole. I'm sure there are already libraries for driving WS2812b from Pi, such as from Adafruit. Certainly the WS2801 library works.
nemetroid 7y ago
The article mentions that they attempted bit banging first, but it didn't work precisely for the reasons you mention, which is why they used SPI instead.

bitwize 7y ago

OP should consider installing a Xenomai kernel on his Pi, to handle the signal output in hard real time while still providing a nice Linux-based interface to his program.

Ao7bei3s 7y ago

APA102 is strictly better than WS2812B (standard SPI, much less sensitive to timing, way less PWM flicker, similar price/availability). When you still want bare metal, pick a modern uC like ESP8266 (cheap, 32 bit, integrated WiFi for trivial connectivity) instead of "classic" overpriced, outdated 8/16 bit AVR (Attiny/Atmega) based Arduino hardware. Arduino the software platform still works great of course, but so does NodeMCU which is the go to stack on ESP8266.

zaarn 7y ago
Arduino's still have a use, Atmega/Attiny in general, the chips are much cheaper, especially if you don't need connectivity.
simcop2387 7y ago
I'd recommend looking at some of the ARM dev boards instead of the ESP8266 for general purpose stuff and if you need the wifi, the ESP32. This is mostly because the ESP8266 is missing a lot of hardware functionality that you'll find in the ESP32 or any arm boards. In particular UARTs (serial ports), I2C, and SPI periphrials that can make working with other things like the APA102 a lot nicer to code for. With the arm chips you usually even can setup the SPI transfers as DMA so that you don't have to actually do any work on the cpu itself to drive the lights. That said the ESP8266 still has a place because of how cheap you can usually find them. Lowest price arm board that i know of from a manufacturer is the Teensy LC at ~$12USD, but there are cheaper ones out there on ebay and aliexpress. I just can't say anything about how well they work or are supported by anyone.
- fluffything 7y ago
  The ESP32 is great. I love this board. The only thing that is missing is good Rust support.
  - AdrianoKF 7y ago
    IIRC, Espressif (the company behind the ESP32) is working on a clang/LLVM port to the Xtensa architecture, which would enable a Rust toolchain.
    - StavrosK 7y ago
      That would be a dream come true for me, but I've been hearing that for a few years, so I don't have much hope.
      - AdrianoKF 7y ago
        They do have an issue for merging their fork back into upstream LLVM in their repo: https://github.com/espressif/llvm-xtensa/issues/8 https://github.com/espressif/llvm-xtensa/issues/8 Not sure how fast that's gonna happen, but one may hope!
- wdfx 7y ago
  I bought a pair of esp8266 off Amazon for about £10 recently; they both look like some sort of knock-off, the PCBs are unbranded and the soldering looks somewhat less than perfect in places - however, both devices function perfectly. (WIP modular synth sequencer: https://photos.app.goo.gl/PcMqnUThygRG3T8v7 https://photos.app.goo.gl/PcMqnUThygRG3T8v7 ) I also have since bought a couple of ESP32 and think they are awesome.
  - codebje 7y ago
    Check the regulators on those cheap boards, they're often well under spec and cause brown-out reboots when the wifi gets working. If you don't use the more power hungry board features they still work fine.

theamk 7y ago

This uses hardware SPI module running at 3MHz. Those modules are buffered, and as long as there are no underruns, there will no glitches at all. And the userspace sends entire buffer in one syscall, so those underruns will have to be caused by kernel stall, which usually only happens when buggy device drivers are present.

amelius 7y ago
That seems like the right way to do it, but this piece in the article is a bit unclear: > Now taking a look at the duties of the PWM signal we need to send, we can approximate the highs and lows to some multiple of 1/3. This means that if we run a MOSI SPI signal at triple the frequency the lights expect, then we can send a single WS2812b "panel bit" using a combination of 3 SPI bits.

jamesfmilne 7y ago

It’s possible, using the isolcpus kernel command line argument, to prevent the scheduler from managing certain CPU cores. You can then manually assign a thread to an isolated core, and it will run there without any interruptions from thread switching. You can also map interrupt handlers away from those isolated CPUs. There may be architectural things that cause interruptions you can’t mitigate though (like SMIs on Intel).

amelius 7y ago

I think the RPi output ports should be equipped with a buffer. It could work just like the buffered output of audio signals, so if you write reasonably quickly, then there will be no loss in the signal. Of course, there will be some latency, but in many applications (including this one), that will not be a problem.

pjc50 7y ago

Unfortunately this is a "middlebrow dismissal": you know a fact, but not the whole context, and therefore end up claiming that something won't work when in practice it works fine. The code uses the SPI peripheral, it's not generating the 1s and 0s individually but handing a buffer of them over to the OS which will DMA them out.

StavrosK 7y ago
You do need the buffer to never underrun though, no? That having been said, if this works reliably, it's fantastic. The ESP32 is pretty great, but controlling WS2812b LEDs from a Pi Zero would be extremely convenient as well.
- davemp 7y ago
  It’s not very hard to avoid under-runs with a ~125MHz SPI core vs a 1.5GHz quad core cpu.
- pjc50 7y ago
  It only matters if the underrun is in the middle of a message, and the messages are short enough to fit in the buffer whole. I'm sure there are already libraries for driving WS2812b from Pi, such as from Adafruit. Certainly the WS2801 library works.

nemetroid 7y ago

The article mentions that they attempted bit banging first, but it didn't work precisely for the reasons you mention, which is why they used SPI instead.