<div dir="ltr">Hi Richard,<div><br></div><div>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.</div><div><br></div><div>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).<div><br></div><div>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 (<a href="http://www.whatimade.today/esp8266-and-the-water-heater/">http://www.whatimade.today/esp8266-and-the-water-heater/</a>). I started along these lines then found I'd over-extended.</div></div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Yani.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 24, 2015 at 4:12 PM, Yani Dubin <span dir="ltr"><<a href="mailto:yani.dubin@gmail.com" target="_blank">yani.dubin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Richard,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr">So I picked up the gauntlet and got some modules working eventually.<br></div></div></div></blockquote></div></div></blockquote><div> </div></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">Is anyone else using these modules? I know Phil wrote an great introduction here: <a href="http://rancidbacon.com/files/kiwicon8/ESP8266_WiFi_Module_Quick_Start_Guide_v_1.0.4.pdf" target="_blank">http://rancidbacon.com/files/kiwicon8/ESP8266_WiFi_Module_Quick_Start_Guide_v_1.0.4.pdf</a></div></div></blockquote></div></div></blockquote><div> </div><div> As it happens, I finally decided to have a poke at mine this weekend.</div><div> </div><div><br></div><div><div>I played with the AT commands briefly, seeing how one could easily implement ones own webserver on a connected uP.</div><div><br></div><div>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.</div><div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div></div><div><br></div><div>I intend to put this on github when I'm done (will be under <a href="https://github.com/YaniDubin" target="_blank">https://github.com/YaniDubin</a>), 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 :)</div><div><br></div><div><br></div><div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">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.<br></div></div></blockquote></div></div></blockquote><div> </div></span><div>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?</div><div><br></div><div>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.</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div dir="ltr">An excellent open source hardware and software example of what can be squeezed into the device is available here: <a href="http://harizanov.com/wiki/wiki-home/three-channel-wifi-relaythermostat-board/" target="_blank">http://harizanov.com/wiki/wiki-home/three-channel-wifi-relaythermostat-board/</a> 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.<br></div></div></blockquote></div></div></blockquote><div> </div></span><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div></div><div class="gmail_extra"><br></div></div></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div>I bought the ESP12 because they have the most IO pins available at the moment<br></div></div></div></div></blockquote></div></div></blockquote><div> </div></span><div>That moment has passed it seems - last night I ordered some of the newer ESP-12E modules.</div><div><br></div><div>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: <a href="http://www.aliexpress.com/item/Free-Shipping-5pcs-lot-ESP8266-remote-serial-Port-WIFI-wireless-module-through-walls-Wang-ESP-12/32268066794.html" target="_blank">http://www.aliexpress.com/item/Free-Shipping-5pcs-lot-ESP8266-remote-serial-Port-WIFI-wireless-module-through-walls-Wang-ESP-12/32268066794.html</a>. 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.</div><span class=""><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div>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.<br></div></div></div></div></blockquote></div></div></blockquote><div> </div></span><div>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.</div><span class=""><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div>Tomorrow I hope to hook up a 128x64 oled display and install my own web pages.<br></div></div></div></div></blockquote></div></div></blockquote><div> </div></span><div>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?</div><div><br></div><div><br></div><div>Regards,</div><div>Yani.</div></div></div></div></div>
</blockquote></div><br></div>