Hardware flow control

[f1ac0]

Hello,

I have tried your firmware on my Amiga computer using the following guide :
https://blog.nootch.net/post/amiga-bbs-online-2019/
With few additions on the Amiga side :
enable a "ignore DSR" feature, disable "Carrier detect" and use the "New8N1" serial driver.
I am impressed by the result and I would like to thank you for sharing your work.

I am able to communicate up to 115200 bauds.
However my tests show that the operation above 38400 is not reliable (on my system running a 68020@33MHz).
I believe the reason might be the lack of flow control.
Would it be possible to add hardware flow control to your firmware ?

On my adapter (which I used previously with the Zimodem firmware), here are the actual connections:
CTS of the host to GPIO15 (RTS of the router)
RTS of the host to GPIO13 (CTS of the router)
and also Ring on GPIO2, DSR of the host on GPIO5 and DTR of the host on GPIO4, however these are not essential.

[martin-ger]

I am not aware that the serial driver supports RTS/CTS. Maybe somebody knows or I would have to dig deeper into it. Currently I will hardly find the time for that.

[f1ac0]

Actually most ESP pinout cheat-sheets have RTS and CTS signals for UART0, on the pins that I stated in my previous post
https://www.pinterest.com/pin/747738344362958328/
https://stackoverflow.com/questions/46722951/wemos-esp8266-function-while

As you said, it might be a hardware feature of UART0 (however in the Zimodem that I used before they were implemented in software, and also reversed in the default configuration at that time).

[f1ac0]

An addition to my previous message, yes there seem to be a hardware flow control. there is sample code and links to docs from espressif in the pages of this post : https://www.esp8266.com/viewtopic.php?f=27&t=8560&start=8
Those pins seem to be hardwired, not possible to relocate them.

[f1ac0]

Here is an update and a good news after I had a look inside the source files.

A configuration to enable hardware flow control is already available in include/driver/uart.h !
I recompiled with UART_HW_RTS 1 and UART_HW_CTS 1.

slattach does not work anymore with it, even with removing the -L argument (I guess it would also need a carrier detect signal).
However it does work in the Amiga with hardware flow control enabled !
The baudbandit.device serial driver now also works with it (it requires this hardware flow control),
I am now able to use it up to 57600 bauds with big files downloads. 115200 still has problems when load increase.

Something worth to mention : configuration data is kept when flashing the device again. This is convenient when testing.

[martin-ger]

That's great news! Thank you for digging around! I will mention that in the Readme.

[bartekre]

I can confirm that after enabling RTS/CTS it works nicely with https://github.com/cnvogelg/plip2slip at 500000 bauds.

slattach does not work anymore with it, even with removing the -L argument

Out of curiosity, what UART adapter did you use? I was able to get it working with FT232R, also at 500000 bauds, so it doesn't seem to be an issue with ESP or the firmware.

[bartekre]

Sorry for necroposting BTW, I didn't realise it's already 2021 😉

[doughamm]

Hi all -- I'm unable to build the RTS/CTS myself, but would appreciate if flac0, bartekre, or someone could do so for me and post a link, if just temporary. Thanks in advance!

[bartekre]

Hi all -- I'm unable to build the RTS/CTS myself, but would appreciate if flac0, bartekre, or someone could do so for me and post a link, if just temporary. Thanks in advance!

This project relies on esp-open-sdk which is not maintained anymore, but there are some old docker images which should do the work.
try larsks/esp-open-sdk with the following parameters for make:
XTENSA_TOOLS_ROOT=/tools/xtensa-lx106-elf/bin
SDK_BASE=/tools/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/usr
SDK_LDDIR=lib