What is the maximum number of bytes that can be sent through USB-to-serial COM port at one go?

Suppose someone uses hyper-terminal to send a very long ASCII string at a COM port. This COM port is created by FTDI USB-to-serial port cable. The cable used is http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232RG_CABLES.pdf.

Is there a limitation imposed by the UART driver for PC? For example, Arduino UART tx buffer is 64 bytes only.

What is the maximum number of bytes that can be sent through a PC serial port at one go?

• Which chip specifically? – Ignacio Vazquez-Abrams Jul 6 '15 at 4:46
• – user768421 Jul 6 '15 at 4:48
• May I know why the negative vote? I am new to electronics stack exchange and not familiar with the culture. Can the person who downvote explain? – user768421 Jul 6 '15 at 4:49
• What do you mean by "at one go"? - Do you mean without blocking the write system call? – JimmyB Jul 6 '15 at 10:39

In full-speed USB, the maximum packet size is 64 bytes.
In high-speed USB, the maximum packet size is 512 bytes.

Most USB/serial converters, including yours, use full speed.

However, if you are looking at the serial output, the USB packet size does not matter, because USB packets can be sent faster than the speed of the serial line, and are buffered. For example, if the PC sends 100 bytes, it will use two packets, but what you are seeing at the other end, on the serial line, is again a continuous stream of 100 bytes.

Similarly, if you are sending data from an Arduino, you can buffer a new TX byte as soon as some previous byte is being sent, so the size of the TX buffer does not really matter. (However, a larger buffer size allows the pre-buffer more data, which allows continuous transmission even if the microcontroller must do something else for a longer time.)

PCs, most microcontrollers, and USB/serial converters are fast enough so that the only bottleneck is the speed of the serial line, so you will never see a gap in the data, regardless of how many bytes are transmitted.

• FTDI can be a bootleneck if your microcontroller support USB. – MathieuL Jul 6 '15 at 18:44
• The USB bus may in these cases be limited to transferring 64 bytes at a time, but that doesn't mean necessarily mean that the driver layer will not accept larger chunks. – Chris Stratton Aug 10 '16 at 20:19

Hyperterminal is a Windows-specific software program, so I don't think this is really on-topic, also it has been deprecated- it is no longer bundled with any supported version of Microsoft Windows.

Anyway, there is no practical limitation. Set it up to talk to a COM port and you can send a text file of just about any size (or a binary file via the Xmodem and other ancient protocols of the saintly days of yore). If you sent a 2G file at 9600 baud it would take a month or something like that. Nevermore.

As many as the involved chips can actually store.

Go back 20 years: Back then, modems were attached to a PC via a COM port. The "Download" was basically a stream of data which was only limited by phone fees :-)

• I thought there may be a limitation imposed by the driver. For example, Arduino UART tx buffer is 64 bytes. I was wondering if the same applies for PC serial port. – user768421 Jul 6 '15 at 4:50
• As long as the buffer can be emptied faster than it fills up, the buffer size doesn't limit the amount of data sent or received. – The Photon Jul 6 '15 at 4:57
• As you say, that's the buffer. If you manage to read the buffer in time, it will never fill up fully and your device will always be ok to receive data. The typical PC port contains a buffer as well (see ComputerManagement -> Your Serial Port -> Port Settings -> Advanced). Again, the same applies. Make sure you read it in time and you can receive data endlessly. – Tom L. Jul 6 '15 at 4:57
• -1: there is no need to store anything, the receiving chip might as well calculate a checksum on the fly and otherwise drop the bytes. – Wouter van Ooijen Jul 6 '15 at 6:21
• Unless you put only one payload byte in a USB packet buffering is required between the USB and UART. Your comment is posted as a criticism of an answer (a mistaken criticism at that) not a response to the question. – Chris Stratton Aug 16 '16 at 20:04