[chbot] ESP8266 Wifi module progress

[Yani Dubin]

Hi Richard,

Didn't take long to hit a wall with the lua/NodeMCU approach. This language
seems to quickly consume the little available memory left over for the user
application.

Recompiling the firmware to disable the built-in modules I wasn't using did
little to increase the available memory. I expected this because these are
implemented in C - I believe it is a case of there only being so much
script you can have before it chews through the memory. It possibly doesn't
help that I'm new to lua (and not looking to become any more expert than I
need to).

So unless you were really keen on lua, and knew how to optimise it for
memory usage (and when you could call garbagecollect() to clear the decks),
I wouldn't recommend it unless you only wish to control a few buttons.
Trying to generate flexible/dynamic content seems to have taxed it a bit
much. This is the post I followed initially where it is successfully being
used to control a single GPIO (
http://www.whatimade.today/esp8266-and-the-water-heater/). I started along
these lines then found I'd over-extended.

I'd be keen to know how you get on with the esp-httpd approach used for the
relay thermostat board - I think I will be looking at something along those
lines next.

Cheers,
Yani.

On Sun, May 24, 2015 at 4:12 PM, Yani Dubin <yani.dubin at gmail.com> wrote:

> 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/482f8b9c/attachment.html>