Pico and ESP8266

If it is going past the timeouts, I'd be happy to increase them where needed? There's no real issue with them being longer if everything is working fine :)

I'm not too convinced about adding an option to set the timeouts... I think if people have had an issue with the timeouts and have to google it and then figure out they need to increase a config parameter, something's gone horribly wrong :)

Thanks for the tip. I pulled the ESP8266 module as you suggested. Upping the timeouts made no difference, so I also pulled down the AT module and tried to replicate what I can do with Serial2 (so far list APs, connect to a network and get my IP address) using at.cmd... and it strikes me that it is not abiding by the passed timeout param since it seems to return directly?

My AT command returns are two lines. I always get the issued command on the first line then OK on the line below. With Serial2.write and the timeout I get both to console. With my attempts to use at.cmd I only get the first, and immediately?

Also, it always seems to be first line (the command) that is in the var getting evaluated for a match to "OK" in the Esp8266 module code.

I'm not the best at following callback logic so I could be barking up the wrong tree - anyone confirm or deny that the timeout param in at.cmd is effectual?

it strikes me that it is not abiding by the passed timeout param since it seems to return directly?

Not sure I understand? The function will return immediately, but the callback gets called when a string is received or the timeout elapses.

With my attempts to use at.cmd I only get the first, and immediately?

You need to call ATE0 on initialisation - which turns off ESP8266's echo. It's easier for the code and obviously faster too - as it's not having to parse out what it sent. The ESP8266 module should do that automatically?

EDIT: Note all of the following actually had no bearing on issue. In end reflashing to the same firmware appears to have sorted it.

@Gordon thanks for coming back on this thread, I'll try and explain what I mean. As I understand it the AT module wraps serial. So I've got two test functions now, one that is sending AT commands directly using Serial2 and another using the AT module.

The first function (Serial2) and some calls with commented returns is/are below.

Note the return on ATE0, but that's another story, though I'm starting to disagree :D

// Serial Tests
var serialTest = function(cmd, timeout) {
  var l = "";
  Serial2.setup(115200, { rx: A3, tx : A2 });
  Serial2.on('data', function(d) {l+=d;});
  Serial2.write(cmd + "\r\n");
  setTimeout(function() {console.log(l);}, timeout);
};

serialTest("ATE0", 1000); 
// ATE0
// no this fun

serialTest("AT+CIPMUX=1", 1000);
// AT+CIPMUX=1
// OK

serialTest("AT+CWMODE=1", 1000);
//AT+CWMODE=1
//no change

serialTest("AT+CWJAP=\"xFxxxS\",\"xxebxx­x\"", 1000);
//AT+CWJAP="xxxxxx","xxxxxx"
//OK

serialTest("AT+CIFSR", 1000);
//AT+CIFSR
//192.168.1.16

serialTest("AT+CWLAP", 5000);
//AT+CWLAP
//+CWLAP:(0,"",0)
//+CWLAP:(3,"Orxxxalign",-54)
//+CWLAP:(4,"BIOxxxAMD",-83)
//+CWLAP:(3,"CxxDUK",-52)
//+CWLAP:(0,"CDxxUK-GxxUEST",-52)
//+CWLAP:(4,"waxxdaroxxxWAP1xxx2ice",-64­)
//CWLAP:(4,"Laxxxxxp",-67)  
//etc

Trying to test the AT module command at.cmd i have the test function below plus the calls and commented returns. Always one line whatever timeout is set. Never anything else.

// AT Test
Serial2.setup(115200, { rx: A3, tx : A2 });
var at = require("AT").connect(Serial2);
var atTest = function(cmd, timeout) {
  at.cmd(cmd + "\r\n", timeout, function(d) {
    console.log(d);
  });
};

atTest("ATE0", 1000); 
// ATE0

atTest("ATE0", 10000); 
// ATE0

atTest("AT+CIPMUX=1", 1000);
//AT+CIPMUX=1

atTest("AT+CIPMUX=1", 10000);
//AT+CIPMUX=1

atTest("AT+CWMODE=1", 1000);
//AT+CWMODE=1

atTest("AT+CWMODE=1", 10000);
//AT+CWMODE=1

atTest("AT+CIFSR", 5000);
//AT+CIFSR

When I added a few logging statements in the ESP module I downloaded and have locally I could see that in all cases I tested d was being evaluated against something that in the serial function is on the second line, but using AT it actually contained the first/only line (the command) - i.e AT+CIPMUX=1 != OK

I doubt that has clarified things much, and it's fair to say I'm a bit out my depth here, so please tell me if I'm muddying the water ;) but I suppose the question I'm posing is why am I ok using Serial2 but not the AT module which wraps Serial. Is there an issue in there?

For my 2p worth I was seeing c. 5% timeouts until I upped the timeout value. It is overkill given I can easily miss a few sensor readings, but I am retrying all failing ESP connects and as a final fallback hard resetting the chip by pulling RST low

@Gordon, whatever I had above please ignore - I cannot reproduce on another Wifi network tonight. Beyond AT, AT+GMR, & AT+RST, nothing now works even with the serialTest function that I got results from earlier. Breadboard/hardware setup unchanged. :/

Hmm, strange.

Well, the no this is fun could be because there was garbage in the ESP8266's input buffer. Sending \r\n separately beforehand might help things? It seems amazingly strange that you're still getting echo back after calling it... Is there any chance RX and TX could actually be shorted??

I'd be careful when testing and setting up AT multiple times, as on('data',...) adds a new listener (and keeps existing ones). It could be messing things up for you?

Had you tried wifi.at.debug()? It should dump out exactly what's going on - although I've noticed that a bug in Espruino means that the debugging itself can cause the Serial data coming in to get corrupted when running at higher (eg 115200) baud rates :(

Also, just in case, could you maybe try a breadboard power supply to supply 3.3v to the ESP8266? It could still be some power issue I guess? I know people have reported issues with breadboards and ESP8266 (I think because of the power draw), so you could try soldering a capacitor right across the ESP8266's power pins?

@Moray which timeouts did you have to increase? I'm happy to tweak them up - I'd just rather not increase the ones where Espruino should always be getting an immediate response from the ESP8266.

Success. Cap was on ESP8266 already, but in a last ditch attempt I decided to reflash it, even though I had revision 0.25 it seems flashing it with the 0.25 bin on the ESP8266 page has resolved.

My serial and AT tests still behave as they did so they obviously have no bearing on the matter whatsoever, so I don't mind if you drop those posts, as I would not want to mislead others.

Is it possible for flash to be loaded improperly? Moral is - flash it - even if you think you have good firmware!

Don't think I've ever had to fight as hard for a hello world

|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
          |_| http://espruino.com
 1v81 Copyright 2015 G.Williams
>echo(0);
=undefined
Connecting to WiFi
Connected
Response:  {
  "headers": {
    "Date": "Fri, 23 Oct 2015 12:32:39 GMT",
    "Server": "Apache/2.2.14 (Ubuntu)",
    "Last-Modified": "Fri, 15 Nov 2013 15:42:26 GMT",
    "ETag": "\"c01036-d-4eb390b8a8d18\"",
    "Accept-Ranges": "bytes",
    "Content-Length": "13",
    "Vary": "Accept-Encoding",
    "Connection": "close",
    "Content-Type": "text/plain"
   },
  "httpVersion": "1.1",
  "statusCode": "200",
  "statusMessage": "OK"
 }
--->Hello World!
> 

Great!

I think the ESP8266 has some configuration settings it stores in flash, so I guess those could have been corrupted. Not good that the module came pre-installed with bad firmware though.

Also, I didn't think about this before, but you made your own module loader? I'm not sure if you're using the minified version of the modules or not, but I'd advise it. They'll be a bit faster and will use less memory.

@Gordon you mean the Go console I made? Yes that pulls the minified versions. It works really well from my use of it so far but I've not actually been using that in this process - there where too many variables as it was - so have upgraded Mac to El Capitain - now Chrome IDE working very well (lots of other stuff on my Mac now doesn't quite work at all or as it did, but hey ho)

Wow, great! Yes, I meant to Go console, but as you say it's probably less variables to use the Chrome IDE :)

Did you just update the OS on the old mac then? Sorry to hear it broke lots of other stuff :(

Yes, it's available for 10.6.8 upwards and its a free upgrade (they've seen the light).

I'm using the IDE for most stuff now it's functional for me. But the Go console was a good experiment that I'll come back to with some slightly different use cases in mind.

I'm trying to make Olimex's ESP8266 board (MOD-WIFI-ESP8266 Rev. A) work with the Pico. I'm using the 10 uF capacitor. I don't have a shim (and it doesn't fit Olimex's board anyways).

The firmware version test revealed "AT+GMR\r\r\n00160901\r\n\r\nOK\r\n" at 115200 Bd, so the firmware version seems to be 00160901. I hoped it would work out of the box, but it doesn't. The example crashes with the following error message:

>Uncaught ATE0 failed: no this fun
 at line 2 col 18

No this fun indeed. I figured that the best bet would be to update the firmware to one tested with Espruino, so I downloaded version 0.50.0.0.

With regards to the module documentation:

• Where it says "Connect to Espruino, copy and paste this code into the left-hand side, and disconnect" you might want to add that "disconnect" means to disconnect the WebIDE (and not disconnect the Pico from USB or the ESP from Pico)
  
• You might also want to add that Mac users first need to install pySerial as described here because otherwise the esptool will just crash with a cryptic error message
  
  

In order to put the the ESP into boot mode on the Olimex board, I actually had to solder: the GPIO0 solder jumper needs to be put into position 0 (more about this).

I successfully flashed the new firmware, soldered the jumper back to 1 and... nothing. Now the board doesn't respond anymore, also the firmware check program just returns 3 empty strings :(

What did I do wrong?

And what was I supposed to flash to where? The firmware zip files comes with many bin files, but the included readme is not clear. I flashed the boot_v1.4(b1).bin file to address 0 and the user1.2048.new.5.bin file to address 0x1000 - is that wrong?

I used the 0.25 on a ESP-01 that came with 0.18. And that was trivial, after I had to throw away the first broken one (it always failed sooner or later to write to the EEPROM). Now I got some - two - more with 0.40 version. What to do? Hope it complies with 0.25 or bump it up to 0.50. Because it was not very clear which files had to be place on it, so I down graded it to 0.25... and it works now most of the time. So give it a shot with 0.25. (I'm also interested in a bit more details about the 0.50 version.)

Did you flash two images or just one? And which ones? The firmware zip contains 5 bin files and it's not clear which ones to use and which addresses to flash them to.

For 0.25, afaik, only one file has to be flashed. I cannot exactly recall the source I got the 0.25 from, but it seemed to me to be just 1 file. Not so with 0.50 taken from the ESP8266 site, where it is a zip with many files.

Yes, afraid I'd use 0v25 - that's the version that's had the most testing done with Espruino and which seems reliable. It's just a single binary that flashes on and should just work out of the box.

I'll try and update the docs with your suggestions (and a note recommending the 0v25 over the 0v50).

Thanks gentlemen... after soldering the GPIO0 jumper back and forth about 50 times in 2 days trying to awaken the ESP8266 with the 0v50 firmware in all its variations, I tried the 0v25 version as you suggested. It's counter-intuitive but it worked immediately! Now I can finally turn off the solder station and write some JavaScript :)

...put SMT resistor over the solder bridge... and when you need reset, you just touch the chip side with a (bread board) grounded wire... I'm sure it is not the last time you'f flashed.