F*ing ESP8266, I've had my doubts about it right from the start.

I built this to control the servos...

Using the multiprocessor serial networking. The TX of each is on a flylead that plugs into the RX of the next, and its broken out on the top left corner so I can connect the TX and RX of the UART.
Its powered by a 5V 2A supply, and the whole thing is paranoically well grounded and shielded to prevent any crosstalk.

Here the ESP is connected directly to the UART and has been programmed with multicore.ino:

const int host=1;
const int packlen=1;
unsigned char bytes;
int bootdelay;
void setup() {
  Serial.begin(115200);                           // open serial port
  while (!Serial) { ; }                           // wait for the port to be available
  if (host==1) { bootdelay=1000; } else { bootdelay=5000; }
  for (int d=0; d<bootdelay; d++) {               // garbage collect delay
    if (Serial.available() > 0) { unsigned char dummy=Serial.read(); }
    delay(1);
  }
  
} 
void loop() { 
  int val1;
  if (Serial.available() > 0) {                  // if there is a packet
    bytes=Serial.read();                          // read the packet
    val1=(int)bytes;
 
      Serial.write(bytes);                    // write packet
      
  }
}

Which has had everything stripped out so all it does is return what it is sent. It can be uploaded to the ESP and the Atmel without modification and should perform the same. On an Atmel, viewed from a simple port scanner and byte injector script:

Port not open
Clearing buffers...
Connected!
Starting input thread.
Send command byte
Byte : 1
00000001 - 01 - 1  
Send command byte
Byte : 2
00000010 - 02 - 2  
Send command byte
Byte : 3
00000011 - 03 - 3  
Send command byte
Byte : 255
11111111 - ff - 255 - �
Send command byte
Byte : 
Thread done!
Main done!

However, uploaded to an ESP (and I have now tried two, one from eBay and one that Ars sent me) it does this instead.

Send command byte
Byte : 3
00000011 - 03 - 3  
00000000 - 00 - 0  
00000000 - 00 - 0  
11111110 - fe - 254 - �
11111110 - fe - 254 - �
Send command byte
Byte : 3
00000011 - 03 - 3  
Send command byte
Byte : 3
00000011 - 03 - 3  
Send command byte
Byte : 4
10000010 - 82 - 130 - �
Send command byte
Byte : 1
11000000 - c0 - 192 - 
Send command byte
Byte : 1
11000000 - c0 - 192 - 
Send command byte
Byte : 2
00000010 - 02 - 2  
11111111 - ff - 255 - �
00000000 - 00 - 0  
00000000 - 00 - 0  
11111111 - ff - 255 - �
Send command byte
Byte : 00000000 - 00 - 0  
00000000 - 00 - 0  
11111100 - fc - 252 - 
11111110 - fe - 254 - �
11111110 - fe - 254 - �
11110000 - f0 - 240 - 
11111100 - fc - 252 - 
11111111 - ff - 255 - �
11110000 - f0 - 240 - 
11111110 - fe - 254 - �
11111010 - fa - 250 - 
11111111 - ff - 255 - �
11111111 - ff - 255 - �
00000000 - 00 - 0  
11100000 - e0 - 224 - 
10000000 - 80 - 128 - �
11000000 - c0 - 192 - 
11111000 - f8 - 248 - 

Of particular note is the last section. While I was sitting and puzzling over where all the spare bytes were coming from, an few more appeared at random. Then a few more, and more as I watched. Eventually it filled up the terminal over about 10 minutes in random bursts.

The Atmels dont do it using the same code on the same board, same power supply and connected to the same rig, so I really have no explanation other than I have two bad processors and I've wasted my time trying to get something broken to work. Its making up data on its own, no wonder I couldnt get anything meaningful out of perfectly good code - which I wrote blind I might add. Runs on the Atmels without modification, but I had to add garbage collection and checksumming just to get it to run with the ESP and now I know why.

I've built two motherboards, one using brand-new hardware, hacked a test rig with flyleads and Arduinos and a ESP programmer board I built, nothing worked, finally I strip it all back and watch it taking the piss...