Effective Xon/Xoff flow control?
Publison
Posts: 12,366
This discussion was created from comments split from: Prop2 FPGA files!!! - Updated 20 December 2017 - Version 30a.
Comments
I'm using - no I'm enjoying - tachyon with P1 and one thing I'm definitely missing is flow control. Although Peter stated above that there currently is no fiddling with newline delay and character delay on the P2, I'm sure in future there will be.
From my point of view the lack of flow control would avoid unmanned builds which is inconvenient in times of robots ...
Best regards,
proplem
I think of an unattended build for different hardwares connected via UART or USB. Think of the situations where you @Peter plugged around different hardwares to reproduce problems we were asking for? If you could build for all hardwares in parallel without manual interference wouldn't this be a huge advantage? Or think of an automated build for users: download the files from dropbox/github and building automatically. I'd appreciate that very much.
Would it be impossible to implement a driver for windows and/or linux which is flow controlling correctly?
P2 should implement this - the pc side can follow if it is only software.
Right?
Test was to loop back, set 4MBd and send 500k chars. With flow control disabled, this fails badly, with it enabled, 500k arrive fine. Averaged duplex baud is something over 2MBd, due to flow control working.
Parts like FT232H/FT2232H have larger buffers and faster Max baud, so another way to manage flow control is to keep the chunks below the buffers and software ack.
The Bridge device can support hardware flow control, however to operate as you describe as a byte-code system over a live serial link, I think Tachyon needs to include hardware handshake features.
Does it do this ?
Probably best to include both-way support, even if P1 is unlikely to saturate an up-link, a P2 certainly could.
CP2102 specs say RTS Hi for > 448 bytes (of 512 buffer), Lo for < 384 Bytes, and CTS (in) says The CP2102N will not send more than two bytes of data once CTS is pulled high.
It is also possible to change the settings for the port to trim the length of the internal FIFO but a lot depends upon the O/S too. I will have to play with this to see what I can get away with but unlike the P2, the P1 does not have much memory to play with and even 1K for a seldom used buffer is an extravagance.I have had this P1 buffer dynamically resize into file buffer area but it gets messy.
Hmm, ok, I've not tested XON/XOFF, but the CP2102N info says this - hints 64 is the smallest ?
"Software handshaking uses the same watermark levels as hardware handshaking and can be configured dynamically by host software.
Watermark levels greater than 512 are converted to an XON limit of 448 bytes and an XOFF limit of 512 bytes. If the XON limit crosses over the XOFF limit, the XON limit will automatically be modified to not cross over the XOFF limit. An XOFF limit of 0 is converted to 64 to guarantee buffer space is available until the UART end device stops transmission. When setting the XON and XOFF limits, it's recommended to use values where the XON limit added to the XOFF limit is less than 512 bytes, like 192/192 or 128/128.
CP2102N testing shows that the XON limit set to 192 and XOFF limit set to 192 provides optimal software flow control behavior."
I can try the same thing in Windows with TeraTerm and I can even change the FT232R buffer levels to 256/256 vs 4096/4096, enable soft handshake, and try again. Not a sausage. Obviously none of the serial drivers seem to support it, but of course with such large buffers in the USB chips the handshake needs to be handled directly by the FT232R.
BTW, I tested this on Tachyon V4r7 but with a special version where I could change the size of the receive buffers up to 2K. There is an XOFF sent after the first CR received during a TACHYON (no echo) block load and an XON is only sent once the buffer is exhausted etc.
Now I will give the CP2102 a go and see what happens. I vaguely recall going through this exercise many years ago and giving up in disgust.
EDIT: I think I will see how effective hardware handshake is as I really only need the one line back to the serial port. I'll test it out first with a direct I/O from the Prop and then I might add a tiny PIC12F1572 to intercept an XON/XOFF and have it handle the hardware handshake rather than the Prop, just so I don't need to change anything on my Prop boards.
Note the part I quoted from & tested is the new CP2102N, (upgraded MCU version of CP2102, faster and (re)config is now flash, not OTP) - there is now a low cost CP2102N-MINIEK module.
It also says this :
If the CP2102N receives an XOFF request, it will stop transmission, even if the CP2102N receiver needs to transmit an XOFF over
UART. This can potentially allow an overflow to occur or a deadlock condition if both the CP2102N and the connected UART device
transmit XOFF at the same time. The XOFF_CONTINUE setting allows the CP2102N transmitter to send XOFF/XON requests even if it
has received an XOFF request from the connected UART device. Once the connected UART device transmits XON, normal transmission
from the CP2102N resumes.
I think that means the CP2102N both manages XOFF internally, & can pass-thru the XOFF. (so you need to set P1 and CP2102N for the same XOFF )
XON comes from the P1, and is acted on by the CP2102N, which feeds from the local buffer.
The CP2102N at least discusses watermarks and conditions when it says it handles soft handshake whereas the FT232R says it handles it in hardware for "fast" response but says nothing further about it and neither does it seem to be effective. The FT232R chips I use are from an approved distributor so they're not fake chips either.
However in spite of a lack of flow control I find P1 Tachyon quite snappy and it only seems to need a few milliseconds line delay. In contrast there is MeCrisp Forth that I have run on ARM chips and despite hardware and interrupts and stacks of RAM it still needs very generous delays, even character delays I find, on 200MHz+ ARM chips!. P2 Tachyon of course has plenty of RAM to spare and doesn't need any delays of any kind, even at 3M baud.
Hi, perhaps this interesting for others:
I just discovered, that meanwhile with Windows 11 + Teraterm + FT232RL USB to serial it is now possible to get Xon/Xoff. You have to activate the protocol in Teraterm EDIT: in the Device Manager ! and you have also to reduce the USB buffer size of the com driver from 4096bytes to 64bytes in the Windows Device Manager. The following code for Taqoz 2.8 peeks in the serial buffer and sends Xoff, if more than 50bytes are in the buffer. Xon again for <10 bytes. The maximum filling is then reduced to about 110bytes of 768bytes. If I switch off the protocol in Teraterm, I get the overrun again.
Background was, that I wanted to paste longer text directly into my editor at 921600baud.
Have fun, Christof
long bufFullFlag bufFullFlag ~ long bufFullMax bufFullMax ~ : xonXoff \ check filling of serial buffer and emit xon xoff 32 cog@ 31 cog@ > if $300 32 cog@ 31 cog@ - - else 31 cog@ 32 cog@ - then dup 50 > bufFullFlag @ 0= and if bufFullFlag ~~ 19 emit then dup 10 < bufFullFlag @ and if bufFullFlag ~ 17 emit then bufFullMax @ maxs bufFullMax ! \ %savePos \ 80 2 %XY %yellow %pen . %plain \ %restorePos ;Hm, does not work soundly. Sorry.
Edit: if you activate Xon/Xoff in the Windows Device Manager it seems to work much better.