The death of Xon/Xoff flow control...

[magic]

This looks like it's supposed to work, at least on the transmitting side. But are you running this before or after starting the terminal emulator?

As I said, minicom simply disables all flow control when it starts and I found no way to change that without running stty again

[m k]

Found Belkin F5U103v 067B:2303
XP Pro SP3 with ser2pl.sys 2.1.51.238 is fine.

lubuntu 18.04.6 LTS 4.15.0-204-generic
stty -F /dev/ttyUSB0 1200 raw pass8 ixon
cp [file] /dev/ttyUSB0
No, Xoff sent, but transmit not stopped.
(stop = ^S)
'sane' setting didn't change anything.
Stuff moves to both directions, cp /dev/ttyUSB0 [file] is fine.

HP OEM Asus K8S-LA (SiS 760GX), puTTY not starting, can't open port.
Downgrading, can't remember the size of 's' of default puTTY serial.

[nctnico]

I just tried: if you turn software flow control on in minicom, it will configure the port to enable xon/xoff flow control. It is just that minicom doesn't restore the old stty values on exit.

[m k]

Downgraded to lubuntu 14.04.6 LTS 3.13.0-13-170-generic.
Same machine.

puTTY still nagging that ttyS0 is no good.
cp [file] /dev/ttyS0 is fine and Xoff supported.

Belkin 067B:2303 is still the same, no Xoff.

Packard Bell OEM MSI MS-6786 (VIA KM400A/KN400A)
lubuntu 14.04.6 LTS 3.13.0-13-170-generic and
lubuntu 10.04 LTS 2.16.32-21-generic
same thing, Belkin 067B:2303 no Xoff.
Standard port is fine.

[m k]

HP Maverick Silverado Rev 0B (Intel Q965)
lubuntu 16.04.6 LTS 4.4.0-185-generic
Belkin dongle still bad and standard port good.

My give up.
It's not the other hardware, these Prolific drivers just don't work.

Also found brainboxes VX-001B ExpressCard dated 17/8/11 and HP DV6 Vista has a port.
I think I'll pass.

[free_electron]

because people appearantly no longer care about having working flow control.

old protocol to circumvent latency (xon/xoff) over another old protocol (serial port) shoehorned on a packetized bus with more latency.

Why don't you make a proper USB device ? i know the answer... because then YOU have to provide all the drivers for all the platforms. (I face the same problem.)
We keep encountering uart style transport over usb because of the immense task of making USB drivers for a plethora of operating systems. (and the associated issues getting them certified and whcl approved so the OS will allow them to run)

Can you use a HID type device ? then you don't need drivers.

[nctnico]

A HID style device can't be used with a terminal emulator program. It may be old school but using a serial port and a terminal emulator takes away a lot of effort to create a way for development and debugging as it uses mature technology which is widely supported and available for any platform (including mobile phones)  You are right about not wanting to create custom drivers.

[PlainName]

Can you provide an Ethernet interface instead of serial? Then it would work with any network, as do most terminal apps, and use TCP flow control.

OK, a bit more onerous than a serial port but you wouldn't have to write any drivers, and it would work to practically anything (even wireless with an appropriate dongle).

[nctnico]

Can you provide an Ethernet interface instead of serial? Then it would work with any network, as do most terminal apps, and use TCP flow control.

No, because that would require configuring a network and thus a user interface (=serial port for example), having extra electronics, etc, etc. It is a complete non-starter. Bringing a serial port out is just a matter of extra test pads. The ethernet parts alone costs more than the entire BOM for some of my designs.

[Nominal Animal]

Do remember that it is only passing the full flow control settings from host to device that does not work with plain CDC ACM.

If your USB microcontroller is hard-wired to another microcontroller over UART, or only supports a fixed set of settings (baudrate, parity, stop bits, flow control), the USB microcontroller can simply ignore the serial port settings the host provides, and always use its own fixed settings.

[m k]

Maybe original idea was a partial connection.

Is raw text print available?

[m k]

Seems that the easiest thing is a pass through port and own sending script.

while (all not sent) {
 while (something received) {
  receive character
  update Xoff status
 }
 check Xoff status
 if (not Xoff)
  send character
}

[Nominal Animal]

For what it is worth, I blundered into a very interesting yet cheap way to fix the problems at the hardware level.

WCH CH32V203C8T6 is a Qingke V4B RISC-V MCU in LQFP48, which has two full-speed USB interfaces, but costs less than $1€ in singles at LCSC (and Aliexpress).  It does not require a crystal; a 3.3V regulator and two 100nF X7R supply bypass capacitors suffice.  However, it does have four UARTs, two SPI, and two I2C.  See Stefan Wagner's CH32V203 F6P6 development board as an example, one using the F6P6/TSSOP20 variant.

On the C8T6, one can use both USBs, I2C1 (SCL on 45/PB8 and SDA on 46/PB9, alternate configuration), USART2 and USART4 (RX, TX, CTS, RTS), SPI1 (NSS, SCK, MOSI, MISO), and either SPI2 (NSS, SCK, MOSI, MISO) and I2C2 (SDA, SCL), or USART3 (RX, TX, CTS, RTS), at the same time.

The idea is simple: you have a small device exposing aforementioned pins.  One USB device (USBD) is the bulk data interface.  The other USB device (USBFS) is an optional one, and provides a terminal console (using standard ANSI escape codes) where one can interactively configure and monitor the bulk data interface, for example using Minicom/PuTTY etc.  You don't need to use the console interface, unless you wish to configure the bulk interface, but the configuration interface could for example make certain things, like say baud rate, to some fixed value, having the bulk interface lie to the OS.  Useful in cases where you like a specific terminal software, but it has issues setting all the settings the way you like, or the driver does things you don't like.  I'd add an I2C EEPROM like M24C01-RMN6P or M24C08-RMN6TP for about ten cents, to store the configuration without wearing down the Flash on the MCU.  In all, I calculate the BOM cost to be less than 2 USD/EUR.

In Linux of course, one can do the same thing just using different CDC ACM endpoints and udev rules to identify them.  Here, the two USB devices can have different Vendor:Product and/or Serial, identifying which is which on all operating systems, even Windows, when still using the generic/class CDC ACM drivers.

Two separate USB devices also makes for interesting shenanigans, since each USB is limited to about 1 Mbytes/sec data throughput.  For example, for a custom bulk SPI stuff, one could use one USB for outgoing data, and the other for incoming data, for sustained continuous SPI transfers at about 8 MHz, effectively doubling the full-speed USB bandwidth.  Also, resetting/reconfiguring the bulk data interface for a different set of endpoints won't reset the configuration interface, because they are separate USB devices.

[magic]

With an MCU you can make your own USB-UART bridge which always obeys flow control regardless of host software settings. It could even implement CDC to work everywhere.

[westfw]

make your own USB-UART bridge ... It could even implement CDC]/quote]
You haven't been paying attention.  If you implement CDC, there's no way for the host-side software to turn flowcontrol on and off.
I guess that would be OK, if you're willing to have it turned on permanently, or via a HW jumper, or some magic UART sequence on the device side, but it's certainly not ideal.

(oooh... there's an interesting topic.  How and what commands would you implement on the UART side of such a device, if you want to also maintain full 8bit data transparency "most of the time."  BREAK comes to mind; Both the bridge (if a microcontroller) and target (probably also a microcontroller) should be able to create and measure timed BREAK conditions.)
Edit: likes like UARTS with LIN support may already do some of this - BREAK 0x55 is apparently supposed to help do autobaud.)

[Nominal Animal]

It's all about making it easier to set and override software settings for the hardware serial port.  USB CDC is wonderfully easy to use, but insufficient for setting flow control on the device itself.

BREAK condition is when the data line is asserted low continuously, for longer than a full symbol.  Following that with 0x55 gives you four one-bit wide high pulses immediately following the low.  This is sufficient for baud rate detection, as the timing is not that strict (±5%, although many prefer to get within ±1%).

For a continuous UART output, a timing histogram of the shortest bit durations can be used for baud rate detection.  This is slightly more complicated if one wants to be robust against glitches; plus the fact that stop bits can be 1, 1.5, or 2 bit times wide.

[Jeroen3]

I'm in a bit of a pickle with a project which needs to receive large amounts of text (more than anticipated) but it can't keep up with processing and buffering is not practical.

Maybe I'm kicking in an open door here, but if the baudrate is too high to keep up with on the mcu...
What if you lower it?

[magic]

Then the firmware upgrade takes longer
And you must be damn sure that programming a page will never take longer than expected, because RX buffer overrun would result.

By far the best option is to have more RAM than you have flash