As part of my internship, we are using ESP8266-01 devices connected to PIC controllers with the ability to send/receive data each way. The company already had a well established Lua server program going, but now I've been tasked with looking at potentially swapping to Micropython.

Problem:

After playing around for a day or so, I've managed to get the web server working, and displaying a very basic HTML page (from the tutorial on the docs(dot)micropython(dot)org document repository). However, it requires constant connection to the terminal window (PuTTY), which is fine for testing, but does not cut it for the potential applications.

How would I go about creating a web server on the ESP that can be run without PuTTY and then also be used via UART communication to a PIC chip?

You mention "Some of the modules in this package require significant amounts of RAM to load and run", do you mean the ESP or another controller that it is connected to? Because the ESP I have available has very little RAM I believe.

What chip did you write it on? Because it does look close to what I want to do, but if the chip can't handle it, then I'll need to find something else.

I think it depends a lot on what you are doing. Uploading all the python files to the micro python file system and having the runtime compile all of them, while running webrepl and your application code will quickly run you out of RAM. On the other hand, if you freeze the byte code on an image, the results are far better.

For example, here is a memory dump on a raw image (no webrepl or uhttpd loaded or running) right after restart:

I have not done a lot of analysis of the uhttpd code to determine what space optimizations can be made. I suspect there is opportunity for improvement.

So I don't know how well you'd do elsewhere, or even if you wrote the code from scratch. Yes, the uhttpd modules do contain several levels of abstraction (in order to encapsulate protocols at their appropriate levels), but I don't know how much memory improvement you'd get by effectively writing the same code in one module. I've never measured the RAM impact of factoring code into lots of smaller modules, vs one big module. Maybe someone here has?

Also, please beware the the uhttpd modules are pretty new and are not well tested. In time they will be, but this is really a hobby project that has not seen a lot of exposure. And of course there is no professional support. On the other hand, the code is small, open source with a BSD-style license, and as I mentioned before, PRs are always welcome

I am also looking forward to some improvements to make, including:

* Support for POST/PUT through the REST API (will likely require some interface changes)
* Support for HTTP basic auth
* SSL support, if at all possible. (There is some code in there now to support SSL, but there is no auth or certificate management, so its value is dubious from a security perspective)

These changes may image the stability of interfaces and APIs, so anyone using this software should be prepared for the possibility of API-incompatible changes.