Re: GPIO Latency differences 0.93 to V1

2015-04-23T11:56:42+08:00

SOLVED!!!!

When I included the code in the library I had automatically added ICACHE_FLASH_ATTR to the function declaration. As per a post on this forum - this causes contention as the cpu tries to grab the code from the flash ram. I removed the ICACHE_FLASH_ATTR so that the code is stored completed in RAM and it works now!

Statistics: Posted by sgoggin — Thu Apr 23, 2015 11:56 am

Re: GPIO Latency differences 0.93 to V1

2015-04-23T09:59:30+08:00

..

So If I put the same code directly into user_main.c - it works fine. If I put it into a library called ws2812.c/h then when it's called there is a delay introduced periodically - approx every 150msec, which if data is being sent throws the timing off of that data..

Why would putting the code in a library make a difference?

Statistics: Posted by sgoggin — Thu Apr 23, 2015 9:59 am

GPIO Latency differences 0.93 to V1

2015-04-22T20:33:34+08:00

Hello all,

I could use some suggestions on things to look at - spent several hours trying to make this work - but not having much luck.
Although I have now isolated this issue to be only occuring on ESP8266_SDK_v100150320 it does not reproduce on ESP8266_SDK_v093141121

I have a piece of code that toggles a GPIO port to drive a ws2812 LED chain. The code that drives this is fairly simple and looks like this

Code:

for( i = 0; i < MAX_LEDCHAIN; i++ )
   {
      byte = LEDArray.ws2812array[i];
            
      if( byte & 0x80 ) SEND_WS_1(); else SEND_WS_0();
      if( byte & 0x40 ) SEND_WS_1(); else SEND_WS_0();
      if( byte & 0x20 ) SEND_WS_1(); else SEND_WS_0();
      if( byte & 0x10 ) SEND_WS_1(); else SEND_WS_0();
      if( byte & 0x08 ) SEND_WS_1(); else SEND_WS_0();
      if( byte & 0x04 ) SEND_WS_1(); else SEND_WS_0();
      if( byte & 0x02 ) SEND_WS_1(); else SEND_WS_0();
      if( byte & 0x01 ) SEND_WS_1(); else SEND_WS_0();
    
   }

The SEND_WS_0 and SEND_WS_1 functions look like this.

Code:

#define Set13_1 GPIO_REG_WRITE(GPIO_OUT_W1TS_ADDRESS,BIT13); GPIO_REG_WRITE(GPIO_ENABLE_W1TS_ADDRESS,BIT13); 
#define Set13_0 GPIO_REG_WRITE(GPIO_OUT_W1TC_ADDRESS,BIT13);
#define init_13_GPIO PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTCK_U, FUNC_GPIO13);


void ICACHE_FLASH_ATTR SEND_WS_0()
{
   
   uint8_t time =0;
   
   time=2;
   while (time--)
   {
      Set13_1;
   }
   
   time=8;
   while(time--)
   {
      Set13_0;
   }

}

void ICACHE_FLASH_ATTR SEND_WS_1()
{
   uint8_t time;
   
   
   time=4;
   while(time--)
   {
      Set13_1;
   }
   time = 7;
   while(time--)
   {
      Set13_0;
   }

}

The problem I am getting is that the first few iterations of the loop, the timing is significantly delayed in some sort of wierd pattern, ie if I do 10 samples I get the same waveform (see below), but after the first few bytes the timing tightens up after about 10 loops. In fact the timing is perfect over perhaps 120 LED's - approx 300 iterations. But always the first LED get's corrupted.

The rest of the code set's up the ESP8266 in STATION_MODE, and connects to the network. The code also periodically sends a UDP packet to another local network device and a TCP packet to thingspeak with the captured data.

Here is an example of what I mean:

Statistics: Posted by sgoggin — Wed Apr 22, 2015 8:33 pm

ESP8266 Developer Zone

Re: GPIO Latency differences 0.93 to V1

Re: GPIO Latency differences 0.93 to V1

GPIO Latency differences 0.93 to V1