Ma, no wires!

I'm trying to figure out how to hook-up the IDE to the esp8266 via wifi. I did try it out using setConsole() and LoopbackA/B and that's very cool, but what I'm really looking for is something that always works. I.e., I want this to work through resets, reboots, even reflashing with a device that is 1000 miles away (or just in an inconvenient location up in the attic). I'm pretty convinced that I need to implement the server socket code in C and then hook that up as a console. Might the best way to do that be to add a device like USBSerial, e.g. WifiSerial? Or maybe hijack USBSerial? Thoughts?

Yes, I think that's the best way - ideally you could use the existing network abstraction layer (not socketserver, but network.h)?

I'd been thinking Telnet as the name, but yes you could just hijack USB - it's what I do for Linux. You might find that what I did with libs/bluetooth helps a lot as it's doing almost the same thing?

Whatever it does it'd be great to expose it in a way that could be used in other devices (like WIZnet - ESP8266 AT commands might have trouble since they use JS). As a start, you probably want to develop under Linux anyway because it's so much faster to compile/test/debug :)

Also: realistically you need at least an option to have a password. When the password is entered, I'd look in execinfo.root for a variable like PASSWORD, and check against that. That way, if you have code then there's a password, but if you just reset everything then you can log in fine - but it's not dependent on Espruino being in any working state.

So... I have the console over Wifi almost working. It's working, but there is a deadlock. What happens is that jshTransmit assumes that the device TX happens via interrupts and not via idle loop polling. When the TX buffer is full, it busy-waits: https://github.com/espruino/Espruino/blob/master/src/jsdevices.c#L119-L125. But the network is not interrupt driven, it requires the idle-loop calls. Thoughts?

Well, a couple of hacks later and I have something working, although the buffering is not really satisfying at all. I should move it into a JS flat string, but even then it's just waiting to overflow or to hit the out-of-memory wall.

Code is here https://github.com/tve/Espruino/commit/8e480637e095f6fac0ee92f84eb67527ac24f4fa and in the prior commit (jsdevices.c).

If anyone wants to try it out:

• Use firmware http://s3.voneicken.com/espruino/espruino_1v84.tve_master_8e48063_esp8266.tgz
  
• After it connects to an access point, enable the telnet server: require("Telnet").setOptions({mode:"on"});
  
• Then pull-up the IDE and connect to port 23 of your esp8266
  
  

The console also works with the Linux build, but uses port 2323 (to avoid needing root privs). But you have to build that from sources yourself.

I now need to work on the "always available" part so it comes up automatically whenever there's a Wifi connection (if so configured).

BTW, Gordon, do you have an esp8266 to try these types of things out?

Ma, no wires! Espruino firmware update over Wifi followed by IDE connection over wifi. No serial anywhere in sight! A dream coming true!

Build: https://s3.amazonaws.com/s3.voneicken.com/espruino/espruino_1v84.tve_master_4bf01bf_esp8266.tgz

Use wiflash to update firmware, connect to port 23 using the IDE. Yeah, you need to previously have configured the Wifi to auto-connect to your Ap and preferably set a DHCP hostname so you don't have to remember the IP address. Lots of details to work out!

Warning: this is all still pretty hacky and unconfigurable and I'm sure Gordon will point out a zillion issues :-). But... we're getting there!

Oh, forgot to mention: the uart1 debug also is also available over Wifi, or at least the last 1KB is:

>require("ESP8266").printLog()
 29487> net_esp8266: resolving h.voneicken.com
 29491> net_esp8266: connecting socket 4 to 192.168.0.3:4567
 29494> net_esp8266: socket 4 connected
 29505> net_esp8266: socket 4 disconnected
 29505> net_esp8266: freeing espconn 0x3fff8a38/0x3fff8b50 for socket 4
 29514> net_esp8266: socket 4 close acknowledged
 29514> net_esp8266: freeing socket 4
 29525> net_esp8266: resolving h.voneicken.com
 29541> net_esp8266: connecting socket 5 to 192.168.0.3:4567
 29548> net_esp8266: socket 5 connected
 29572> net_esp8266: socket 5 disconnected
 29572> net_esp8266: freeing espconn 0x3fff8a38/0x3fff8b50 for socket 5
 29592> net_esp8266: socket 5 close acknowledged
 29592> net_esp8266: freeing socket 5
 29607> net_esp8266: resolving h.voneicken.com
 29616> net_esp8266: connecting socket 6 to 192.168.0.3:4567
 29623> net_esp8266: socket 6 connected
 29644> net_esp8266: socket 6 disconnected
 29644> net_esp8266: freeing espconn 0x3fff8a38/0x3fff8b50 for socket 6
 29652> net_esp8266: socket 6 close acknowledged
 29653> net_esp8266: freeing socket 6
=undefined

There's also a readLog() function that returns one line at the time from the log and can be used in some JS to ship the log off. I'm hoping to add something to do that more built-in... Not sure whether I should spring for syslog or simply send raw text packets that one can receive using nc.

Sexy sexy! That is awesome!

@tve: no wires, what about the very first time after unboxing the ESP ?

Yes, I've got some ESP8266's kicking around. I'm still waiting for a NodeMCU clone to arrive, but I've got some ESP01s.

The whole data transmit thing is a pain - I guess even though the ESP8266's API is asynchronous, it won't ever actually transmit anything until you go back to idle, so you have the same problem.

Does what you've got there actually help? It might be better to just increase the IO buffer size to 256, and to have a #define that says 'this build only transmits character data on idle, so always drop characters if the buffer gets full rather than blocking'.

It's actually an issue on other platforms too, so it'd be good to find a nice way around it. On the Nordic one it only transmits on idle too - although for that, just calling USARTKick while it busy-waits for the queue to empty could be an option.