- Sat Nov 08, 2014 12:24 pm
#2339
You're right the dreaded "busy..." renders the esp8266 useless until a hardware reset recovers a useable state.
The issue does great violence to the concept of repeatability ....the ability given similar circumstances to get a similar result.
Since the hardware reset restores a working esp8266 after a pause of several seconds; it can be handled by watchdog timers in an attached MCU ( ex PIC) that detect the dreaded "busy.."
and fires a hardware reset and then waits for a proven response from the esp8266. The command that got the dreaded "busy " response can then be reapplied with a statistical probability it might succeed. A three strikes you're out and a watchdog can bring both the esp8266 and the MCU to a power on state.
Frankly this is unpleasant but it is the way the esp8266 firmware designers have chosen so far. It may be a result of the chosen AT human readable interface and the need for extensive parsing
to ensure any command sent is structured correctly....since commands often share a common beginning but vary in length..the esp8266 may be waiting for a keystroke that may never come.
A robust interface of 0..255 decimal numbered 1 byte commands would cut out oodles of parsing and timing issues.
The model to follow is an LCD controller...basically several dozen commands...that branch efficiently within the controller since each command is unique and of fixed length.
Anyway the AT mess does have a very small advantage in testing in that it is human readable. I would love to see the AT interface abandoned in future firmware.
The issue does great violence to the concept of repeatability ....the ability given similar circumstances to get a similar result.
Since the hardware reset restores a working esp8266 after a pause of several seconds; it can be handled by watchdog timers in an attached MCU ( ex PIC) that detect the dreaded "busy.."
and fires a hardware reset and then waits for a proven response from the esp8266. The command that got the dreaded "busy " response can then be reapplied with a statistical probability it might succeed. A three strikes you're out and a watchdog can bring both the esp8266 and the MCU to a power on state.
Frankly this is unpleasant but it is the way the esp8266 firmware designers have chosen so far. It may be a result of the chosen AT human readable interface and the need for extensive parsing
to ensure any command sent is structured correctly....since commands often share a common beginning but vary in length..the esp8266 may be waiting for a keystroke that may never come.
A robust interface of 0..255 decimal numbered 1 byte commands would cut out oodles of parsing and timing issues.
The model to follow is an LCD controller...basically several dozen commands...that branch efficiently within the controller since each command is unique and of fixed length.
Anyway the AT mess does have a very small advantage in testing in that it is human readable. I would love to see the AT interface abandoned in future firmware.
