Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 18 19:15
    Makuna updated the wiki
  • Nov 11 19:00
    jbreizh opened #306
  • Nov 07 23:36
    Makuna closed #305
  • Nov 07 23:35
    Makuna updated the wiki
  • Nov 07 23:31
    Makuna updated the wiki
  • Nov 07 23:16
    Makuna labeled #305
  • Nov 07 22:38
    jbreizh opened #305
  • Nov 02 19:11
    Makuna labeled #303
  • Nov 02 19:11
    Makuna assigned #303
  • Nov 02 19:04
    Makuna closed #304
  • Nov 02 19:02
    Makuna opened #304
  • Nov 02 15:14
    siedi opened #303
  • Oct 27 21:01
    perigalacticon opened #302
  • Oct 27 16:09
    Makuna updated the wiki
  • Oct 16 06:31
    Makuna closed #174
  • Oct 16 06:29
    Makuna closed #297
  • Oct 16 06:29
    Makuna unlabeled #297
  • Oct 16 06:18
    Makuna closed #301
  • Oct 16 06:18
    Makuna opened #301
  • Oct 10 00:08
    Makuna closed #300
sticilface
@sticilface
ooo.... now that is interesting.... it won't work for my adalight implementation though... unless u can do it by serial1?
Shelby Merrick
@forkineye
yeah, its on serial1. uses GPIO2
sticilface
@sticilface
good work!
Shelby Merrick
@forkineye
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
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
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
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

@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
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
Looks good. i will have a look at your UART stuff in due course..
bbx10
@bbx10
@forkineye Your UART code is extremely promising! I will give it try ASAP.
Shelby Merrick
@forkineye
@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
@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
@bbx10 Sweet, thanks for testing it out!
sticilface
@sticilface
@forkineye it works... very well... good job.. took 5min to fit it into the neopixelbus lib!!
Shelby Merrick
@forkineye
@sticilface ah cool, great to hear! thanks!
sticilface
@sticilface
and no crashes with ping... and it works with data coming in via adalight on the other serial!
sticilface
@sticilface
the caveats being it works with 800mhz only, and 160mhz right?
Shelby Merrick
@forkineye
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
i'm driving 144 pixels just fine. 200 causes reboot! u reckon this is because its a 256 byte buffer.. = 85leds?
bbx10
@bbx10
@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
I was thinking how to implement the dithering thing.. i had and idea.... might be possible..
Shelby Merrick
@forkineye
@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
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
@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
Shelby Merrick
@forkineye
I didn't get a chance to work on it anymore this weekend. My plan this week is to move away from Serial1.write() stuff and setting up my own ring buffer to work directly with the UART's FIFO.
Shelby Merrick
@forkineye
@sticilface what other method were you referring to in regards to running 400 pixels? I'm hoping to be able to handle 680 pixels (4 DMX Universes) at a 25ms refresh rate.
sticilface
@sticilface
@forkineye I was referring to the bit banging method which worked for 400, with the break if it detects a wifi interrupt. The refresh rate would be much lower though as about 18/second fail. :point_up: August 23, 2015 12:08 PM
Shelby Merrick
@forkineye
@sticilface ah!! gotcha
sticilface
@sticilface
That was a big improvement though as usually I got a crash if i go over 200. with your UART method what is the time to send out 100 pixels?
Shelby Merrick
@forkineye
Should be right at 30us per pixel, so 3ms
with crashing at 400, was that with ping testing?
sticilface
@sticilface
no ping testing. so i guess that is 12ms for 400? The UART buffer probably fills, then the sketch yields and u get a wdt? As there is a UART buffer, could you do this async? Fill the buffer, loop the sketch fill it again? if the buffer is 256 bytes, 4 per pixel, 64 pixels total = 1.920 ms. so if you can loop round again and fill the buffer in under 1.92ms there will not be a gap? I'm not familiar with any of this so forgive me if I'm talking nonsense?
Shelby Merrick
@forkineye
The hardware buffer that the SDK talks about is 128 bytes. The 256 byte buffer exposed by the Arduino Serial object is a circular buffer within the class - https://github.com/esp8266/Arduino/blob/esp8266/hardware/esp8266com/esp8266/cores/esp8266/HardwareSerial.cpp#L612
It yields within the write, making sure the hardware buffer isn't overflowed. Looking at the code, it should be fine with a higher pixel count. I'll do some testing this evening and see what I can figure out.
sticilface
@sticilface
cool beans. cheers. What u reckon your back of the paper calculation is, as to how many you can drive with one ESP?
Shelby Merrick
@forkineye
in theory, should be only limited by the refresh rate you want
i need to keep mine to at least 40Hz / 25ms, so that works out to roughly 4 DMX universes / 680 pixels