Adding a second strips of neo pixels?

gloomyandy

@o_lampe The board.txt mechanism is not really ideal, it is there mainly to avoid having to have multiple builds for boards that are basically very similar. Although it provides that flexibility it also adds a potential source of error that the Duet boards do not have (it is fairly common for folks to get the board.txt settings wrong).

In this case I'd say it is not the best solution. Rather something like an extension of the existing RRF mechanisms would be better, we already have ways to define a pin for something like a heater port or fan control, I would have thought this same system could be used to define an LED port. That way a user can simply use gcode to define the pin(s) to be used.

o_lampe

@gloomyandy @dc42
I agree that RRF3 has offered a new flexibility regarding pin/port definitions. The NeoPixel implementation doesn't allow that for the benefit of DMA, but the bit banging versions should allow "free" choice of pin(s).
And while we are talking about bit banging: why not implement a SW-SPI or SW-UART port?
There are so many things happening outside of the actual print-time, where we could use the MCU effectively instead of sitting idle.

zapta

@dc42 said in Adding a second strips of neo pixels?:

The other is intended for the 12864 display and is driven by bit banging

I set the colors every 10 secs in the daemon.g file. What are the implications of using a bit banging output with 25 neo pixels? Does it occupy the CPU 100% for the duration of the transmission? Will this interfere with normal printing?

(Most of my neo pixels updates are no change so I guess I could skip them using some global variable that keeps the last updated state but it's extra complexity and will not recover fast from update errors)

dc42

@zapta said in Adding a second strips of neo pixels?:

Does it occupy the CPU 100% for the duration of the transmission? Will this interfere with normal printing?

Yes and yes. That's why if you want to update both LED strings during a print, it would be better to use an external gate so that you can drive both strings from the DMA-driven channel. You will need a 74HCT02 IC and a spare IOx_OUT pin.

zapta

Thanks @dc42, I will stay with DMA only then.

What do you think about the topology here https://forum.duet3d.com/topic/26347/adding-a-second-strips-of-neo-pixels/2?_=1639426715611 ? Using three helper neo pixels near the duet to simulate a single 3 + 20 neo pixel string without using a daisy chain?

The neo pixel data output seems to drive 50ma so probably good enough to drive a ~150cm wire to the 20 neo pixels string. https://cdn-shop.adafruit.com/product-files/1138/SK6812+LED+datasheet+.pdf

dc42

@zapta how often will you change the colours on the strip of 3? If it's only occasionally then you could use the bit-bang channel for them.

zapta

@dc42 said in Adding a second strips of neo pixels?:

@zapta how often will you change the colours on the strip of 3? If it's only occasionally then you could use the bit-bang channel for them.

I update every 10 secs but the color actually changed when the printer changes state (printing, cooling, idle, etc) so very seldom if I will skip the no change updates.

dc42

@zapta in that case you should be good to use the bit bang channel for that. The main limitation of the bit bang channel is that if you use M150 on it, it will ask the movement system to come to a stop, then when it does it will halt the system for up to about 200us while it executes the command, then it will restart movement.

zapta

Thans @dc42 , I will give it a try. I presume I need to add a 5v level shifter for the secondary neopixel output I will use.

dc42

@zapta said in Adding a second strips of neo pixels?:

Thans @dc42 , I will give it a try. I presume I need to add a 5v level shifter for the secondary neopixel output I will use.

Yes, you will.