esp-link revisited

Regular readers may remember my article on hardware implementation (and my associated balls-up) for a serial console using an ESP8266 and JeeLabs’ excellent esp-link firmware.  Well this weekend I had cause to revisit it.  Another fairly ancient, headless server (a Soekris box this time) was in dire need of an update, so I reached for my trusty console adapter.

Except (there’s always an “except”, or a “but” nowadays …have you noticed?) that the Soekris has a console which, at boot-up, defaults to a (very useful and quite speedy, for the time) baud rate of 19,200  …and my v2.0-beta version of esp-link didn’t handle that as one of the selectable baud rates.  No problem!  One of the nice features of JeeLabs’ package (which I mentioned in the original article) is that you don’t even have to compile the code; they very conveniently provide the pre-compiled binaries on their site and, because I already have esp-link running on my ESP, I don’t even need to reach for the USB cable and FDTI adapter,  I can just flash over the air using the built-in utility.  Except…

Instead of doing a “make flash”, I decided to download the new firmware package, which consists of the binary files you need, as well as a little shell-script called “wiflash”.  Wiflash is a little helper script which basically wraps “curl” to do the heavy lifting.  You just give your ESP’s hostname (or IP address) and it’ll go off and do the actual programming for you.  Except that in my case it came back with an error message (from curl):-

HTTP server doesn't seem to support byte ranges. Cannot resume.

…which seemed a little strange, as at that particular point, all it was doing was fetching a 9-byte long file, /flash/next, which contained the plain-text name of the area to program this time round, “user2.bin”, and I wasn’t requesting, or expecting it to have to resume anything.

The curl manual page doesn’t seem to elaborate on whether the -C (–continue-at) option is a default or not, but it does say that prefixing option names with “no-” will disable them, so it seemed worth trying as a quick fix (remembering that today’s objective is to upgrade a system, not debug curl or the esp-link web server), so I simply modified line #82 in wiflash from:-

next=`curl -m 10 $v -s "http://$hostname/flash/next"`

to:-

next=`curl --no-continue-at -m 10 $v -s "http://$hostname/flash/next"`

…and blindly hoped that all of the other calls to curl in the script would just work.

As it turned out, work they did and that one simple change was all that was needed (a quick trip to the “issues” tab on the esp-link git page confirmed that I’m the only one, so far, to have seen this issue, so I’m willing to  believe it’s just a quirk of my fairly ancient OS combined with the old, original v2.0-beta version of esp-link already on the device).

Anyway, a minor problem solved and a nice, shiny, new version of esp-link installed on the ESP, with lots of new features and (almost! ‡) all of the baud rates you could ask for.

Screen shot of esp-link v3 console page

Note that the baud-rate and parity/stop configurations are now on nice, drop-down menus and there’s a separate console input box, as well as selectable history for all of your previous commands.

In addition, on the side panel we have new pages for “WiFi Station”, “WiFi Soft AP”, “Services”, “Upgrade Firmware” and “Web Server”.  While some of that information was available with older builds, the new pages give an uncluttered, neater feel to the application and, for most of the pages, there are new additions to the existing configuration options, giving you, for example, the option to set up a server and timezone for SNTP services.

All in all, a worthwhile update for a very useful utility and, while we’re here, I notice that JeeLabs and Thorsten von Eicken have created a tiny (and much neater) hardware solution than mine, specifically for programming one of their new products.  Neat!

 

‡ 74880 anyone?  (Yes, it’s that annoyingly non-standard squirt of debug info at ESP power-on)

Advertisements