In particular log/text seems to get cached
look into using etag headers?

I am using release 1.0.1 on an ESP-03, using 512K flash

I have esp-link working beautifully on my esp-03 connected to an arduino UNO. I can upload 32K sketches via wifi with 100% success.

My problem is when I try to make outbound TCP connections from the arduino, I get no response from the esp. I can see the commands coming in from the uC serial port when I look at the Http viewer, and if I connect to port 23 with a terminal viewer, I see the commands on the serial link but esp-link is not responding at all - the command is treated like regular I/O

I am trying this command:

[email protected]:80
~100GET /asciilogo.txt\r\n\r\n\0

I am sending a \n after each line.

What am I doing wrong?

Build fails when trying to build with mingw under windows. I replaced the espfs directory with the one here and got it to build but that of course removes anything you've modified.

In the Makefile around line 286 wget for yui-compressor line needed skip cert check and output file defined:

cd yui; wget --no-check-certificate https://github.com/yui/yuicompressor/releases/download/v2.4.8/$(YUI-COMPRESSOR) -O $(YUI-COMPRESSOR)

I also needed to make sure the path is set for java bin, python, and git bin. This will also cause a build error if anything on the path is in "Program Files (x86)". I added symbolic links in my c:\espressif folder to these locations to resolve this issue.

Here's my resulting espmake.cmd that I call from visual studio.

@echo off

REM remove automatic created obj folder
rd obj /S /Q >nul 2>&1

PATH=%PATH%;C:\Espressif\xtensa-lx106-elf\bin;C:\MinGW\bin;C:\MinGW\msys\1.0\bin;C:\espressif\git-bin;C:\espressif\java-bin;C:\Python27
make -f Makefile %1 %2 %3 %4 %5

And visual studio NMake properties I have:

Preprocessor Definitions: ESP8266;__MINGW32__;__WIN32__
Include Search Path: .\serial;.\user;.\espfs;.\httpd;.\include;c:\tools\sming\Sming\system\include;c:\tools\sming\Sming\Libraries;c:\tools\sming\Sming;c:\tools\mingw64\x86_64-w64-mingw32\include\c++\x86_64-w64-mingw32;c:\tools\mingw64\x86_64-w64-mingw32\include\c++\backward;c:\tools\mingw64\x86_64-w64-mingw32\include\c++;c:\tools\mingw64\x86_64-w64-mingw32\include;c:\tools\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.3\include-fixed;c:\tools\mingw64\lib\gcc\x86_64-w64-mingw32\4.8.3\include;c:\Espressif\sdk\include

Introduction

Due to the way avrdude is programmed and some MCU bootloader quirks, you sometimes need a lot of luck to successfully program the MCU over the air.

The intention of the algorithm below is to solve these issues by introducing more intelligence in esp-link. It is the result of a lot of experimenting and analysing bootloader/avrdude source code but it's very well possible I still missed some quirks at this moment :-).

Below I try to describe the algorithm in words. I'm also busy implementing this algorithm as a small proof-of-concept network proxy that sits between the programmer (avrdude) and esplink. Since I found another quirk yesterday evening, my current code does not yet completely implement the description below. Once it does, I'll share it here also. In order to get quick results, it is implemented in perl. I'm also trying to make it easier to port to esp-link by using a similar 'API' like the esp-sdk provides (afaik). It should run on both linux and windows (with e.g. ActiveState perl).

Used Terminology:

MCU = microcontroller that speaks STK500 protocol
esplink = esp module with esp-link
avrdude = client pc which runs the programming tool (e.g. avrdude)

General principle:

During the synchronisation phase of the STK500 protocol, esplink itself talks to both MCU and avrdude. Once esplink synchronisation is established with both MCU and avrdude, esplink merely performs a bridging function between avrdude and the MCU.

Algorithm:

Once avrdude establishes a connection on port 2323 of esplink, esplink resets the MCU and starts to send STK_GET_SYNC;CRC_EOP (0x30;0x20) to the MCU at regular intervals (e.g. 50ms). There are now 2 possible events that can happen:

1. Client activity
   Client will send STK_GET_SYNC;CRC_EOP (0x30;0x20). If the client does not get a reply, it will retry sending this sequence until it gets a STK_INSYNC;STK_OK (0x14;0x10) reply. Due to the (naive) way avrdude is programmed, we need to ignore incoming STK_GET_SYNC;CRC_EOP sequence two times (see *1).
   From third time esplink receives STK_GET_SYNC;CRC_EOP, esplink replies to each sequence with STK_INSYNC;STK_OK (0x14;0x10).
   Once esplink receives a different sequence, communication with avrdude has reached a point where we can pass the received data unmodified to the MCU (AVRDUDE_READY state). So: if the MCU is already in sync (MCU_READY state), we send the received data (and all future data) directly to the MCU. If the MCU is not yet in sync, we wait until MCU is synced.
2. MCU serial reply
   The only thing the MCU should send is STK_INSYNC;STK_OK (0x14;0x10). This means the MCU is in programming mode and is awaiting further STK500 commands (MCU_READY state).
   Depending on the used bootloader, if the MCU does not receive a command in time (within 1 second for optiboot, maybe less for other bootloaders), it will reboot and leave programming mode. Therefore, if we reach MCU_READY state, esplink should have a watchdog timer firing every 0.5s. If the watchdog expires and the avrdude communication has not yet reached AVRDUDE_READY state (see *2), esplink should change MCU_ state, resend STK_GET_SYNC;CRC_EOP (0x30;0x20) and wait for the STK_INSYNC;STK_OK (0x14;0x10) answer. Once we received the answer, we switch back to MCU_READY state for 0.5 seconds.
   If in the meantime avrdude communication reached AVRDUDE_READY state, we send the received avrdude data (and all future data) directly to the MCU. All further incoming MCU communication can be directly passed to avrdude. The watchdogtimer can be stopped now.

Remarks

1: avrdude sends STK_GET_SYNC;CRC_EOP twice and ignores the reply deliberately. See stk500_getsync function in http://svn.savannah.nongnu.org/viewvc/trunk/avrdude/stk500.c?revision=1321. On windows, the stk500_drain function does not behave well and this causes a timing issue where the incoming response channel is not cleared properly. So if esplink behaves correctly and replies to every STK_GET_SYNC;CRC_EOP, there is a realistic chance (it happened to me) avrdude sees too much replies STK_INSYNC;STK_OK (0x14;0x10) and we get protocol errors due to the unexpected input. In an ideal world, avrdude code should be fixed to properly handle 'net:' ports and not treat it like a serial port.

2: Yup.. happened to me also... Seems I'm attracting timing issues :-)

Hi!

first of all thanks for esp-link! it's awsome! you did a great job!

I've got some questions:
I'd like to connect to a TCP server. All esp-link setup was ok! I used NodeMcu to flash the esp module with boot_v1.4(b1).bin (0x00000) , blank.bin (0x7E000) , user1.bin (0x01000). I set esp 01 avr mode, get the IP address and everything looks working fine. But, before connecting arduino and esp8266, when i check µc Console i get few characters (most of them are unreadable chars) printed every 20-30 seconds. Why? They apparently don't have any sequence. They just look like random printed chars. Shouldn't the µc console be empty when not connected to any microcontroller?

Then, when i connect Tx and Rx pins to Arduino the µc Console automatically starts printing huge amount of unreadable chars also if i don't print anything from arduino serial. What am I doing wrong ?

I tried to connect to my TCP server and i still get huge amount of unreadable chars. The same with the examples you provided.

After power-cycled esp8266 when i check µc Console huge amount of unreadable chars are printed also if not connected to arduino. Any idea?

I also tried to flash again esp8266 but nothing changed.

It would be very helpful if you can provide more detailed examples with arduino-side code.

Thanks a lot for any advice!!

Michael

Hi, thanks for the great software. Would it be possible/realistic to have an option to enable hardware flow control for the serial connection? Or would it interfere with the network side of things? I might look in to it myself if It is at all possible.

TVE
Your ESP-link is also useful to add an easy wifi connection for Arduino Uno using SWserial.
The problem is the max allowed baud rate is 38400.
Now i'm using https://www.pjrc.com/teensy/td_libs_AltSoftSerial.html but there is limitation.

Please could you add the option to choose baud rates lower than 57600 like 38400 and 19200.
I have understood that a low baud rate (e.g. 9600) is not allowed due to the TCP tasks that cannot be stopped.

Could you add a menu to change the connection port, not only 23?
The telnet port 23 can be blocked by routers and gateways in some networks (e.g. a corporate network...)

Thank you
Best Regards
Gio

The whole "STA+AP" mode is pretty fragile, I'm continuing to discover. For example:

• power up esp in new location, comes up in STA+AP on ch1
• connect to its AP, configure desired network SSID/PW
• turns out that AP is on ch6
• to connect to this AP the esp's AP has to switch to ch6 too
• the device used to configure the desired network gets disconnected due to channel change
• as a result, the user never sees the outcome of the network change[/list]

Not sure how to "fix" this without lots of logic that becomes fragile and difficult to test. May have to just live with the fact that the user will have to manually reconnect to the esp's AP if things didn't work correctly.

I find it helpful to be aware of the wifi channel numbers being used as I have some networks using the same SSID with different channel numbers in adjacent areas.

Do we have/need a mechanism to connect to hidden wifi networks?

Switch the uart0 to the MT pins (see http://www.esp8266.com/wiki/doku.php?id=esp8266_gpio_pin_allocations) in order to avoid ROM start-up gibberish from being sent to the attached MCU. This is important when using the ESP as a pass-through radio from the attached MCU and putting the ESP into deep-sleep to save power. Less important when using the ESP temporarily to debug an attached MCU.

Allow a static IP address to be configured.

Replaces #11 item 7

Hi

I grabbed the version of this code to run on ESP-01 units... it works - I can set up a port and talk to it. I grabbed a commercial package to map a port to a COM port on my PC - and checked - bidirectional communications over the real port to the virtual port - no problem - at 115k. but when I tried to use this to program an ESP12 remotely - no joy. Most of the time, my Eclipse setup - which programs boards no problem every day using an FTDI, would not have it (I booted the ESP12 up with GPIO0 grounded as usual). Could it be that the unit is running out of buffer RAM?

I'm trying to send the sketch to atmega8 with optiboot.
Source of otpiboot: https://code.google.com/p/optiboot/downloads/list (optiboot-v5.0a.zip )
uC is 8MHz (internal quartz).
Sketch is basic blink sketch from arduino ide (link to file : https://www.dropbox.com/s/xreb6mdbw6w3rnh/blink.hex?dl=0).
Card is ESP-01 (512kb) flashed with esp-link 1.0.4. Pin assignment : esp-01(AVR).

I've switched the baudrate to 9600 with command: http://192.168.2.107/console/baud?rate=9600

Scheme:

I try to upload the sketch from UBUNTU with command

petre@LinuxPC:~/arduino/arduino-1.6.5-r5$ hardware/tools/avr/bin/avrdude -C hardware/tools    /avr/etc/avrdude.conf -DV -patmega8 -Pnet:192.168.2.107:23 -carduino -b9600 -U flash:w:blink.hex:i -v -v -v

avrdude: Version 6.0.1, compiled on Apr 14 2015 at 18:03:40
     Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
     Copyright (c) 2007-2009 Joerg Wunsch

     System wide configuration file is "hardware/tools/avr/etc/avrdude.conf"
     User configuration file is "/home/petre/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : net:192.168.2.107:23
     Using Programmer              : arduino
     Overriding Baud Rate          : 9600
ioctl("TIOCMGET"): Inappropriate ioctl for device
ioctl("TIOCMGET"): Inappropriate ioctl for device
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xff
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xff
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xff
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xe7
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xfd
ioctl("TIOCMGET"): Inappropriate ioctl for device

avrdude done.  Thank you.

If I change the baudrate to 115200 the result is:

petre@LinuxPC:~/arduino/arduino-1.6.5-r5$ hardware/tools/avr/bin/avrdude -C hardware/tools/avr/etc/avrdude.conf -DV -patmega8 -Pnet:192.168.2.107:23 -carduino -b115200 -U flash:w:blink.hex:i -v -v -v

avrdude: Version 6.0.1, compiled on Apr 14 2015 at 18:03:40
     Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
     Copyright (c) 2007-2009 Joerg Wunsch

     System wide configuration file is "hardware/tools/avr/etc/avrdude.conf"
     User configuration file is "/home/petre/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : net:192.168.2.107:23
     Using Programmer              : arduino
     Overriding Baud Rate          : 115200
ioctl("TIOCMGET"): Inappropriate ioctl for device
ioctl("TIOCMGET"): Inappropriate ioctl for device
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x41
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x54
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x2b
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x43
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x49
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x50
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x4d
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x55
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x58
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3d
ioctl("TIOCMGET"): Inappropriate ioctl for device

avrdude done.  Thank you.

The uC resets on start (after ioctl("TIOCMGET"): Inappropriate ioctl for device) and second reset is after ioctl("TIOCMGET"): Inappropriate ioctl for device.

I've connected Esp TX to uC RX directly too but without changes.

It would be good to have an adjustable baud rate for the mcu. Some microcontrollers require different bauds to reprogram, ie the arduino pro minis I'm using only accept new sketches at 57600.

Also, because my arduino is 5v I'm using an npn transistor to switch the arduino's reset. This seemed safer to do than wiring the esp's 3v gpio directly to the arduino's 5v reset pin. But to do this I had to invert all the GPIO_OUTPUT_SET(mcu_reset_pin, X) calls in serbridge.c.

Having these settings user adjustable could be very handy.

Anyway, now I am up and running. OTA flashing of the esp-01 and arduino pro mini working like a charm.

SITUATION:
right after flashing esp-link (either 1.0.1 and 2.0 versions) onto the new module and connecting to 192.168.4.1 (stangely the modules appears as AI-THINKER_XXXX in my case) and going to WIFI setup page.
WHAT:
scanning for network ssids the scan never ends so there is no way to change the SSID.(it actually will end after 15 or 20 minutes but there is no way to know it, and it looks like something has went wrong)
i wonder if it has to do with how many networks are availiable (there are 30+ of them around where i am, if you include the very faint ones.

I just did a fresh install of everything on a Mint 17.1 32bit virtual machine in VirtualBox.

I took a few notes of what I had to do to get it running and thought it would be helpful to other newbies. These steps were omitted in the readme.

I had to install zlib1g-dev:

sudo apt-get install zlib1g-dev

I also had to install esptool:
I also had to install python-serial for esptool to work:

sudo apt-get install python-serial

I also went ahead and added the absolute path for esptool.py to the esp-link Makefile.

Double check the esp-link makefile for paths, make sure you have the correct path to the esp_iot_sdk (mine was the incorrect version).

Finally, don't forget to make sure that the esp-open-sdk/xtensa-lx106-elf/bin is in the PATH.

[EDIT]
I realize now that esptool should have been installed when I installed esp-open-sdk. Manually installing it probably wasn't necessary, I probably had a PATH issue.

Hi, is there a way to use the serial activity LED to control the TX enable for an RS-485 communication? Please point me to what files to edit to make the LED "blink" only on a TX activity duration, RX can be ignored. This should be sufficient to control the TX for an RS-485 communication. Thanks.

With a program outputing a few text lines each second the second chip (AH1444) on the ESP board is getting hot, 60 degree centigrade and rising.
https://files.gitter.im/jeelabs/n9KV/blob

Is this normal?
5V power supply.

Insecure:

• esp-link runs in STA+AP mode for 15 seconds at reset
• reprogramming and reset via port 23 is allowed
  Secure: (not really secure, sigh)
• AP mode only after reset if it cannot connect
• no reprogramming or reset via port 23

replaces #11 item 3

Update 6/17: this is general placeholder for implementing TLS and security. Right now esp-link is not secure. Unfortunately getting TLS to work is non-trivial and requires somehow freeing up a lot of memory first...

3 modes:

• always log (useful for debugging)
• never log
• log until connected

Ignore this thread, I'm using it to add images to the README.md...

When LPC devices are programmed to remap the reset pin it is required to apply power and set DTR/RTS in a specific manner to get access to the bootloader in order to program. Provide hardware and software support to handle this switched power capability, used currently as uploader -w while the device is physically disconnected and reconnected. This is particularly relevant to the JN-ESP device where physical disconnection is not obvious.

Is it possible to use mdns with esp-link?
What I mean is something like Avahi or Bonjour type broadcasting of own host name on the local network.
This way the esp module could be found on the network by it's host name: esp-link.local.
As these names must be unique, it would also be nice if the module automatically appended a number to the name: esp-link3.local.

First connection works, second is funny, perhaps only prints after ?

http://bbs.espressif.com/viewtopic.php?f=5&t=655

... so it blinks even when no-one is connected

Data sent by attached uC (uC Tx ->ESP Rx) is not passed to clients (port 23) (even if can be seen in ESP uC console). Checked using putty, telnet, Socket Test, HW Virtual Serial Port.
Checked on releases V1, V1.0.1 and V2beta.
Tested on ESP -12E - can be HW specific.

I'm quite new to DIY electronics, so I'd like to run this by you.

I have a device that can be controlled over RS-232 - but I'd like to control it wirelessly.

Do I understand correctly that an ESP8266 combined with a MAX232 could provide that? And that based on this project I could create a firmware that connects to the wifi, after which it provides a (authenticated, perhaps REST-ish) API to send commands to the device over RS-232? Or am I misunderstanding some things? :)

I configured esp-link to use a static ip address instead of DHCP.

After compiling the latest 'master' firmware and uploading it to my ESP-7 via wiflash, the ESP switched back to DHCP and lost the static ip settings after the reboot.

Is this the intended behaviour?

(I'm not yet familiar enough with the code to fix/analyse it myself at this moment, so i report it here)

The uC console page needs to display the current baud rate and also mention the serial settings (8 bit, no parity, 1 stop bit)

This replaces #11 item 6

Thank you for this great software! Flashing the ESP and the µC over the air is so cool!

There is a tiny typo in the release notes which might throw some people off:

% esptool.py --port /dev/ttyUSB0 --baud 460880 write_flash -fs 32m -ff 80m 0x00000 boot_v1.4\(b1\).bin 0x1000 user1.bin
Traceback (most recent call last):
  File "/usr/local/src/ESP8266/esp-open-sdk/xtensa-lx106-elf/bin/esptool.py", line 481, in <module>
    esp = ESPROM(args.port, args.baud)
  File "/usr/local/src/ESP8266/esp-open-sdk/xtensa-lx106-elf/bin/esptool.py", line 67, in __init__
    self._port = serial.Serial(port, baud)
  File "/usr/lib/python2.7/dist-packages/serial/serialutil.py", line 261, in __init__
    self.open()
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 282, in open
    self._reconfigurePort()
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 417, in _reconfigurePort
    set_special_baudrate(self, custom_baud)
  File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 47, in set_special_baudrate
    FCNTL.ioctl(port.fd, TERMIOS.TIOCGSERIAL, buf)
IOError: [Errno 25] Inappropriate ioctl for device

With --baud 460800 it works. This happens only with a CP2104 serial adapter; the FTDI board happily accepts 460880.

I've flashed esp-link v2.0.rc1 to ESP12 module. I've configured Wifi settings and cycle the power of module. All works fine, I can connect to esp-link via web browser and via serial emulator, serial link is working fine. Debug output is as below (I've stripped a couple of first bytes with different baudrate):

   294> 
   294> ** esp-link v2.0.rc1 - 2015-09-20 21:37:44 - e7311d5
   294> Flash config restore *FAILED*
   295> CONN led=0
   297> SER led=14
   299> Wifi init, mode=STA
   301> Wifi uses DHCP, hostname=esp-link
   305> "ip": "0.0.0.0"
   307> "netmask": "0.0.0.0"
   310> "gateway": "0.0.0.0"
   312> "hostname": "esp-link"
   315> Httpd init, conn=0x3fff1e10
   318> Serbridge pins: reset=12 isp=13 swap=0
   331> Reset cause: 6=external
   331> exccause=0 epc1=0x0 epc2=0x0 epc3=0x0 excvaddr=0x0 depc=0x0
   332> Flash map 512KB:256/256, manuf 0xEF chip 0x4016
   336> ** esp-link ready
   339> MQTT_Init
   340> mode : sta(18:fe:34:a0:19:e0)
   344> add if0
   345> f r0, scandone
  2464> state: 0 -> 2 (b0)
  2466> state: 2 -> 3 (0)
  2469> state: 3 -> 5 (10)
  2470> add 0
  2470> aid 6
  2470> cnt 
  2506> 
  2506> connected with frogland, channel 6
  2506> dhcp client start...
  2507> Wifi connected to ssid frogland, ch 6
  6665> ip:192.168.1.121,mask:255.255.255.0,gw:192.168.1.100
  6666> Wifi got ip:192.168.1.121,mask:255.255.255.0,gw:192.168.1.100
 12470> pm open phy_2,type:2 0 0
 15315> Wifi check: mode=STA status=5
 15315> Turning OFF uart log

I've tried powering off and on a few times, it worked fine. Then I've checked "enable SLIP" in configuration and cycled power again. Connection to Wifi wasn't restored and reset is not helping. esp is not starting it's own network too. Debug log is:

   297> 
   297> ** esp-link v2.0.rc1 - 2015-09-20 21:37:44 - e7311d5
   297> Flash config restore *FAILED*
   298> CONN led=0
   300> SER led=14
   301> Wifi init, mode=AP+STA
   304> Wifi uses DHCP, hostname=esp-link
   308> "ip": "0.0.0.0"
   310> "netmask": "0.0.0.0"
   313> "gateway": "0.0.0.0"
   315> "hostname": "esp-link"
   318> Httpd init, conn=0x3fff1e10
   321> Serbridge pins: reset=12 isp=13 swap=0
   334> Reset cause: 6=external
   334> exccause=0 epc1=0x0 epc2=0x0 epc3=0x0 excvaddr=0x0 depc=0x0
   335> Flash map 512KB:256/256, manuf 0xEF chip 0x4016
   339> ** esp-link ready
   342> MQTT_Init
   343> mode : sta(18:fe:34:a0:19:e0) + softAP(1a:fe:34:a0:19:e0)
   349> add if0
   351> add if1
   352> dhcp server start:(ip:192.168.4.1,mask:255.255.255.0,gw:192.168.4.1)
   360> bcn 100
 15318> Wifi check: mode=AP+STA status=0
 15318> Enabling/continuing uart log
 30318> Wifi check: mode=AP+STA status=0
 30319> Enabling/continuing uart log

To enable esp-link.local type of DNS names

The readme states that GPIO pins 12 and 13 are needed. I have the ESP-01 breakout version of the esp8266. It doesn't appear to have pins 12 and 13 broken out. Can I still use this module or do I need to purchase a different version?

Need to make sure that esp-link comes up even if it receives a high rate of garbage on the RX line and doesn't get stuck in framing error and RX interrupts.

First things first, this is the exact application I need for my home automation projects and I think a lot of others do too. A cheap transparent wifi to serial gateway. Thank you thank you.

Here are some observations and requests.

1. The web interface wifi page seems to work with Firefox but not internet explorer 11, on IE it never loads the list of detected APs. (if you don't want to support IE that’s fine, just mention in documentation which browser to use)
2. After the ESP8266 connects to an AP successfully, it doesn't show the IP address assigned so I have to search for it manually.
3. Powering down my router/AP does not make the module go back into AP mode. Indeed the module goes from consuming 20ma to 70ma which indicates it is trying to go back to AP mode but I can't discover it until re-flashing the unit.
4. Selectable baud rate that is saved in eprom is a critical feature. Lots of devices either cant or shouldn't communicate at 115200. Right now when I try to communicate through the ESP8266 to an Arduino uno using modbus it wont work. I don't know if this is due to the speed or something else.
5. You use port 23, it would be nice to be able to customize the port but not critical, at the very least you might consider putting the port on the web interface as a status so people will more easily know what port is used?
6. It would be nice to be able to see and set serial port settings. For instance: Speed, Parity, Data bits, Stop bits. I don't know what parameters you are using, I am not sure you have mentioned it in documentation? 115200,8,n,1?
7. Static IP Please. Dynamic works well for more modern protocols like MQTT however lots of common protocols like Modbus really requires a static IP if you are going to put something in production (i.e. not have to fix it when your router resets).
8. All of these settings need to persist through power cycle. If the default firmware that comes on these units would allow persistence for everything I would just bite the bullet and power through the pain of AT commands, but some of the critical settings reset on power cycle making the ESP8266 a toy so far...

I am sure someone has done the things I need before, maybe with an Arduino sketch or something else, however I have spent many hours and can't find an example anywhere. Sorry, I know this is a laundry list. I am used to having these features in industrial devices, obviously for my personal use I would like it in a $5.00 package! Keep up the good work and I look forward to your progress!
Thanks.

P.S. I am using an ESP-7 that came soldered down on a white breakout board.

When clicking on the uC Console page with an empty buffer there's a buffer overflow resulting in gibberish on the web page and a reset of the esp is required to really recover.

Hi,

First of all thank you for that nice piece of software! :-)
For my use case I need a mobile, battery powered standalone access point with encryption that bridges UART to TCP. From what I have seen, with ESP-link the ESP8266 can only be used as a station in a network but not as a secured access point. Could you please think about implementing this feature?

Thanks and best

Setup

• Arduino pro mini 3.3V/8Mhz with optiboot bootloader v6.2 modified to serial speed 250000 baud.
• ESP-07 with esp-link (commit f057a65), configured for 250000 baud, serial port connected to the arduino, gpio12 connected to arduino reset.

My programming environment (where I run avrdude) is a linux vmware host in a remote datacenter, connected to my home network via a vpn over a cable connection. The ESP module is associated with an access point on my home network. So the latency/jitter between the ESP and avrdude is a bit higher than a physical host on the same network as the ESP.

STK500 protocol

For short overview see: http://www.nongnu.org/pulsefire/apidocs/src-html/org/nongnu/pulsefire/device/flash/avr/Stk500Command.html, For the full specs see http://www.atmel.com/Images/doc2525.pdf)

For this explanation, only the next commands are parameters are relevant:

• commands:
  • 0x10 = STK_OK
  • 0x14 = STK_INSYNC
  • 0x20 = CRC_EOP
  • 0x30 = STK_GET_SYNC
  • 0x41 = STK_GET_PARAMETER
• parameters:
  • 0x80 = Parm_STK_HW_VER (hardware version)
  • 0x81 = Parm_STK_SW_MAJOR (software version major)
  • 0x82 = Parm_STK_SW_MINOR (software version minor)
  • 0x98 = Param_STK500_TOPCARD_DETECT (stk500 topcard detect)

STK500 synchronisation mechanism

The programmer sends STK_GET_SYNC;CRC_EOP (0x30;0x20) repeatedly until it receives STK_INSYNC;STK_OK (0x14;0x10) from the arduino. At that moment synchronisation is complete. After initial synchronisation, avrdude starts querying the device (hardware/software version,...) by sending for example STK_GET_PARAMETER;Parm_STK_HW_VER;CRC_EOP (0x41;0x80;0x20). The arduino replies with STK_INSYNC;hardwareversion number;STK_OK (0x14;0x3;0x10). This interrogation continues a for while and when all information is gathered and evaluated by avrdude, the programming sequence can start.

The following snippet illustrates initial synchronisation and beginning of the interrogation sequence. This is part of the console output if you run avrdude with multiple -v options (-v -v -v -v -v -v -v -v).

avrdude: Version 6.1, compiled on Aug 16 2014 at 00:04:23
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [06]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [02]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [98]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
...

Synchronisation errors

The following snippet illustrates an out of sync sequence (as seen by avrdude) I get very regularly:

avrdude: Version 6.1, compiled on Aug 16 2014 at 00:04:23
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Recv: . [14]
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x14
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [03]
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x03
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [10]
avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x10
avrdude: Send: A [41] . [98]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [06]
avrdude: Recv: . [10]
...

In this snippet, avrdude receives the reply (0x14;0x10) to the 0x30;0x20 synchronisation sequence twice. Since avrdude does not expect this, we get a 2 byte mismatch between issuing a command and receiving the answer to the command. This causes the protocol error messages and finally abort of the programming. In order to get a better understanding how this happens, we look at the serial communication between the ESP and the arduino.

The next image is captured with a logic analyser placed on the serial interface between ESP and arduino and shows 3 logic signals:

1. RX: serial port on arduino and shows the information sent from the ESP to the arduino
2. TX: serial port on arduino and shows the information sent from the arduino to the ESP
3. RESET: show the status of the arduino reset line.

Initial situation: Arduino is running and idling, not sending or receiving anything on the serial port. ESP module is booted and configured for serial bridge. Next, avrdude is started and has opened a tcp connection to the ESP module and starts sending it's first command.

Let's see whats happening step by step:

1. ESP received the first sync sequence (0x30;0x20) and toggles the reset pin of the arduino
2. The first received sequence (0x30;0x20) is sent to the arduino. (It is sent very short after the reset, and can be considered lost in almost all situations because the MCU has not booted yet at this moment)
3. avrdude did not receive a reply and resends the sync sequence (0x30;0x20)
4. the arduino sends a very late reply (0x14;0x10) to the second sync sequence. A possible explanation for the very late reply is the arduino serial port is already configured and listening around step 3, but some other bootcode is running at that moment and serial processing has not yet started until now.
5. avrdude did not receive the reply from 4 yet and resends for the 3th time the sync sequence (0x30;0x20)
6. arduino bootloader is up and running and immediately sends a reply (0x14;0x10)
7. by this time, avrdude has received the first reply (step 4) and sends the first getparm command
8. arduino replies immediately to the received getparm command (0x14;0x03;0x10)
9. avrdude sends the next getparm command
10. arduino immediately replies to the second command

(I verified the exact data bytes sent/received at each step, but lost the screenshots)

A few possible solutions

1. (simplified) ESP could discard late replies by the arduino. E.g. a reply to a sync command must occur within 50ms or else the reply is discarded. The effect would have been that the reply of step 4 is not sent to the arduino and protocol synchronisation would be ok.
2. The ESP could do the first synchronisation step by itself: Send 0x30;0x20 to the arduino until 0x14;0x10 is received from the arduino. Once avrdude resends the sync sequence (0x30;0x20) after the arduino is in sync, the ESP can answer to avrdude immediately by itself with 0x14;0x10.

My feeling is solution 1 seems to be the most protocol agnostic. If needed, the 50ms timeout can be set as an esp-link parameter.
Solution 2 feels like the most robust algorithm, but must be adapted for each programming protocol.

Remark 1: Maybe my observations are an optiboot specific timing issue. If needed, I could try with some other bootloaders.

Remark 2: Still haven't found the time to get acquainted with the esp-link code itself :-(

I am using version 2 on an ESp-01 with 32Mbit flash. I have notices two issues:

Scenario 1:
While ESP in WAP mode, connect to [email protected] and set PIN assignment to esp-01(AVR)
ESP goes into STATION mode and joins AP
Everything seems to work until you remove power from the ESP
after power loss, ESP loses PIN assignments and reverts to esp-bridge PIN assignment

Scenario 2:
While ESP in STATION mode (joined to AP), connect to esp@IP and set PIN assignment to esp-01(AVR)
ESP resets and loses PIN assignment and AP configuration
ESP reboots into WAP mode and needs to be re-connected to AP, PIN assignment reverts to esp-bridge

Is this expected behavior?

On a small screen in portrait mode, the wifi config screen is pretty much unusable. The same goes for the home screen. It would be great if this were adaptive and put the boxes in a vertical orientation when the screen size is smaller. I have attached a couple of images. Landscape looks fine, but you will see what I mean about portrait.

These features I miss already after 2 days of playing with esp-link:

1. Ability to change hostname and have a custom (short, e.g. 128 char) description. The hostname and description should be clearly visible on the homepage (and preferably also all subpages) to avoid user mistakes when managing multiple devices at the same time. At the moment you have to look at the browser address bar and the host ip to distinguish different devices.
2. Ability to disable remote programming. It's very easy to make a mistake if you have multiple simultaneous projects and make an ip address typo or copy Makefiles between projects. :-)
3. Serial programming does not always work with arduino optiboot loader compiled for 250000 baud programming speed. Sometimes it only works after the 4 or 5th programming attempt. My guess would be some timing issue, but I'm not yet familiar with the exact programming protocol. So i'll investigate/test this further when I have some spare time.

These features are not really important for me, but I think they would increase user-friendliness

1. Serial input field on the uC console window. It is easier on e.g. a tablet/mobile phone to open a webpage and query a device than going through telnet.
2. Have the ability to use custom baud rates on the webpage. Since the API already allows this (e.g. http://192.168.0.76/console/baud?rate=250000), it seems this is only a cosmetical issue (textbox in addition to the preset-buttons)?
3. Have the ability to configure and use a different baud rate for programming only. On arduino, different bootloaders expect a different baud rate for programming depending on version, clock speed... (often 38.4k, 57.6k up to 115.2k). But sometimes an application wants to use a different baud rate to minimize transmission errors or achieve higher throughput. Many users lack the knowledge/hardware to compile and upload a custom bootloader where the programming baud rate equals the application baud rate. At this moment, the user must go to the uC console page, select the correct programming speed, program the device, select the correct application speed, watch the console logs... (repeat this for each programming iteration)

I'm really looking forward to the already announced features (outbound TCP requests, MQTT, REST...) :-)

I have the issue that the ESP does not connect to my wireless network. The same happens with another sieral-Wifi bridge software (ESP transparent bridge)

I notice a rather high power consumption when I powerup the esp8266 (ESP12-Q, esp-link v2.0.beta2 precompiled binaries). As can be seen in the screenshot below, it draws a current of 72mA when doing nothing and about 115mA when listening.

However, when I surf to the built-in esp8266 webpage and change the pin assignment from jn-esp-v2 to wifi-link-12 and back to jn-esp-v2, the module suddenly draws approx 50 mA less (24mA idle, 78mA listening). The mentioned behaviour is repeatable. See screenshot below.

Everything still seems to work perfectly (http server, serial,....). It seems like some extra powersaving feature of the esp8266 is turned on when I switch from wifi-link-12 pins to jn-esp-v2. These results are more in line with the scope screenshot at http://jeelabs.org/book/1526f/.

PS. the current shown is the total current drawn by an arduino-pro-mini (3.3V,8Mhz) with a very simple serial echo-repeater example loaded and the ESP12-Q module with esp-link. I verified the power consumption of the arduino does not change at all (7mA avg, 11mA max) during the experiments.

Btw. You are doing a great job! Esp-link is exactly what I was looking for :-)

Hi!

Thank you very much for the great firmware. This was what I was really looking for - having a serial bridge with the comfortable option to change STA settings without reflashing.

As the software I am using only allows port numbers above 1023 to be used for TCP I have to alter the port number - but I am not able to flash the software because its to big. I already altered the Makefile to assume 512kB flash (which correctly results in a warning that the firmware will not fit) and removed mqtt and rest modules - still the size is too big.

Any suggestions?

BR
Robert

When the esp8266 is configured to connect but can't it keeps scanning and tring to connect, using 70mA the whole time. Something should be done to make it reconnect less often.

Code provided by iothing http://www.esp8266.com/viewtopic.php?f=34&t=3445&start=80#p22358:

static void ICACHE_FLASH_ATTR resetTimerCb(void *arg) {
  int x = wifi_station_get_connect_status();
  int m = wifi_get_opmode() & 0x3;
  os_printf("Wifi check: mode=%s status=%d\n", wifiMode[m], x);

  if (x == STATION_GOT_IP) {  //connected successfully and got ip
    if (m != 1) {  //not already in sta mode

#ifdef CHANGE_TO_STA
      // We're happily connected, go to STA mode
              os_printf("Wifi got IP. Going into STA mode..\n");
              wifi_set_opmode(1);  //stay in the mode we are in!
              wifi_set_sleep_type(SLEEP_MODE);
#endif
    }
    //continue to check on the wifi state
    os_timer_arm(&resetTimer, RESET_TIMEOUT, 0); //check again in RESET_TIMEOUT seconds
  } else {
    if (m == 3) { //if we are in AP+STA Mode
      if (retry) {
        os_printf("WiFI: no ip, retry...\n");
        wifi_station_set_reconnect_policy(true); //attemp to reconnect
        wifi_station_connect();//reconnect
        retry = false; //unset the retry flag
        os_timer_arm(&resetTimer, 10000, 0); //check again in 10s
      }
      else  {
        os_printf("WiFI: no ip, wait...\n");
        wifi_station_set_reconnect_policy(false); //disable auto-reconnect
        retry = true; // set retry flag
        os_timer_arm(&resetTimer, 120000, 0); //check again in 120s
      }
    }

    if (m == 1) {  //in STA mode and no ip
      os_printf("STA->AP+STA\n");
      wifi_set_opmode(3); //change to AP+STA mode so the user can correct the wifi settings
      wifi_station_set_reconnect_policy(false); //disable auto-reconnect
      retry = true; // set retry flag
      os_timer_arm(&resetTimer, 120000, 0); //check again in 120s
    }
    //if in AP mode (default after flash) do nothing
  }
}

Seen using esp-bridge and arduino

Hi,

esp-link created some funky files when I connected it to a serial console of an openwrt router:

root@GL-iNet:/# ls
ls

**
CONN
Flash
Httpd
MCU
Reset
SER
Scan
Serbridge
Starting
Turning
Wifi
add
aid
bin
cnt
connected
dev
dhcp
download_file.socket-0
espFsInit
etc
exccause=0
f
gateway:
hostname:
ip:
ip:192.168.0.10,mask:255.255.255.0,gw:192.168.0.1
lib
mnt
netmask:
overlay
pm
proc
rom
root
sbin
scandone
sys
tmp
usr
var
www
root@GL-iNet:/#

Any idea where those files come from?

I am trying to use your esp-link in transparent mode to replace a serial port. The port presents a prompt and I send a dump command. It seems to work okay until the dump returns about 2140 characters. At this point I lose the final characters of the dump. Is this expected?

I do see the final characters and prompt correctly on the microcontroller console.

I suspect this is a flow control issue. I don't see any debug messages. I'm using V1.0.1 on a ESP-01

I read your blog, but I don't see any reason why a large packet coming from the UART side would cause flow control issues. Any idea?

If this is hopeless I'd like to know, otherwise I might have a look at the code and try to fix it myself.