search

gloomyandy / RepRapFirmware

OO C++ RepRap Firmware
GNU General Public License v3.0
257 stars 61 forks source link

Control LED strip on skr 1.4 #32

Closed Cairon closed 3 years ago

Cairon commented 4 years ago

Hi, Seems that M150 is not yet implemented for LED strip control. Any idea about using the native neopixel pin on skr 1.4 with neopixel like LED strip ? Thank you.

jaysuk commented 4 years ago

There's not enough ram available on the LPC boards to allow neopixel support. The best you can do is turn something on and off using pwm.

On Thu, 27 Aug 2020, 11:39 Florian Dubois, notifications@github.com wrote:

Hi, Seems that M150 is not yet implemented for LED strip control. Any idea about using the native neopixel pin on skr 1.4 with neopixel like LED strip ? Thank you.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/gloomyandy/RepRapFirmware/issues/32, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATUSBRKRNRAP4QWNLNDJBTSCYZW5ANCNFSM4QM2YUGQ .

Cairon commented 4 years ago

The skr 1.4 have a build in neopixel socket. I supposed it's made to work (better) with. You can find severals working examples like this one: https://www.youtube.com/watch?v=SoAcZDXzd00

The base RRF provides the M150 command for this usage, but not duet3d yet.

If no way, I'll turn to control LED strip with an arduino, controlled via M260 (i2c Send and/or request Data).

gloomyandy commented 4 years ago

Neopixels are very tricky they have a ridiculous interface that requires very fast and relatively precise signal timing. There are really only two ways to meet these timing requirements, use some form of hardware, disable interrupts and use software.

When I originally looked at the Duet code for this DC42 only had a hardware solution that used the Duet SPI hardware. This solution allows addressing up to 60 neoplixels and requires a buffer of 700 bytes (basically each neopixel bit gets expanded to 4 bits). Unfortunately we can't do this on LPC hardware as we only have two SPI devices and they are already in use. A solution (similar to what we use for the software UART) is possible use memory to memory DMA, but this will expand the memory requirement considerably - basically each neopixel bit will require 4 DMA descriptors). Even then the timing requirements would be crazy and I'm not sure we could meet them.

The alternative (used by Marlin I think) is to disable interrupts and bitbang the data in software. But I didn't want to go that route because I was concerned about the possible impact on the control signals used for the stepper motors. However in the code for the new lower cost Duet 3 DC42 has added this option, his solution to the stepper motor control problem is to actually pause the motors while writing to the neoplixels. I think this is a good solution but it was not one I wanted to use just for the LPC version, however given this is now "official" behaviour I think we can probably do the same thing. The other good news is that this solution only needs 180 bytes of memory to support the same 60 neopixels. One word of caution though I think (from the comments) that DC42 really only intended this code be used for support of the LCD displays that neopixel backlights, not for the disco light setup that some users seem to go in for...

Having said all of that it may take me a while to add this support because...

  1. I don't have any neopixels to test with.
  2. I'm pretty busy at the moment trying to finish up the STM32F4 support and tracking all of the 3.2 changes from DC42.