I’m trying to use the @ Nicolas3’s lib (1) to drive WS281x RGB addressable LEDs (2) with a G400-D on .NETMF 4.3 + GHI Electronics NETMF SDK 2016 R1 Pre-Release 1.
These LEDs need strong timing respect to interpret logical 0 and 1 and the @ Nicolas3’s lib uses the SPI to generate the needed 0/1 timings:
[ul]A LED bit is generated using 4 SPI bits
2 LED bits are transmitted each SPI bytes
Each LED needs 3 bytes (RGB) to set the correct color, which gives 12 SPI bytes per LED.
Each of my LED matrix module has 64 LEDs ( 8 x 8 ) which gives 768 SPI bytes per matrix
I want to drive 4 chained LED matrices, which gives a total of 3072 SPI bytes[/ul]
Unfortunately, the G400-D SPI driver seems to treat SPI bytes buffer one by one or something like that because I see delay between each SPI bytes (see attached analyzer snapshot while transmitting 0xAA pattern).
[Edit] I’m using G400-D SPI2 @ 3200Kbps, no MISO, no CS, no SCK [/Edit]
So, here are my 1st questions:
[ul]Does someone experienced such [G400] SPI behavior?
Does someone try to drive WS281x LEDs with G400 SPI?
Does exist a solution or a workaround (RLP, …)?
If it’s not a correct behavior, does the next SDK update corrects it?[/ul]
Thank you ‘iamin’. Seems to be the same with G120…
I suppose that this inter-byte delay doesn’t exist on Cerberus (STM32) because the LEDs are correctly addressed in the https://www.ghielectronics.com/community/codeshare/entry/977 project. That is strange because STM CPUs are less powerful than G120 and G400…
Hi all,
I played with RLP on SPI because I was upset that a such powerful CPU like AT91SAM9X35 on G400 couldn’t deliver continuous bytes flow on the MOSI output…
Quick’n dirty RLP SPI implementation based on ATMEL code sourcery: SAM9X35 only, some hardcoded settings, no interrupt, no DMA, no read… :-[
But results are here ;D
Please take a look at the 2 pictures attached: one with the GHI SPI driver (delay between each bytes), the other with the RLP SPI implementation (continuous transmission). Brown signal SPI_CLK, red one is SPI_MOSI…
Works without any comparison on my NeoPixels 8x8 LED Matrix… but sometime I still have rarely artifacts due to time gap between bytes… Probably with Irq handling it will be better.
I am keen to try to work with the addressable LED strip based on ws2812b or ws2813 chip. I saw few comments here and there that due to the timing issues no any interpreter-based board, like netduino etc can handle this task. I have Fez Panda 2. Do you think I better go for LPD8806?
Yeah, but there I see the guy uses some tricks to make a buffer and tries to adjust the speed of the board with the acceptable speed of the Strip chip.
I am personally a fan of WS2813 as they’ve did this second data line which will be used in case one or more LEDs are out. But that chip has even stricter timings than WS2812B, so I am really afraid I won’t be able to use it.
Alternatively, I’ve looked into APA102 chip which looks like the WS2812 but with the CLOCK input which has to solve the problem.
So maybe I will go with APA102. There’s no any library for it so far, so I will need to struggle with data sheets, but all in all I believe it’s the same as working with LPD8806:
As far as I understand I need to wire the CLCK input of the Strip to Di13 and Data to Di11 and it will do the job.
What I found interesting and can’t explain so far that it looks like SPI handles the clock on its own. Why I say this, because all the projects for Arduino I saw have that manual send for the clocks and Netduino users are only sending the data to the strip.
One finding. There’s a guy who managed the issue with timing using custom firmware for his Netduino 2 plus. So he created a native function.
Hence the question:
RLP - can it help me here? Is it actually the same as guy did? So I assume Netduino doesn’t have anything like RLP that’s why he needed to put it into firmware. But FEZ Panda 2 has RLP support so I can write it with no “involvement” into the firmware, correct?
Also, the Netduino 2 plus looks like a faster board than Panda 2… would it be a problem?
It was a long time ago… So, RLP didn’t solve the problem even by managing the SPI TX interrupt.
But making attempts with a PIC32 OSLess I realized that by inverting the MOSI signal (and the lookup table) the results was perfect with the G400D with .NET directly or with RLP.
But, to avoid timing issues with managed platform or non real-time ones, my next choice will probably APA102 LED’s…
@ Olivier.ov - hi and thanks for your reply! G400D looks like the way faster chip than is used on my FEZ PANDA 2, so I am really getting disappointed and desperate now to try WS2813 even with RLP… Though I will buy a meter of it anyway and try it out.
My plan is to also get one strip of APA102 and check it out with regular .Net. Do you know if something like APA102 exists which also has the backup data line like WS2813? This feature is extremely demanded by my project.
![https://www.ghielectronics.com/uploads/forum/img/13013_SPI-G120_large.png[/url]](https://www.ghielectronics.com/uploads/forum/img/13013_SPI-G120_large.png%5B/url%5D){kind=link}