ESP8266 Developer Zone

Re: Flow control and AT protocol

2017-04-26T22:55:54+08:00

It is no important is there a long input buffer! The important thing is that the WIFI module have not any software follow control! It will be simple if some response to +IPD is need. For example simple ACK(6). No every master is a PENTIUM 3GHz with 8GB RAM!

Statistics: Posted by CALLm151 — Wed Apr 26, 2017 10:55 pm

Re: Flow control and AT protocol

2016-08-21T21:46:55+08:00

hmiezin wrote:
Are you sure that UARTS stores characters in an internal HW FIFO ? Do you think that the UART in the ATMEGA328 has such a buffer ? Do you know which length it is ? I carefully read the ATMEGA datasheet and never saw anything about this.

RTFM. ATMEGA328 datasheet, clause 20.11.1 UDRn – USART I/O Data Register "The receive buffer consists of a two level FIFO."

hmiezin wrote:
This is exactly what I experienced with the WS2812 ledstrip which is 3 wire asynchronous, the control is done by a single digital output with very fast logic requirements.

Use SPI output to drive WS2812. One byte at SPI output can form two bits for WS2812.

Alternatively you can use PWM output to generate accurate timing for WS2812.

Statistics: Posted by akouz — Sun Aug 21, 2016 9:46 pm

Re: Flow control and AT protocol

2016-08-21T07:06:07+08:00

Hello, Akouz, and thanks for responding,

There is a point I do not get in your answer.

Are you sure that UARTS stores characters in an internal HW FIFO ? Do you think that the UART in the ATMEGA328 has such a buffer ? Do you know which length it is ? I carefully read the ATMEGA datasheet and never saw anything about this.

Of course, in my software, UART Rx is processed in an ISR where characters are stored in a SW FIFO. But it still means 175µS between 2 rupts. If for some reason, a time critical function masks interrupts for more that 175µS, we are dead !

This is exactly what I experienced with the WS2812 ledstrip which is 3 wire asynchronous, the control is done by a single digital output with very fast logic requirements.
I agree with you that I can certainly solve the problem with a 4 wires synchronous ledstrip (LPD8806 or other).

To be honest, I find that it is a pity that the choice of our lestrip HW is only related to some strange choices in the ESP8266.

So, we are thinking of replacing the ESP8266 AT firmware by a home made specific firmware, just matching our needs.

Henri

Statistics: Posted by hmiezin — Sun Aug 21, 2016 7:06 am

Re: Flow control and AT protocol

2016-08-19T15:13:02+08:00

hmiezin wrote:
If the UART is 57600 baud, this means that each char is ~175µS. If, for any reason, the application microP is busy more than 175µS (which is something quite short !!), characters will be lost.

No, it won't. All UARTs store received chars in their internal FIFO. Process UART Rx by ISR to ensure that received char is not lost.

hmiezin wrote:
For instance, forget any ledstrip in your app, because you can not process highly accurate timings required by those devices (this was my project)

Use SPI to drive LED strip. SPI hardware use to have FIFO too. Also use ISR to serve SPI. Then it would not be problems with timing.

Statistics: Posted by akouz — Fri Aug 19, 2016 3:13 pm

Flow control and AT protocol

2016-08-18T17:43:20+08:00

All those requests found on forums about xon/xoff implementation in the esp8266 are symptomatic. Everyone now is aware that HW flow control proposed by Espressif is just impossible to use because RTS/CTS are not present on the major part of ESP modules connectors. HW flow control has a cost, XON/XOFF has not.
Am I right ?

But if we go further, we rapidly find that we have a problem somewhere else with the ESP8266, in the area of processing asynchronous events with the +IPD message.

Think of an asynchronous UDP message arriving from the WIFI on the ESP8266. As soon as the message is ready, the ESP8266 will send +IPDxxx to the application micro P. If the UART is 57600 baud, this means that each char is ~175µS. If, for any reason, the application microP is busy more than 175µS (which is something quite short !!), characters will be lost.
This is a very high constraint for the applicative software .
For instance, forget any ledstrip in your app, because you can not process highly accurate timings required by those devices (this was my project) !!

On top of this, I have doubts on the protocol definition on the asynchronous link.
Let me explain.
Most frequently, the protocol is QUESTION/RESPONSE (AT command from the APP -> answer from the ESP). Good ! master slave relationship always make things simple (pls do not see any political background)
But there one exception is IPD, which can be considered as a RESPONSE without QUESTION.
Then immediately I wonder: what happens if the ESP8266 wants to signal an IPD during a question ? The documentation is not clear about this .
Am I wrong ?

As a result, the underlying complexity and lack of documentation on protocols makes a good design of the application almost impossible.
And the lack of flow control makes the implementation of the application very hard.
At the moment I feel the ESP8266 is a nice thing to play with for very simple apps (temp sensor, remote control…).

Can I make a suggestion ?
Let the protocol stick to master/slave communication only. This will not solve everything but it makes the application design so simpler ! and you can avoid flow control because you only receive what you asked for.
For example , just add those 2 AT commands in the firmware, and forget spontaneous transmission of IPD by the ESP8266. Or make it configurable.

Command AT+IPD_STATUS
Possible answers
NOTHING_PENDINGnothing pending
IPD_PENDING,1,OKone IPD is pending concerning channel 1, no error
IPD_PENDING,1,OVERRUN,2,OKone IPD is pending concerning channel 1 in overrun (some channel 1 data have been lost). IPD pending also for channel 2, no error.

Command AT+IPD_READ, channel
Possible answers
ERROR (if no IPD pending)
+IPD:xxxxxx (same as now) if the IPD is really pending

Thank you i advance for your replies

Nri

Statistics: Posted by hmiezin — Thu Aug 18, 2016 5:43 pm