-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated code for inbound wifi data buffering #232
base: master
Are you sure you want to change the base?
Conversation
tl;dr Tried to fix constant drops on my HW, ended up changing more than I wanted to. So I went down the rabbit hole with this change., and I'm not sure if it's even needed since quite a few people have not had issues with WiFi (specifically for the Mega256+esp8266). The problem I was seeing was a frequent mismatch between the CIPSEND command and the corresponding data which caused the WiFi to stall and drop. This issue was likely exasperated by my network, so I wanted to see if I could synchronize the CIPSEND. I wasn't able to do what I wanted with the current implementation, so I needed to change quite a bit. Hopefully, something similar can be done with the original code if this change is too involved. I added a 32 byte buffer to parse the incoming messages. Those messages are grouped as either ending in /r/n, start with '>' or are +IPD messages. All messages are read into the staging buffer one at a time. The exception is the +IPD message which is read up to the ':" to get the data length, then the rest of the data is written to the inbound ring buffer directly. This just let me control which message I was dealing with easier. From that, I also added some synchronization to trace the CIPSEND from start to SEND_OK/FAIL. Tested with the Engine Driver App and Cab Engineer apps. My board was terrible before, could not click more than a few buttons before dropping out. On my setup, its very stable now, can also switch between the apps. This was only tested on one board, so it needs to really be vetted on more hardware with users who are familiar with the functionality. Also, AP mode is terrible on my HW so no app I ran (even test apps) seemed to work very well. My testing was mainly using STA mode. |
One thing I noticed with the Engine Driver app is after a dropout, it seems like the rate of message sending increases (heartbeat?). The controller can usually keep up, but it can lead to more dropouts. I think this -may- be the app, because when I shut it down I can see the proper quit message (<* Q\n\0 *> 0,CLOSED\r\n), then if I restart the app, the rate returns to normal and the app reports the correct button statuses. |
- Added timestamps for CIPSEND and +IPD tracing
Added a flush for the esp8266 data receive buffer if the link drops |
Further updates
No description provided.