kivan117 wrote:Also, aside from waiting for a timeout, is there any way to know the module is even there and functioning?
Shortest method is sending "AT\r\n" and you should quickly get back "OK\r\n". It's probably best not to do that while it is in the middle of something else like scanning for APs(which takes quite a while), connecting, right after a send, etc. The newest firmware seems to recover from it that I've seen, but the older firmware would say "Busy now..." and be worthless from there on until you did a hard reset. That was truly frustrating trying to debug stuff before I knew what was going on, I find the newest firmware reliable.
kivan117 wrote:High level, my plan is to basically have a Uzenet controller/state machine.
All those details you mention; it sounds like we are doing the exact same concept, mine is very lazy also to avoid using too many cycles per frame. I removed a lot of the checks for things that should never fail, because well, they never seem to fail anymore and it makes the code faster/smaller/simpler. The caveat of sending UART traffic while it's busy still remains, but my state machine makes sure it's working by verifying baud/functionality with "AT\r\n" at step 0, after that things like "AT+CIOBAUD", "AT+CIPMUX=0", "AT+CIPMODE=x", even "AT+CIPSTART.." I treat as deterministic. I give a wait frame in between and "eat" whatever response it sent at the next step without checking. The only things I don't take for granted are network things like "AT+CIPSEND=..", "AT+CWJAP", "AT+CWLAP", so I do hard error checking there. If there were previous errors before, well, they will get caught there since it wont send the data. My error handling is simple setting the state machine back to step 0 which resets the module and tries again, I think of it basically as a script, and it's reliable.
kivan117 wrote:Any design tips for handling the incoming stuff?
It is complex to write code that works with partial packets, since of course the data might not all be there until next frame. I rely on the fact the server will always send me an exact amount of bytes per the request made, and it will never send extra data I didn't ask for, so you do have complete control over everything that comes in the form of "+IPD...", except for how long it takes to get it all. I propose not to read any data after a send, until you have at least the correct amount of bytes in the UART buffer you should be getting, including the "+IPD.." bytes. Then you don't have to deal with partial data, and you can know if an error occurred simply by checking the first byte for anything besides 'S' in "SEND OK\r\n", then eat "SEND OK\r\n+IPD...", then use the raw data you have left. I plan to do this until I find evidence it's not reliable, I hope you do too so we can determine what assumptions are safe to make so our lives get easier as community experience goes. This is still experimental stages afterall! Also, you have to figure, if you do discover an error, there is not much better to do than simply start from the beginning. Again, I am not seeing this happen personally.
Edit- BTW, that doesn't cover all cases. For instance we have to keep in mind data bigger than 256 bytes seems to come in separate "+IPD" chunks split across a max size of 256 each, a simple byte counter should work to eat "IPD" again, but I haven't needed it yet. Another thing to consider is that at any point in time you could get disconnected from wifi, internet could go down, the server could go down, etc. Again, that should be very rare, but it will instantly send "UNLINKED" or whatever(I forget). I implemented a time out while waiting for the amount of bytes the payload should have, so if I have not received all the bytes I should get from the server for a while, I restart the whole thing which should cover that. Error messages should never just interrupt the middle of an IPD but should wait until it's over so data corruption should not be an issue. The server always disconnects an Uzebox instantly if it sends something with a bad format, like not enough bytes, too many bytes for the num and len of the entries you specify specifically to prevent issues. This should always indicate bad programming. Even with the artificial delays it currently does, I do not actually see the 8266 breaking packets in 2, or combining packets using the "Nagle Algorithm". That's weird but I have not spent a lot of time with WireShark watching it yet nor sent much a variety of data to it.