Interest in extending LED strip length?

Developers
1

Hi all!

I’m interested in fleshing out the LED strip support in klipper to handle longer strips of LEDs better (a 3m 60/m strip is $20 and goes over the limit!). I haven’t see a lot of activity in this area, so I figured I’d ask before sending stuff in case the answer is ‘you should be using a separate system for that’.

General ideas:

  • Allow a config to disable the LED limit (125-166 today) on secondary MCUs or some configurable basis.
  • Extend SET_LED with a ‘COUNT=XXX’ parameter that allows setting a continuous range of LEDs without making a template or setting each individually.
    • This is entirely host-side.
  • Add an ‘offload’ parameter to all chainable strip types that allows sending pixel data via SPI or PIO in the background and be able to process larger strips without stalling for 5ms+. This will have to be implemented per mcu since all the current spi drivers seem to be synchronous.
    • Note that neopixels can be offloaded to SPI as well. This should also solve the ‘no neopixel for host-mcu’ issue.
    • Are there other examples of longish commands that complete asynchronously with IRQs or DMA?
    • This might have to be double-buffered if we want to ensure we aren’t either tearing or waiting for a previous update to complete.

Thoughts?

2

Hello @jmerdich !

Honestly?

What’s the use of so may LEDs? Disco?

Don’t forget that the printer board must be able to deliver the additional load.

1 Like
3

This is why I ask before sending PRs :stuck_out_tongue:

You’re right that anything fancy belongs far far away from the main mcu. Hence secondary. I mostly care to do this at all because putting cheap led strips in a large square on the led of my enclosure goes over the limit, even if they’re likely all going to be some static variant of ‘grey’ and off the critical path. I understand if this is better left to some non-time-sensitive platform.