Teensy 4.1 USB Serial connection

I am looking for detailed documentation about the Teensy 4.1 Serial class from the Teensyduino library, but unsuccessful so far.

In particular I am trying to understand when/if/how I can reliably expect communication without information loss.
I am transmitting binary data (the rate I need is approximately 0.8 MB/s). So far I was experimenting with the Serial.write command (and transmit data in batches of ~ 110 kB), which seems to happily transmit. However, the command even works / does not block, if the receiver does not read anything. This seems to imply that I cannot expect that no bit-loss has occured even if the receiver does read data.
Is there any way to ensure no bit-loss?

I also experimented with Serial.flush(), which according to the Arduino-documentation waits for outgoing transmissions to be completed, but this didn't work (it did not block even though the receiver was not reading). So the implementation on the Teensy is probably different?

Can anybody please shed some light on my ignorance?
Thank you.

Here are some basics about Serial ports: https://en.wikipedia.org/wiki/Serial_port
SO, if you looking for documentation, this is a first place to look at.
Means: No serial port in the world gives you the information wether the data was received or not. It just not in the feature-list of a serial port. You can't expect that for any serial port.

USB-Serial emulates a real serial port - there is no feedback wether the data is received or not. It's up to you to implement that, in the application layer.


But there are mechanisms like Hardware-flow-control ("Handshake") that may help you. DTR and RTS are emulated, too. Then, there the normal Arduino-functions functions like available() etc which I guess you know already.
Then, USB has a CRC check inbuilt. So, at least you don't need to check for transmissions errors which can occur with real serial ports (They can even occur on other Arduino-boards with dedicated Serial chip - not so on Teensy) . All received data will be correct. It's up to you to make sure your code is fast enough to handle the very high speed of Teensy, esp.
Teensy 4.x and not to loose any data-packets.

This thing is not implemented in the emulation: It does not emulate the slow speed of a real serial interface. Instead it transfers with full USB speed (which can vary - depends on other devices connected to the USB, Hubs, etc)

Example: PJRC had to modify the original Arduino Serial monitor, because the java-code was not fast enough, it even crashed!

You may want to add some software-handshake.

Hope that it helps
Frank

Serial is for USB virtual serial. Serial1 to Serial8 are for the real hardware serial ports.

Not sure whether you're talking about USB communication or real serial.

Can't see how you're trying things (no code shown), so hard to say why it's not working.

The title says USB

In the past, there were protocols like X/Y/Z-Modem (some better terminal-software still supports them) for file-transfer.
https://en.wikipedia.org/wiki/ZMODEM

Frank B,
thank you for this answer. These facts already clarify a lot. I will read about efficient ways to implement software-handshakes etc.

Paul Stoffregen,
yes, sorry, I am talking about the USB virtual serial.
I will post some code, as soon I have some more concrete questions. Basically I am sampling a signal at around 200 kHz using a DMA buffer, which triggers some code every time the buffer is full (every ~160 ms). Very similar to one of the Teensyduino examples. That buffer I want to write to my PC via USB virtual serial (using Serial.write(buffer, buffer_size) so far).
If by "not working" you are referring to Serial.flush(), I investigated a bit more and my previous statement "it did not block", when evaluated right after Serial.write) is not quite correct. Every 21 times it causes the code to be blocked for a couple of seconds. It also blocks the recipient, although she already received all the data. This doesn't make a lot of sense to me so far, since I thought, if the receiver already has all the data, the buffer must be empty already.
Clearly, there are some things, I do not understand correctly. So I will do some reading until I bother you again.
Thanks for the reply.