I’ve been using NodeMCU boards for a couple of ESP8266 projects, and they’re certainly a very easy way to get into ESP8266. The NodeMCU module contains an ESP-12E module and a CH340 USB-to-serial chip.
However, this is also the least satisfying aspect of the NodeMCU experience. The USB interface appears as a generic serial port, with all the attendant baud-rate configuration issues, and while esptool and luatool work very well, having the host upload code at 9600 bits per second is rather frustrating.
Clever use of the DTR and RTS lines allow the host computer to reset and reflash the ESP
Additionally, while the USB port is disconnected, the CH340 is still using up space and power to no purpose.
As an alternative, a small USB-enabeled CPU such as an ATMega8U2 with LUFA, or even an ATtiny167 with V-USB could be used. The ESP would still be the ‘primary’ CPU, but the AVR would provide USB interfacing and additional functionality.
This chip would interface between the USB host and the serial programming port of the ESP8266, manipulating the same “reset” and “boot mode” pins as the CH340 solution does. But rather than presenting to the USB host OS as a serial port, it would present a more sophisticated and controllable interface, with ioctls to control its behaviour. A user-space driver could then even expose the contents of the ESP flash as a file system.
The AVR controllers also have plenty of nice onboard I/O, so the chip could continue to be useful while disconnected. Simple serial port commands from the ESP to the AVR could read and write individual pins on the AVR, or use the AVR to provide stepper motor control.
Eventually, this work may feed in to the Cubic Inch Robot project.
The controller would be able to pull the main CPU in and out of programming mode and possibly even access the main flash while the main CPU is disabled.
I’m still working on how to hook one to the other, but in the meantime I’ve playing around with some old-school AVRs and I’ve asked pid.codes for a PID for the device!