[chbot] ESP8266 Wifi module progress

[Yani Dubin]

Hi Richard,

So I picked up the gauntlet and got some modules working eventually.
>>
>

> Is anyone else using these modules? I know Phil wrote an great
>> introduction here:
>> http://rancidbacon.com/files/kiwicon8/ESP8266_WiFi_Module_Quick_Start_Guide_v_1.0.4.pdf
>>
>
 As it happens, I finally decided to have a poke at mine this weekend.


I played with the AT commands briefly, seeing how one could easily
implement ones own webserver on a connected uP.

Initially I was hoping to see if I could use it as a cheap serial-wifi
dongle (PPP or SLIP) to provide internet connectivity to any Linux based
board (with its own TCP stack and all the userspace tools needed - but
without taking up a USB port - if it even has a full sized one). After much
messing around, I ultimately determined that this was a waste of my time -
the SDK apparently only provides access to TCP/UDP, not the IP level. Even
though some of these firmwares (NodeMCU for instance) include lwIP, when I
peeked into their code, I found they were just wrapping up TCP level
commands to shift data to/from the network interface - it appears there is
no access at the IP level at all, so now way to forward IP data. So IP over
IP is out, but theoretically you could try some sort of TCP level
encapsulation (ssh tunnelling/forwarding for instance), but my interest had
well peaked by this point and I just ordered some USB WiFi dongles (1.85USD
without 2dBi antenna, 3.44USD with) and mvoed on to the things it is
capable of.


Ultimately, I installed NodeMCU (firmware, not to be confused with their
devkit of the same name), which allows you to host lua scripts to do almost
anything. The advantage of this approach is a very simple way to leverage
the module as a standalone web-based control plane with no need for a
secondary uP. I don't think my passing interest in web connectedness will
take me to the point of writing my own firmware / hacking at that level.

So last night I wrote a basic webserver in lua. This was my first time
using lua, so I got a bit carried away with the fun of learning a new
language. Once I'm, done, it will provide monitoring/control of all GPIO
pins (so you can set input/output mode from the web interface), allow you
to save these settings as non-volatile, provide the ADC value, and list the
scripts present and allow you to run them. Almost all of this I already
have working. Stretch goals would be allowing you to view (and possibly
edit/save) the scripts on target.

I'd also like to put in some more REST interfaces in and see how easily I
can leverage this to provide ajax style pages. If memory serves, this is
all client based, so quite doable (if I don't get bored first - I'm more a
driver level guy, and only like brief forays into application space).

I intend to put this on github when I'm done (will be under
https://github.com/YaniDubin), so if anyone is interested in going the
NodeMCU route, and I've lost momentum (as I am wont to do), please give me
a kick, and I'll publish what I do have :)


I tried to use an FTDI USB dongle to program the modules but it kept giving
>> me errors. I eventually gave up and used a trusty PL2303 USB to RS232
>> instead with a 4049 cmos level shifter to 3.3V which worked first time.
>>
>
I'm using an FTDI based Tait device (Terminals DSUMON interface if you're
familiar) which can communicate reliably at 921600 baud. So the baudrate
generation on the ESP side must be pretty solid - either I got lucky, or it
is all down to the stability of the interfacing serial converter or uP?

Having said that, the speed of the device itself limits the usefulness. For
me, that has really only been debug (via UART), and programming in new LUA
scripts (using the python script 'luatool' to encapsulate lines of text in
the NodeMCU file.write() calls - this is very inefficient, and the loader
has a 0.3s sleep between lines - try sending lines of script to write via
NodeMCU any faster, and you run into errors). But if you were passing data
back and forth with a server hosted on a separate uP, regardless of where
the throughput bottleneck sits, seems there's no point adding unneeded
latency at the UART.


An excellent open source hardware and software example of what can be
>> squeezed into the device is available here:
>> http://harizanov.com/wiki/wiki-home/three-channel-wifi-relaythermostat-board/ I
>> have the relay board code working with a single 1 wire temperature sensor.
>> Multiple temperature sensors do not seem to work, not sure if its a
>> hardware or software problem.
>>
>
Yes, this is where I learned about esp-httpd (which it uses). This might be
a much better approach than the lua hacking above. If you want a real
webserver, where you provide just the html, I presume this is the best
thing going. This has the advantage, from what I read of it, of being
multi-user. What I've hacked in lua is not. So if one client authenticates
(password field), another can jump in and control what they really
oughtn't, but the temptation is just too great :). I'm not sure about
esp-httpd, but esp_bridge (which I've also played with) boasts openssl
support.

Another advantage is scalability - because the HTML is dynamically
generated in lua, that file contains the whole server (probably you can
spread this out by invoking other scripts, but that seems a kludge).
esp-httpd would provide better scalability if you had a complex UI with
many pages - and it uses some form of cgi to provide dynamic content /
access to the hardware.

One less obvious advantage of esp-httpd is that it potentially has a faster
debug/reprogram cycle. Correct me if I am wrong, Richard, but I believe you
upload an image with all your static files using the bootloader to a
specific region of flash. As compared with echoing a line at a time to a
lua interpreter (as explained, 0.3s sleep between lines of script - very
slow indeed).

So my only concern is it is more fiddly (need to go into bootloader mode
rather than reprogramming in run mode). But then I'm sure I've come across
USB based programmers which use the DTS line or similar to manage resetting
into bootloader seamlessly, so presumably that fiddliness can be mitigated
(need to control GPIO0/reset).


I bought the ESP12 because they have the most IO pins available at the
>> moment
>>
>
That moment has passed it seems - last night I ordered some of the newer
ESP-12E modules.

These seem to be new, so there are many misleading AliExpress listings
which combine pictures/specs of both 12/12E. The distinction is the 12E
brings out the SPI interface on a third edge (so connections on 3 sides
rather than 2). I found one which consistently advertised the -12E (2.56
USD a piece at 5x). This is the seller link I ordered from:
http://www.aliexpress.com/item/Free-Shipping-5pcs-lot-ESP8266-remote-serial-Port-WIFI-wireless-module-through-walls-Wang-ESP-12/32268066794.html.
Happy to on-sell if anyone wants to try this model out once I've confirmed
they are as advertised. While there is an ESP-13 available now, it looks
much like the -12, and doesn't have the extended pins of the -12E.


Much of the ESP8266 example code around the web has makefiles that need to
>> be re-written or modified to work with the open source tool chain. Some of
>> the examples required mods to header files and prototypes as the tool chain
>> has moved on over the months.
>>
>
I found that esp8266_open_sdk to be good, after a few tweaks to the
makefiles as you describe. But then I only used it to build two projects
(NodeMCU and esp_bridge firmwares). These only required updating makefiles
with LDFLAGS/CFLAGS to insert the -I and -L (I built the split
toolchain/SDK - perhaps with the combined one this is not needed?), and
adding the tools to the PATH, so these must have already been migrated to
the latest toolchain.



Tomorrow I hope to hook up a 128x64 oled display and install my own web
>> pages.
>>
>
I was wondering if you can access the SPI interface on the earlier modules
(pre 12E), but under different names? How were you planning to interface
the Oled? Was this via SPI, or something else entirely?


Regards,
Yani.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20150524/0de757b2/attachment-0001.html>