These are chat archives for Makuna/NeoPixelBus

15th
Jan 2017
brutzler
@brutzler
Jan 15 2017 01:37
Here I am....
Michael Miller
@Makuna
Jan 15 2017 01:37
So you got it working?
brutzler
@brutzler
Jan 15 2017 01:38
Is this dependency to WiFi a problem too, if i use only one LED?
yes it works now
I only want to use a WS2812 instead of 1xRGB-LED (less wiring)
Michael Miller
@Makuna
Jan 15 2017 01:39
It can always be a problem, BUT with only one its less likely to happen. You can try by changing the method from
Neo800KbpsMethod to
NeoEsp8266BitBang800KbpsMethod
This method will use the PIN you pass.
other alternatives are
NeoEsp8266Uart800KbpsMethod or
NeoEsp8266AsyncUart800KbpsMethod (uses TXD1/GPIO2)
brutzler
@brutzler
Jan 15 2017 01:45
OK. I am only astonished, that I could use GPIO2 in the adafruit example. Here there was a using of NEO_KHZ800. Thought it is the same as your Neo800KbpsMethod
Michael Miller
@Makuna
Jan 15 2017 01:46
Neo800KbpsMethod on esp platforms defaults to
NeoEsp8266Dma800KbpsMethod
My library supports many methods to handle sending data, and by using the template model (the greater than less than) gives me great flexibility in the support without cost of extra code or memory to support all the alternatives.
BitBang (which is what Adafruit uses) really should be avoided. If in heavy WiFi traffic to and from the device; you will see glitches even with just a few pixels. There is no solution other than uses the hardware like I do with the DMA and Uart methods.
Michael Miller
@Makuna
Jan 15 2017 01:51
If you don't use WiFi, then bitbang should work fine. But using the hardware methods will free up more CPU for other things (tradeoffs).
brutzler
@brutzler
Jan 15 2017 01:51
OK. Lot of input atm.
In summary: You suggest a using of your Neo800KbpsMethod, in order not have any problems with active WiFi. But then I am forced to use GPIO3. Right?
Michael Miller
@Makuna
Jan 15 2017 01:52
Correct.
The next recommended is NeoEsp8266Uart800KbpsMethod or NeoEsp8266AsyncUart800KbpsMethod which will force to use GPIO2, giving you an alternative.
brutzler
@brutzler
Jan 15 2017 01:54
In what case to use 400Khz instead of 800Khz? lenght of wiring?
Michael Miller
@Makuna
Jan 15 2017 01:54
Older Pixels
brutzler
@brutzler
Jan 15 2017 01:54
I only have ~10cm
OK
Michael Miller
@Makuna
Jan 15 2017 01:54
First generation of pixels were slower protocol. Some where just chips and no actual LEDs, you added your own LEDs.
I have run wire upto several meters without much of a problem.
brutzler
@brutzler
Jan 15 2017 01:56
Using WiFi with bitbang methode:
WiFi causes problems on the LED. But LED can not disturb WiFi. Is this correct?
Michael Miller
@Makuna
Jan 15 2017 01:58
yes and no. Generally with small runs all you will see is colors are wrong. With more than a few, it can cause resets of the Esp. This is one of the issues with FastLED right now (he has an open issue that compared all the libraries together and the person posted uptime with each)
I think the person ran my library for a week without a single reset using the DMA method; but with BitBang it was the same as AdaFruits and reset at least once in 8 hours generally. Really not sure why FastLED reset within just a few hours consistently at the time.
Anymore urgent questions? Got to go start foraging for food ;-)
brutzler
@brutzler
Jan 15 2017 02:01
OK. only one final question:
As i told you, I only want to use one WS2812 instead of a RGB-LED. i want to show state of my WiFi-plug for 230VAC. For this WiFi is indispensable.
Does the use of WS2812 in that case make sense?
Michael Miller
@Makuna
Jan 15 2017 02:03
Sure. Its a great way to add multi-color status. It might be a little more costly when mass produced; but the WS2812 chips are getting cheap! the size of the chip really becomes the limiting factor.
brutzler
@brutzler
Jan 15 2017 02:04
I only think about probably restarts
With digitalwrite() I am sure to have no problems
Michael Miller
@Makuna
Jan 15 2017 02:06
With the default method; there should be no restarts. Its pretty solid code using the documented DMA hardware. No special blocking interrupts at all so it should not effect the WiFi or cause resets.
brutzler
@brutzler
Jan 15 2017 02:06
OK. thx for your great help. enjoy your meal. going to bed now. 3am ^^
Michael Miller
@Makuna
Jan 15 2017 02:06
I have had no reports of any resets with it.
cya
brutzler
@brutzler
Jan 15 2017 02:07
cu
brutzler
@brutzler
Jan 15 2017 02:12
this is not urgent. feel free to answer it when you have time:
const uint16_t PixelCount = 4; // this example assumes 4 pixels, making it smaller will cause a failure
I tried with "1" and working. What sort of failures do you mean?
brutzler
@brutzler
Jan 15 2017 02:23
Oh, stupid me. ...this EXAMPLE....
Should read more accurate....
brutzler
@brutzler
Jan 15 2017 17:33
Hi again... just thinking a bit of PIN-distribution for my "project"
Isn't taking the GPIO3 (RxD0) a problem when I use Serial? For only making debug messages serial interface uses TxD0 (GPIO1). But receiving from serial interface will be a problem, or?
Michael Miller
@Makuna
Jan 15 2017 17:39
Yes it will be. If you need the serial for other purposes than debug, then you can just call swap; like this...
  // use Serial for something else
  // move serial to GPIO15(TX) and GPIO13 (RX) 
  // we loose the debug monitor though
  Serial.begin(9600);
  Serial.swap();
  // now initialize the NeoPixelBus strip
  strip.Begin();
Without the above, you will retain the ability to send debug messages, but you will not be able to receive anything on the serial port. Further, you can use the alternate Uart method which leave the normal debug Serial fully available.
brutzler
@brutzler
Jan 15 2017 18:21
OK, you confirm my thoughts.
As yesterday mentioned: The UART-method is as stable with WiFi as the DMA-method. (And uses GPIO2)
But normally I do not need Serial input to the ESP. As long as Debug is working, all is fine. I only was afraid, if I initialize Serial and strip, already at this time there will be problems of double use GPIO3.
But even in your example you use both.
Michael Miller
@Makuna
Jan 15 2017 20:31
Just initialize the detail before the NeoPixelBus, otherwise it will take the pin back.