These are chat archives for Makuna/NeoPixelBus

23rd
Aug 2015
sticilface
@sticilface
Aug 23 2015 11:08

so i upgraded to staging, with SDK 1.3, replaced the nointurrupts with the savedPS, and it is looking pretty good. adding the bail out using _getItrrCount(), returning an error code from show(), and then using that to resend the pixels works really well, it works for my ADAlights too.. I thought i'd measure how often it was failing.. using 100 LEDs, it was failing 1-6 every 10 seconds or so, but not very much... use ping -f and you can see the effect on failed sends...

Send_Fail: count = 9, average/s = 0 
Send_Fail: count = 1, average/s = 0 
Send_Fail: count = 5, average/s = 0 
Send_Fail: count = 5, average/s = 0 
Send_Fail: count = 16, average/s = 1 
Send_Fail: count = 3, average/s = 0 
Send_Fail: count = 15666, average/s = 1566 
Send_Fail: count = 38463, average/s = 3846 
Send_Fail: count = 36641, average/s = 3664 
Send_Fail: count = 34176, average/s = 3417 
Send_Fail: count = 37629, average/s = 3762 
Send_Fail: count = 37509, average/s = 3750 
Send_Fail: count = 8399, average/s = 839 
Send_Fail: count = 5, average/s = 0 
Send_Fail: count = 4, average/s = 0

but the LEDs... worked smoothly, and the ESP did not crash at all, and actually with the new SDK it returned even better than the 1.2 SDK... with only 0.1% packet loss...

83903 packets transmitted, 83821 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 0.407/9.387/76.581/6.335 ms

put this up to 400 LEDs...

LmacRxBlk:1
Send_Fail: count = 201, average/s = 20 
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
LmacRxBlk:1
Send_Fail: count = 189, average/s = 18

and its about 18 fails per second! but they still work...

Shelby Merrick
@forkineye
Aug 23 2015 11:36
i just got ws2811 working via UART. should be the end of interrupt issues!
hoping anyways. more testing to do, but looks good so far. implementing it now
sticilface
@sticilface
Aug 23 2015 11:47
ooo.... now that is interesting.... it won't work for my adalight implementation though... unless u can do it by serial1?
Shelby Merrick
@forkineye
Aug 23 2015 12:05
yeah, its on serial1. uses GPIO2
sticilface
@sticilface
Aug 23 2015 12:07
good work!
Shelby Merrick
@forkineye
Aug 23 2015 12:07
it uses the UART configured 6N1 and inverted at 3.2mbps. end up having to send 4 times the data to generate the waveform, but its only expanded when filling the FIFOs doesn't take a whole of memory
the stop and start bits become part of the 2811 signal
oh, and you want to do it at 160MHz, else it'll pause between frames sporadically for ~4us.
sticilface
@sticilface
Aug 23 2015 12:12
I'm running at 160 anyways, can't see the point in 80mhz. batteries are dead anyway at that speed with the wifi demands!
sticilface
@sticilface
Aug 23 2015 12:21
mine are actually all hooked up to GPIO 2 so i can do a field test. How easy would it be to encorporate into the neopixelbus lib?
Shelby Merrick
@forkineye
Aug 23 2015 12:35
should be fairly easy to add it. i'm doing it from scratch as i don't need animations and stuff
i need to support other clockless pixels like GECE as well, so trying to make it my framework for that
i'm trying to keep the function calls similar though so it can be ported in easier
sticilface
@sticilface
Aug 23 2015 14:01

@forkineye I've just tried out the microajax, and progmem methods you have for your web pages. I like it. Do you get a couple of second pause between each request when u load a page? for each of the page..1-2 sec.. microajax.js... 1-2 sec... style.css...1-2 sec...values...

occasionally i seem to get a crash as well... the stack dump pointed to 40101da4 <pvPortMalloc>:

i want to move my dynamic content over to ajax which is why I'm interested

Shelby Merrick
@forkineye
Aug 23 2015 14:39
the web stuff needs some work. any other traffic causes serious lag in the interface. the biggest issue is multiple requests. i'm going to redo it in the future so it doesn't ahve to load the css each time
err. mean w/ each page
i just pushed changes to my ESPixelStick using the UART for driving ws2811. Will have it testing throughout the day. branch with the code is here - https://github.com/forkineye/ESPixelStick/tree/ws2811_uart
sticilface
@sticilface
Aug 23 2015 15:26
Looks good. i will have a look at your UART stuff in due course..
bbx10
@bbx10
Aug 23 2015 18:29
@forkineye Your UART code is extremely promising! I will give it try ASAP.
Shelby Merrick
@forkineye
Aug 23 2015 18:38
@bbx10 it's been running for me the past couple of hours without any hiccups on 4 different modules. Only driving 40 pixels each though. Should be good for as many as you can throw at I'd think
my modules are actually outputting for 170 pixels each (1 full DMX universe), but only 40 pixels hooked up
bbx10
@bbx10
Aug 23 2015 20:08
@forkineye I modified a program to use your UART driver ESPixelUART.cpp. The program drives an 8x8 array at 30 fps. No problem so far with crashes. 20 minutes of "sudo ping -A <IP addr>" does not crash it. Using git commit aafacdc (Aug 16) to build the program so this is very close to the latest. I should have another 8x8 next week so can try 128 LEDs at once.
Shelby Merrick
@forkineye
Aug 23 2015 20:22
@bbx10 Sweet, thanks for testing it out!
sticilface
@sticilface
Aug 23 2015 20:44
@forkineye it works... very well... good job.. took 5min to fit it into the neopixelbus lib!!
Shelby Merrick
@forkineye
Aug 23 2015 20:48
@sticilface ah cool, great to hear! thanks!
sticilface
@sticilface
Aug 23 2015 21:16
and no crashes with ping... and it works with data coming in via adalight on the other serial!
sticilface
@sticilface
Aug 23 2015 21:27
the caveats being it works with 800mhz only, and 160mhz right?
Shelby Merrick
@forkineye
Aug 23 2015 21:31
it should work fine at 80 and 160. the sporadic delay I was seeing the UART frame shouldn't be long enough to trigger a reset state
i saw it pop up later on my scope in the 160 testing as well, but never notice it on my lights. that was with a 40hz (25ms) refresh rate
sticilface
@sticilface
Aug 23 2015 21:40
i'm driving 144 pixels just fine. 200 causes reboot! u reckon this is because its a 256 byte buffer.. = 85leds?
bbx10
@bbx10
Aug 23 2015 21:40
@sticilface I use the Huzzah board preset with CPU freq 160 MHz. No way to change the Flash freq and I am not sure what the default is.
@forkineye Trying different patterns. No problems. The program implements the Open Pixel Control protocol(same as Fadecandy) so I am running various Fadecandy demos. The program does not implement the fc advanced dithering and interpolation. It just receives pixel values via TCP then pushes the pixels to the LEDs.
sticilface
@sticilface
Aug 23 2015 21:45
I was thinking how to implement the dithering thing.. i had and idea.... might be possible..
Shelby Merrick
@forkineye
Aug 23 2015 21:57
@sticilface hmmmm... is that after you implemented into neopixelbus? each byte of color data takes up 4 bytes of the 256 byte buffer once its inserted so it's probably something else causing it
and it should yield until the buffer has room as well. how fast are you feeding it data?
@bbx10 that's similar to what i'm doing, but using E1.31 (DMX over Ethernet).
it just pumps out whatever channel data it receives
sticilface
@sticilface
Aug 23 2015 22:12
i actually got it to work up to 300, fell over at 400 though... thats fine.. i managed with the new SDK to run 400 using my other method! but 200 is plenty..
using the latest staging, the web server is printing out every request, despite DEBUG not being defined, in the web server... i can't seem to find where the output is coming from though!
sticilface
@sticilface
Aug 23 2015 22:38
@forkineye data feeding happens in one pass... it is from a buffer...
    char buff[4];
// https://github.com/forkineye/ESPixelStick ---  UART driven neopixels.... 
    do
    {
        uint8_t subpix = *p++;
        buff[0] = data[(subpix >> 6) & 3];
        buff[1] = data[(subpix >> 4) & 3];
        buff[2] = data[(subpix >> 2) & 3];
        buff[3] = data[subpix & 3];
        Serial1.write(buff, sizeof(buff));    
    } while (p < end);
I must say it is quite good. and the ESP is a lot more responsive to web requests, without disabling interrupts