ESP8266 Community Forum

- Sat May 02, 2015 4:21 pm #16317 I found a more accurate way of bit banging the signal out than what was originally found and used.

I have updated my library with the new code.

By using the rsr.ccount, you can use the number of cycles that have passed as a means to time it, similar to the original NeoPixelLibrary implementation for Arm.

I still think there is yet another problem, as I see glitches once in a while, which I suspect is that the nointerrupts really isn't stopping all interrupts. I am investigating this still.

NOTE: Running the NeoPixels at 5v and having the IO at 3.3v is not within spec of the NeoPixels (ws2812). The IO must be within +/-0.5v of vcc. This issue was causing a TON of glitches but generally functioned (right pixels, wrong colors).

- Sun May 03, 2015 11:59 pm #16419

Btw, was there a reason you removed the brightness feature? I actually really liked that and it was one of the things I was going to reimplement. I'll end up adding it back to your library, but you don't need to merge it in of course.

1) This "feature" causes errors in the get pixel color as it "changes" the pixel color inplace and can cause round offs. In other words, due to a dim set, a get will return a different color. I felt this was flawed implementation.

2) Further, all it did was walk all the pixels and dim the colors. This can be done by an external routine with more transparency in the cost of the call to dim without causing inadvertent color changes unless you desire that.

3)The feature seemed like a higher level helper routine and not something that should be tied to so low level of code. You may want to dim just a particle set (as some pixels represent one object and other pixels represent another object) and it wouldn't help.

All these added up to removing the feature as it was original coded. But you can easily replace the basic feature, see #2.

Good points. I'll just implement a brightness routine in my app code.

- Mon May 04, 2015 12:46 am #16422 I am using the arduino build environment currently and I only have an 01 module atm, so only GPIO 0 and 2 available.
I also have LPD1886 led strip, specs say Tout must be <280nS, ideally 200nS.
Last night I tried toggling a pin high and low as quickly as possible within a loop with a straight ..

this is a low bit to the leds..
digitalWrite(LED, 1);
digitalWrite(LED, 0);
digitalWrite(LED, 0);
digitalWrite(LED, 0);

and this is a high bit..
digitalWrite(LED, 1);
digitalWrite(LED, 1);
digitalWrite(LED, 1);
digitalWrite(LED, 0);


and it ends up with a 336nS pulse (for the low) according to my CRO.
So I looked into a straight in line assembly routine to generate GPIO pulses but its beyond me still ..
I have the same LEDs working fine on a PIC using an SPI port .. output 0x02 for low and 0xfe for high.

- Mon May 04, 2015 2:34 am #16432 interesting,

well the system API is no help here.
by including..

// Include API-Headers
extern "C" {
#include "ets_sys.h"
#include "os_type.h"
#include "osapi.h"
#include "mem.h"
#include "user_interface.h"
#include "cont.h"
#include "gpio.h"
}

and using the system API to toggle the pins..

gpio_output_set(BIT2, 0, BIT2, 0);
gpio_output_set(0, BIT2, BIT2, 0);
gpio_output_set(0, BIT2, BIT2, 0);
gpio_output_set(0, BIT2, BIT2, 0);

I now have a 664nS pulse..

also tried ..

GPIO_OUTPUT_SET(BIT2, 1);
GPIO_OUTPUT_SET(BIT2, 0);
GPIO_OUTPUT_SET(BIT2, 0);
GPIO_OUTPUT_SET(BIT2, 0);

yet to get it to work, output stays low.