USB traffic can exceed hardware's ability to deal with it

[bombasticbob]

In particular, an OUT endpoint configured for bulk transfers (such as for CDC/ACM) can receive up to 3 packets that are rapid-fired at maximum bandwidth from the host, before it starts to lose data.

This typically happens when serial port data is sent one byte at a time. This does not appear to affect commercially available USB serial devices.

it may be a problem with the configuration. it may require special intervention to stop it, such as immediately sending a control packet indicating or proper DCD handling (i.e. indicate 'no carrier' or similar when it's not possible to receive more data). Need to check out how to do hardware flow control properly, at any rate, to ensure that I'm not flooded with packet data.

[bombasticbob]

NOTE: terminal programs may need to either combine more than 1 char per packet, with a kind of 'nagle' algorithm, or deliberately pace it to match the indicated baud rate on the device.

[bombasticbob]

Related to #15, which is now essentially complete

[bombasticbob]

ONE possible "fix" might be to use LOW SPEED rather than FAST SPEED for the USB connection

[bombasticbob]

See #41

[bombasticbob]

A big part of this problem seems to be an "interrupt storm" that happens if the FIFO is not enabled. The manual says that if you write to either the FIFO READ or FIFO WRITE register, the interrupt state is cleared. With the FIFO off, this does not seem to help. So the next step is to implement the FIFO since it seems the peripheral design "wants" that, and is also (apparently) broken when NOT done 'that way'. That was my conclusion from the experiments I did, at any rate.

See #45