Help creating NeoPixel LSD-language
-
@zapta
It would be cool to program the Arduino through a DWC plugin, but there are so many different Arduino boards and they need special parameters to flash.The RPi Pico was the first CoPro that came to my mind, but for the LED strips I got it would again need a level shifter. (Although I have the code for NeoPixel state machines, I don't want to add another PCB)
The Adafruit NeoPixel library is already there and easy to use, so I'll stick with it
-
@dc42
The other NeoPixel libraries I've seen yet, use 800kHz as SWI frequence.
Why does the BitBang method for Duet2 use 2.5MHz? BTW.: I've set it to 2.4MHz, but it showed 2.5MHz?
Even the RRF STM branch seems to use 1250ns cycle time = 800kHz -
Several Duet boards have firmware support for Neopixel and/or Dotstar already, though limited to 60 LEDs.
The simplest expansion would be a multiplexer controlled by some other outputs, that allows each M150 to update a different bank of LEDs, so the whole array can be updated in a few lines in a macro.
And with a separate 5V power feed so the Duet is not overloaded.If you specifically want to control large numbers from a separate MCU, then one simplest colour setting method could be an image file, like four rows of 72 pixels for your example, with each settable to any 32 bit RGBA value?
Saved as uncompressed bitmaps, they are quite simple to interpret.
For unrestricted updates within a gcode program, you cannot get around the fact that each LED somehow needs four 0-255 values.
The format Duet use in the M150 command is pretty much as simple as it can get, for that.For a cheap and powerful MCU, have a look at the Seeeduino Xiao - SAMD21 ARM M0 CPU with 256K flash, 32K RAM; same as the Pi Pico but smaller. That works with the Arduino IDE once you add the Seeed library.
It's the same memory etc. spec as the Pi Pico, but less I/O connections & Arduino compatible.To minimise software overhead, you can run Neopixels from an SPI port, using just the data connection.
Each data bit to be sent becomes one nibble in the SPI stream, either 1000 for a 0 or 1100 for a 1, at an SPI data rate of 4MBit
Pause for 50uS minimum at the end of each sequence.If you use 32 bit words and start with 0x88888888 as a template each time, you can translate each output byte to a word that sends 8 bits in a small, fast function that checks each input bit and sets the appropriate "4" bit in the output nibbles if its a 1.
(I use that method in my christmas lights, though they run from a DSPIC MCU). -
@rjenkinsgb
Thanks for answering. I must admit, I don't understand the last paragraphs about SW-details, but lets start from the top.
A multiplexer would need a few extra pins and it has to be a level-shifter, too. Furthermore it wouldn't take workload from the Duet, it would quadruple it (in my case).
With all respect, this is no option IMHO.@rjenkinsgb said in Help creating NeoPixel LSD-language:
For unrestricted updates within a gcode program, you cannot get around the fact that each LED somehow needs four 0-255 values.
The format Duet use in the M150 command is pretty much as simple as it can get, for that.Unrestricted is not my goal. I want to describe the look of each strip instead of specifying each LEDs colour/brightness.
Eg. tell the CoPro to fade LEDs #0-72 from dark red to bright white (*). That would be a string of a few bytes length only! The CoPro would then do the hard work of pushing Bits around.
The restriction would be the complexity of the description.*) the string would be like a gcode line where each parameter has a letter followed by numbers: M150 P{0,72} B{50,250} C{hFF0000, hFFFFFF}
@rjenkinsgb said in Help creating NeoPixel LSD-language:
For a cheap and powerful MCU, have a look at the Seeeduino Xiao - SAMD21 ARM M0 CPU with 256K flash, 32K RAM; same as the Pi Pico but smaller. That works with the Arduino IDE once you add the Seeed library.
It's the same memory etc. spec as the Pi Pico, but less I/O connections & Arduino compatible.Yes, I've seen that too and there is a "NeoPXL8 friend" for it, that allows us to control up to 8 strips w 250 LEDs each!
I haven't digged deeper into this, if it would coop with Duet/gcode.
Very promising indeed... -
@o_lampe said in Help creating NeoPixel LSD-language:
how to send a string (with momentary object model data [eg. XYUV-pos, print status, bed temps etc.] )?
Is it a simple echo> "... to a TX-pin?I figured out it's M118 which sends data to a specific target. I'd either try USB or PaneDue port. Although IDK, if Duet's OTG USB port would act as host?
-
@o_lampe said in Help creating NeoPixel LSD-language:
but there are so many different Arduino boards and they need special parameters to flash
There is no need to flash or deal with Arduino differences. Once you flash the LED language interpreter in the arduino, all should look the same. Then, at the beginning of the print you select or download the LED language program and during the print you send commands to control it (e.g. set head x,y for the sand table program).
The nano is very limited though, no much rom/ram. Old school 8 bits AVR
-
@o_lampe said in Help creating NeoPixel LSD-language:
A multiplexer would need a few extra pins and it has to be a level-shifter, too. Furthermore it wouldn't take workload from the Duet, it would quadruple it (in my case).
It would need some extra pins, yes. Two pins for four banks, three for eight etc.
As for workload - it is virtually zero.
The firmware converts the gcode parameter to the required data, then sends it using a hardware SPI port and DMA - so the whole data-output routine is hardware and uses zero CPU time or resources.
It just needs to interpret and convert the gcode line when that is read.For an external unit, the hardest part would be getting the command string to it, from whichever Duet.
I had considered, for another application, using the Duet LED output as a kind of communications link to a slave SPI in the add-on MCU.
That can send as many words of definable data as is needed, using colour values for a small number of "LEDs" as the command data; 24 bits or more each, depending on the data format.
Commands like your example above could be sent by a string that, as far as the Duet is concerned, just sets colours on four LEDs.
-
@rjenkinsgb said in Help creating NeoPixel LSD-language:
As for workload - it is virtually zero.
The firmware converts the gcode parameter to the required data, then sends it using a hardware SPI port and DMA - so the whole data-output routine is hardware and uses zero CPU time or resources.If the goal is to have animations such as shifting heart beat, it requires frequent updates with each LED has a different color than its neighbors so I don't think the duet is a good fit (vs offloading to an external processor as @o_lampe plans to do).
-
@rjenkinsgb said in Help creating NeoPixel LSD-language:
using a hardware SPI port and DMA - so the whole data-output routine is hardware and uses zero CPU time or resources.
I have to take your word for it.
But then I'm asking myself, why there is a limitation of 60 LEDs in the RRF- STM branch?
And does it also apply for a Duet2 where I could only use BitBanging mode?Nevertheless, the concept of having a second MCU (which takes over less timing critical tasks) can come handy for other FW-features as well.
Today I'll try the OTG USB port, see if it can feed the Arduino nano with power and data. -
@o_lampe said in Help creating NeoPixel LSD-language:
But then I'm asking myself, why there is a limitation of 60 LEDs in the RRF- STM branch?
And does it also apply for a Duet2 where I could only use BitBanging mode?I'd guess the limit is down to buffer size, and power consumption?
60 LEDs with a 32 bit value each is 240 bytes, plus four bytes each for start and stop codes, plus buffer pointers etc. so roughly 256 bytes RAM.And for a direct board connection, the 5V regulator has to feed the LEDs, which may be the more critical restriction.
That's for DotStar LEDs, which use SPI clock and data.
I went through the V3.3 firmware and they were the only LED option I could find; no mention of neopixels.If your board supports firmware 3.3, it should work via DMA regardless of the exact board type.
[That's for the "official" RRF branch - no idea what the STM32 capabilities are, or what connectivity the hardware designers have included]I'm not saying any one approach is "best", just going over possibilities to achieve the end result, and as a programmer it's an interesting idea!
-
@rjenkinsgb said in Help creating NeoPixel LSD-language:
the 5V regulator has to feed the LEDs,
The limit regarding current consumption is much lower than 60 LEDs. 8-10 LEDs with full brightness is max. (YMMV)
I'm sure it's related to SPI buffer size. So there is a limited resource worth to preserve for other tasks. -
I got some reaction from the Arduino, when using RX/TX @57600 Baud. But I'd need a levelshifter here, I guess.
Over USB, I got no feedback whatsoever. Tried different M575 settings.
Maybe have to rewrite the Arduino Code, but IIRC the serial port 0 is the same as USB? -
@rjenkinsgb
beside the Seeedstudio Xiao, I also found the DFRobot Firebeetle M0 which has a huge 12MB +16MB storage capacity and a small breadboard area. (for level shifters and power distribution?) The storage would be big enough for some Bitmaps or other animated NeoPixel stuff.
I would then only have to call the right animation, which I'll have predefined in flash.Not sure yet how to program it. Maybe the bootloader is specific for robotics-stuff?
-
@o_lampe
Nice!That works with the Arduino IDE again, you just need to add the appropriate DFRobot SDK file; the instructions & file link are in the Audio photo album project section.
-
@rjenkinsgb said in Help creating NeoPixel LSD-language:
Audio photo album project
RE audio: beside bitmaps and animations I could store some background music, too!
The sand table is pretty noisy with only 1 ball, but 4 ball-ballet definitly needs some sound.I read a comment about a broken arduino library link. I hope it's sorted out now...
-
@o_lampe said in Help creating NeoPixel LSD-language:
Not sure yet how to program it. Maybe the bootloader is specific for robotics-stuff?
Very nice find. I bookmarked it. For IDE I suggest to check platformio. They support many CPUs and platforms and provide an very functional and auto updatable development environment on top of VSCode.
https://docs.platformio.org/en/latest/platforms/atmelsam.html
-
@zapta
The DFRobot board isn't listed (yet) in PlatformIO. I'm not sure, if it would support the extra flash?
Furthermore, PlatformIO seems to work on Linux systems. That's not my favourite OS, especially when it's text-based. I hate to search the web for every config-line and almost have to beg for read/write permissions as normal user. -
For those who want to install the DFRobot firebeetle M0 files for Arduino IDE:
don't use the link provided in their Wiki!
Instead use this link
http://download.dfrobot.top/firebeetle/package_DFRobot_test_index.jsonThen open the boardmanager as usual and search for dfrobot. You will see several firebeetle packages, choose the M0 and your ready
-
LOL, all the example files have comments in chinese
I knew I'd have to learn it one day...There are many examples for fastLED- library, all about WS2812B strips
-
@o_lampe, platformio runs seamlessly on all three major platforms, and you can open the same project on each one of them with no modification.
As for DFRobot, a platform io library search suggests support https://platformio.org/lib/search?query=dfrobot
Also, you can add it yourself as described here or in your project tree. https://community.platformio.org/t/how-to-include-arduino-library-in-platformio/15146
Learning platformio is a great investment. Once you set it up (e.g. on VSCode), you would not go back to the Arduino IDE. I used it on Arduinos, Teensys and Pico. For the Pico for example, it support hardware debugging with another Pico acting as the debugger. There is also a great community around it.
My 2c.