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.
@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.
@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
@sticilface ah!! gotcha
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?
Should be right at 30us per pixel, so 3ms
with crashing at 400, was that with ping testing?
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?
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.
cool beans. cheers. What u reckon your back of the paper calculation is, as to how many you can drive with one ESP?
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
little buffer of time in there of course
don't see why you couldn't do 8 at 50ms or 16 at 100ms
animations will start to get clunky though
of course!
That sounds good. I'll do some testing as well and report with some more details
It really sucks that the bit bang method isn't viable anymore. As I had a version in development that would update 3 "busses"/pins at the same time, so you could triple the number that could be updated.
@sticilface it sounds like you did the work to integrate the hardware serial version this into my library, is it at a point for sharing? My thought was to create a branch for it.
I had a thought for your triple bus method actually
sharing = more than happy... give me a few min, and I'll integrate it with a fresh fork..
which version should i pull against... the master or animator?
Probably call the branch "Fork In Eye" ;-)
I'm using the animator branch for quite a few things
haha
@sticilface Makuna/NeoPixelBus#20
:)
@sticilface Makuna/NeoPixelBus#21
@sticilface You asked a question I missed while I was out...
"what is the name given to this notation = [=] ( xyz) i've done a bit of googling but can't find it"
"what is the name given to this notation = [=] ( xyz) i've done a bit of googling but can't find it"
I believe the specific example you are given is a "lambda expression". Something new to C++ 11, which esp8266 uses, but not available to the AVR Arduino developers as they are still using a pretty old compiler.
I've been asking a lot while u've been away! Thank you for the name. I will google to learn!
I've made a branch of the master, and got it working with the demo. I've used #ifdef #ifndef #else so that the other stuff is not included... It works with the demo sketches. right this is my first pull / push request... so forgive me if i've foobar it
steps to a successful pull...
1) create a branch off the master and do your work there
mmm... i've made a local branch... made a fork on my github, push my changes there, and then made a pull request...
2) submit the changes in that branch to the origin (my repo) and the branch you want it continue in.
the destination branch maybe the master, but in this case I want to create a new branch for you to target.
Did you base the change off the amimator branch or the master?
just the master
interestingly i just tried this sketch #21 and it works just fine using the UART but not with bt banging
@sticilface Am I correct in that the uart version looses support for 400hz pixels?
:point_up: August 23, 2015 10:27 PM I asked about that, I guess theoretically it should work, but i have no pixels to test it
go ahead and make the change, just make sure it compiles if you set the define in the header. I will do the physical test afterwards and adjust from there. Othewise looks good.
@Makuna in regards to 400kHz WS2811, you should just be able to change the baud rate from 3.2mbps to 1.6mbps. I don't have any to test with though
right, i've had a go.. if i understood the 400 support correctly... it should work. compiles and still works
is interrupt disabling and bit-banging completely broken now? i have another protocol to implement and will have to resort to bit-banging. need to disable them for 790us
U'll probably be ok for that amount of time. But my testing showed its a probability thing...
Agreed, it's not guaranteed to work, heavy load and the likely hood of a reset goes up.