add handshake RTS/CTS

[phil31]

i would like to suggest to add a possibility (AT command) to enable or disable an hardware handshake with 2 GPIO : RTS and CTS pins most of the module provide at least GPIO0 and GPIO2. by default, handshake is disable. after boot of the module, we can enable the handshake. GPIO0 stay an input : CTS pin => if active, the ESP8266 can send the message to the CPU

i don't know if it is easily doable with the actual SDK ?

regards

[phil31]

Igrr,

after a quick check on Recommendation V.250., the paragraph 6.2.17 show this command : +IRTS but he conclude to "implementation optional" ..

i think it will be a good feature especially when we debug our application. we often use another UART to send some debug message, then we can miss some message coming from the ESP8266.

please let me know what do you think about this issue ?

thanks Phil

[igrr]

ESP8266 has hardware RTS/CTS, so this should be possible. But i don't know if those pins are broken out on ESP-01 (need to check pinout).

Espressif said that they will release full documentation regarding UART registers in near future. Then I can add support for hardware RTS/CTS.

[phil31]

on the pin definition of the ESP8266, i don't see any RTS CTS mention anyway, the ESP8266 can't check a GPIO before send something ? i mean an software handshak ?

[igrr]

They mentioned some bits in UART configuration registers that correspond to rts and cts here. Maybe those signals are not routed to pads. As I said, I need to check the pinout and/or ask Espressif.

I would like to use hardware support for rts and cts if it is available. If not, then i will have to implement it in software.

And if I go software route, then Xon/Xoff handshare should probably be better. But that needs some more thinking.

[phil31]

XON/XOFF will complicate all stuff.. i agree, hardware will be surely more easy !

yes i read that some RTS CTS bits are mentioned .. but if you check in the document "0A-ESP8266_Specifications_v4.1.pdf" (in the SDK bundle) on §9 Espressif say : Low level protocol functions are handled automatically by ESP8266:

• RTS/CTS,
• ...

so i don't know if these bits are available to any physical pins of the chip .. ?

now, more i test the firmware (your or official one), more i doubt about a reliable solution without handshake RTS/CTS protocol. each time I try to debug something, each time I lose some message (my uart buffer is overlapping). my application require a lot of time CPU. the UART buffer is filled by interrupt routine for sure, but the CPU cant handle the message before another one arrive :( this will come a priority for me. but I understand your effort and you can't do all quickly.

thanks for your time !

[phil31]

well i find a way to fix my issue, using a double buffer. now it's more or less working. but it consume a double RAM buffer on my CPU .. not the better way.

waiting your investigation to know if hardware handshake is doable.

thanks Phil

[igrr]

What is your CPU? How much space do you have in your buffer? If you have less RAM than esp8266, maybe you should consider using esp8266 as your CPU instead. On Nov 11, 2014 12:07 AM, "phil31" notifications@github.com wrote:

well i find a way to fix my issue, using a double buffer. now it's more or less working. but it consume a double RAM buffer on my CPU .. not the better way.

waiting your investigation to know if hardware handshake is doable.

thanks Phil

Reply to this email directly or view it on GitHub https://github.com/igrr/atproto/issues/8#issuecomment-62455237.

[phil31]

no, for a lot of reason i can't change to use the ESP8266 cpu. :(

[phil31]

Hi Ivan,

any update about RTS possibility ? the problem come back when i try to parse the header of an incoming GET request. the request is between 200 and 300 bytes. I can't double buffering and need to parse each received lines, one after one. so without handshake, I lose some lines :(

regards

[igrr]

It is possible, but will require implementing an additional tx buffer on my side, this will take some time. I can add an option to +CIPRD command to read just the given number of bytes. you can then use it to get some amount within your available buffer size. Will that help? It would be relatively easy to implement.

On Wed, Nov 12, 2014 at 6:54 PM, phil31 notifications@github.com wrote:

Hi Ivan,

any update about RTS possibility ? the problem come back when i try to parse the header of an incoming GET request. the request is between 200 and 300 bytes. I can't double buffering and need to parse each received lines, one after one. so without handshake, I lose some lines :(

regards

Reply to this email directly or view it on GitHub https://github.com/igrr/atproto/issues/8#issuecomment-62740328.

[phil31]

i'm not sure to right understand your proposal, but if you propose to send only a limited part of the message (limited by the option value), then the next part of the message will come immediately after the first part.. that will not solve the issue. If fact, i need some time after each line (CR LF end of line) to parse and do some stuff (during an HTML header or during configuration / communication with the module). so I think that only an handshake can help us.. I don't understand why Espressif don't provide it from the beginning ! the ESP8266 UART can work up to 1Mbits .. useless without handshake !

[igrr]

Well this is not a typical problem nowadays because usually hosts are faster than modems and have more RAM. Your case is opposite, more like it used to be long ago when the hosts were slow. Will add "host ready for data" input signal on GPIO0 and "modem ready for data" output on GPIO2.

[phil31]

my CPU is definitively faster .. but she's busy to do a lot of other things that are time critical, with high level ISR. that is not a problem for another project which use an RN171 module (with handshake RTS line). ! but I agree, next project will use a CPU with more of RAM or maybe only the ESP8266, if I have the knowledge to design on it !

Thanks a lot to add at least "host ready for data" input signal on GPIO0. i'm ready to test it ;o) regards

[igrr]

I've made some progress on this issue. Transmitted data is now first sent into a circular buffer, and a separate task pulls data from circular buffer whenever CTS goes high. There are some issues that call for a JTAG, so I'll try to set up a debugging rig next weekend.

[ondra-simons]

Good day all. I have an existing project that uses a PIC micro controller connected to ESP8266 implementing flow control using the espressif AT shield. I have started some work towards building/using the Auto connect web configuration tool. Now that I have it working along with a web client I would like to implement flow control so as to keep with the existing design. I have spent a few days searching for an existing design/implementation. Can someone help me. I would much appreciate it. Thanks in advance