ESP8266 Community Forum

- Mon May 04, 2015 2:54 pm #16492

It probably depends on whether the code which is executed is already in the instruction cache or must be fetched from the flash memory.

Ah hah! Thanks for that.

After I posted that last message, I started getting totally random results on the first led again. However, after adding the ICACHE_FLASH_ATTR to the timing critical method things started working again... mostly.

I still find it odd that it's only the very first led that shows an issue.

- Mon May 04, 2015 8:36 pm #16512 I just looked at the ws2812 data and now I am jealous, the shortest time period required can be 200-500nS .. fits in nicely with the 380nS that is easy to get and far easier than the 200nS I am trying to reach.

So in case anyone else searches for LPD1886 information, I officially give up on getting a standard GPIO pulse down to sub 280nS to be able to use this string directly on the esp and move on with other devices. Easier to get ws2812 instead.

Its interesting how a slower arduino nano can drive this string directly but the esp cannot, simply due to needing multiple instructions for a port write, it appears to swap from high to low the port needs different pull high or pull low drivers + the actual port data changed.

- Mon May 04, 2015 11:17 pm #16519

It probably depends on whether the code which is executed is already in the instruction cache or must be fetched from the flash memory.

Ah hah! Thanks for that.

After I posted that last message, I started getting totally random results on the first led again. However, after adding the ICACHE_FLASH_ATTR to the timing critical method things started working again... mostly.

I still find it odd that it's only the very first led that shows an issue.

I actually found no difference using or not using it. I would still get an error on the first Sometimes. But when I placed a set pin low, it became consistent.

- Tue May 05, 2015 3:27 am #16525 Yes, there are all kind of tricks necessary I also have this in my code.