ESP8266 Community Forum

- Fri Oct 24, 2014 11:54 am #1915 Mission critical? High speed data flow? As jonsmirl loves to say on this forum, take an rt5350 that runs full linux instead.

And I'm not sure I follow you regarding why mathematical completeness can not be established by DTE in case of AT protocol. Track DCE's state, parse responses, figure out state transitions. Responses are not ambiguous. If esp sends something unexpected, well, it happens, turn off your lawn sprinkler pump and reset the module.

I agree that buffer overruns are a problem. Well, there's xon/xoff flow control for that. I can implement that in firmware, that should be easy.

- Fri Oct 24, 2014 3:35 pm #1917 The AT command set has been developed by the Hayes Atlanta-based company back in 1981 for its Smartmodem 300 bps modems (http://en.wikipedia.org/wiki/Hayes_command_set), 33 years ago! It has been used in "mission critical" situations all over the world, long before DSL and cable existed, over unreliable PSTN and satellites networks. I personally used it on a model 33 Teletype in the earlier 80s with such modems.

Its purpose was to to solve the problem of sending both data and commands over the same physical link, and is still heavily used today as a de facto standard for this same purpose, including in the latest generation 3G or 4G modems.

Unlike what you pretend about its "mathematical incompleteness", the AT syntax is unambiguous and is one of the easiest to parse on low-end processors, please read carefully the V.250 corresponding standard. It can work along with flow control, either hardware or software, so your argument about overruns does not stand.

AT command syntax is actually impressively compact and feature-rich: for example, the exact meaning of the required "AT" prefix is little known, but is in fact an extremely efficient way of performing autobaud / auto parity determination.

The "rigidity of GPS sentences with their well defined start and end and a check sum" (let's call it with its proper name: NMEA 0183) is absolutely not addressing the same problem: it is a one-way protocol whose sole purpose is to report information from one "talker" to several "listeners" and thus does not provide a way to send commands. Using it for at least 20 years, let me say it also has its own quirks, the jungle of proprietary commands and argument formats being the least.

Regarding your "high speed interface SPI with an established master slave relationship" proposal, what exactly is this beast? SPI is a synchronous serial protocol that requires at least 3 wires + 1 wire for each individual chip you want to access ("chip select"), with one single master and multiple slaves, so I don't understand what you mean by "established relationship". BTW, SPI is a hardware protocol like I2C or RS232 UART, not a software one like the AT or NMEA protocols mentioned above.

However, I fully agree with you that the Espressif implementation of the AT protocol is a total big mess: there are a lot of areas where it differs substantially from the V.250 standard and features some remarkably inconsistent behavior that shows the complete lack of knowledge of the AT syntax and its global flow of operation from its conceptors. There is no such thing as "busy" state in the V.250 standard (this is a terrible addition to the AT command set), as are the "chinglish" error messages and lack of the basic AT command sets for controlling status and error reporting, echo management, etc.

Now, if you want to get a "mission critical" reliable operation using the ESP8266, there are basically two paths you can go by:

• develop directly onto the ESP8266 chip itself
• use a sane AT command set implementation like @igrr wrote

- Fri Oct 24, 2014 3:50 pm #1918 iggr
Mostly you are correct in your comments and further you are open to ideas which is even better. I think xon xoff has some value. The MCU behind the esp8266 can't be assured of the completeness of a response it hasn't already been programmed to accept. Ex a spurious set of chars perhaps even a set of random chars is chirped out. When does it end? Well it's unknown...(BTW this argument could be made for any wayward interface)...but when legitimate responses from the esp8266 can have varied length it complicates things. Say, a tolerance timer of no more than x seconds of garbled messaging is imposed by the MCU before it resets the esp8266 via a hardware pin. Either the longest possible valid response time sets the minimum time for the timer or the response has a recognizable terminator and the timer then becomes a fail safe timer. Now the MCU is somewhat tied to the esp firmware (probably not a great issue) but if the esp had a table of numbered responses and commands the table could be dumped to the MCU; the MCU could verify its command and response table is compatible. A new response occurring in an updated firmware wouldn't generate resets since it would acceptable to the MCU but not processable.
The flip side is the esp8266 could finish unexpectedly early in a response ( it was glitched). How long does the MCU wait before going to a hardware reset?
After all the missing chars could just be delayed. The data response +IPD,n also has this issue but at least the MCU knows the number of chars it didn't get within the timeout.
By completeness I mean something like a GPS rs232 chirping the $...* sentence deterministically every n seconds. The sentence has a start and an end so sentences completed or under transmission can exist together in a ring buffer fed by an isr. The MCU parser can easily locate complete sentences via the $ * delimiters and disassemble the sentence's data.
A fail safe timer can be set to reset things if any gap exceeds the time to the next sentence.

Anyway I like the ideas you have in improving the interface and I am grateful you are taking this on, it can only help me.
Thanks.

- Fri Oct 24, 2014 4:14 pm #1919 Squonk
vous avez raison et comme ils dise "impossible n'est pas francais". Alors en Anglais.
I was challenging the AT implementation on the esp8266 mostly out of frustration since I have yet to have achieved a bullet proof implementation of toggling LED's...sure I'm testing and I'm trying to make the communications fail between a PIC 1845k22 at 64mhz and the esp8266. Sadly so far the busy now.... is not always resolved satisfactorily. It appears random at least every hour or two and is proving difficult to debug.
I agree with you AT software obeying the rules has worked reliably for over 30 years.
As to the GPS sentences having a specific name ....many names are trademarked (copyrighted) in the US and require a legal recognition when used on a forum. US citizens have to follow US law no matter where the forum is located. Sure it is a finicky explanation and you were right to name the name but people could be theoretically sued for saying "double click" without permission since a large software company located in Redmond owns the idea.
Anyway vous avez compris comme meme.