Arduino-ish clone (ATMega32U4) with interface to ESP8266-01
So I decided to bite the bullet and develop my framework directly onto the ESP. However, I didn't want to develop it on Linux, which seems to be the standard fare out there. I develop my Arduino/Atmel code using Eclipse on my Windows PC and I like the environment. I found a site out there that documents how to do ESP development via Eclipse.
If that's how you want to roll, here's the link.
Using a USB FTDI Serial cable (at 3.3v Tx & Rx lines) and a little breadboard with a 3.3v regulator (the signals from the cable are 3.3v, but annoyingly the power is 5v), and reset and program switch, I'm able to deliver my code right to the ESP chip.
So I rewrote the Framework to work directly off the ESP. And it works great. I had some challenges. The documentation regarding the ESP is scant and not well organized. I mean you can find the manuals for the API, but it doesn't document the ports, how to set them up, or anything about how memory is organized.
Here's what I learned/figured out:
I am still working on the code, but I am maintaining it on GitHub here. The GitHub will only have code that somewhat works. As I add stuff, I'll commit it and post a log.
I'm a C++ programmer (among other languages) so I set out to virtualize the ESP into various components like Sockets, MQTT Client and HTTP Server (to change the MQTT Client settings). My first project for the board was the ever popular NeoPixel Christmas Lights controller. I know, cliché, right? But hey, it's good for proving out various types of settings. I had settings for effects (i.e. blink, theater chase, etc.), appearance (i.e. colors) and effect enhancements (i.e. speed, pixel density, etc.).
Additionally, I created an Android app that was also an MQTT Client that would allow me to view the current settings of one or more boards (at one time I had 3 going) and allow it to alter those settings.
My MQTT approach was simple:
I was largely successful in setting up my framework, but there were issues. They were the same issues everyone faces with these microcontrollers: memory (both RAM and Program) and speed. By the time I had the framework for the HTTP server and MQTT client, I had nothing left to include the application! Some will say that C++ chewed a lot of it up, but it really doesn't and I was judicious in my use of memory.
Another issue was the complexity of the IP protocol with just the AT command set of the ESP. First, socket programming is by its nature, asynchronous, but the nature of the AT command set is synchronous. What that means is that I had to create a complex state machine to keep track of the asynchronous traffic in and out of the sockets over the synchronous stream of the UART. You can't start sending data to a socket in the middle of receiving one or you'd get 'busy' from the ESP. Updating a string of 300 NeoPixels takes longer than 2 character transmits from the ESP and since interrupts were off during an update, you could miss data coming from the ESP. I fixed that by altering the NeoPixel code to check the interrupt bit on the UART and bail when it saw it, but still the complexity of parsing the UART stream and reacting to various possible data coming from the ESP was, in the end, just too much to bear. The parser was recursive (Note: recursion is bad when you have only 2K of RAM!) so that if a message from the ESP came in (i.e. +IPD... or +AT+CLOSE) in the middle of issuing a command and waiting for the response, it'd stop what it was working on, parse the message, issue the appropriate method on the Socket, and continue on with what it was last working on. When using a 'slider' on the Android app would cause a flurry of messages to come in (and respond to), all the while maintaining...Read more »