Serial Receive data rate much lower than expected

I looked into that. I don't think it works that way. I think the 128 byte serial buffer is a hardware limiation.

I'm pretty sure the serial library is where the circular buffer is defined and managed.


Although I am at a bit of a loss to understand why you are willing to lose data, and have little capability to process the data so fast. I would drop the hardware serial completely and drive the USART registers direct with no buffer or interrupt to achieve maximum throughput.

For driving Dynamixel servos from the UART, we have different code which is interrupt based, but adapted to the protocol. This runs at 1Mbps baud rate, but a max transfer size of 256 bytes.

Would you be willing to post your adapted USART code so I can compare it to the original and see what sort of modification might be required for my purpose.

I finally got my project working. It's for Streaming Audio over Serial. I've posted the code for the project here:

I'll still be trying to modify the USART to see if I can improve performance and buffer size. Maybe I could eliminate the need for a second circular buffer by doing so.

So many misconceptions all over ... Nevertheless: The indexes into the receive buffer in HardwareSerial are ints so there is no limititation to the buffersize; just change it RX_BUFFER_SIZE Bytes are written without any software buffering, it waits until the xmit buffe ris available. This is the fastest method possible, though not the one with the best throughput, because it is blocking. It will not allow the perfect parallelism of transmitting and generating the bytes to be sent, but a good performance on the average.

I modified the RX_BUFFER_SIZE in HardwareSerial.cpp. This allowed me to buffer enough sound samples to allow smooth audio playback without needing an extra circular buffer.

Unfortunately, there is no way to read (or set) the RX_BUFFER_SIZE at run time, which is really sad. Perhaps the Arduino core could be updated to include Serial.GetRXBufferSize() and Serial.SetRXBufferSize methods.

There would be some restrictions on that though, as I've already run into while playing around with the RX_BUFFER_SIZE in HardwareSerial.cpp. For example, the Serial.available() method returns a unsigned 8-bit integer, which will not work if the buffer size is increased above 255 bytes. It would have to be upgraded to a unsigned 16-bit integer, but that takes up more ram. Several variables would need this sort of upgrade, in turn increasing the overall RAM requirement.

So I totally understand why the limitations are in place... the variables are chosen very wisely to save system resources. It's just not very flexible to accomodate larger bandwidth needs.

Don't feel so pessimistic! The available() bug has escaped me while reading through the code. This has nothing whatsoever to do with memory consumption. It is a plain bug!

Do not hazitate to correct it! This will have hardly any consequences and will break none of your existing code. Most people use available() as boolean anyhow, not as the number of elements in the buffer.

AFAICS there are no further bugs in the code that would avert the use of a large buffer..