I am doing a project using Mega2560, and need to use several serial ports.
One of the serial port need a large TX buffer (e.g.128 bytes), but other serial port only need smaller TX buffer (e.g. 32 bytes).
I know I can set the hardware TX buffer size in HardwareSerial.h to 128 bytes, but all 4 serial ports will have TX buffer size of 128 bytes (total 512 bytes), which is a serious waste of memory !
Is there any method to change the individual serial buffer size of Mega2560 ?
There is no need to change the underlying buffer sizes.
Have a look at the examples in Serial Input Basics - simple reliable ways to receive data.
In the examples the constant numChars sets the size of the array for incoming data to 32. You can easily change that to any size you need. Just use a separate function and a separate set of variables for each of your serial ports.
KK959, can you tell what the project is ? What are the baudrates, and how many bytes is the block of data that is received ?
For example with a high baudrate of 115200, it takes 11 ms to transfer 128 bytes. That is not a lot, but during those 11 ms there is enough time to read data from the buffer.
With 9600 baud it takes 133 ms to transfer 128 bytes.
Large buffers are not a waste of memory if you don't need that memory
I can turned that around: you paid for the memory, it is a waste if you don't use it
If you really need large buffers, then you can upgrade to an Arduino Due, and increase the Serial buffer size.
Koepel:
For example with a high baudrate of 115200, it takes 11 ms to transfer 128 bytes. That is not a lot, but during those 11 ms there is enough time to read data from the buffer.
There will be plenty of time at 500,000 baud also.
Thank you Robin 2 for your great tutorial about serial in. But my problem is about Tx !
I use a serial port run at 115200 to communicate with a display module. The communication use command like long text strings. At times when there is more data to send, some text will be missed in the display module. So I think increase Tx buffer may correct this problem. I can't afford increase all 4 Tx buffer because there is less than 30% memory left.
For the suggestion of use a Due, sadly I don't know how to use it, and I think it's learning curve is too steep for me !
The Arduino TX never misses data.
When the TX buffer is full, the Serial.println() and Serial.write() wait until there is an open spot in the software buffer. That will slow down the sketch. Perhaps the sketch will become so slow that it no longer can be used. But all the data will be transmitted, always.
Therefor making that buffer larger does not solve your problem.
Changing to a Due will not solve the problem.
Is the display running at 3.3V ? Is there a signal level problem between the 5V Arduino board and the display ?
Which display is it ?
Is it something like the Nextion displays ?
The display probably uses a microcontroller with hardware UART to read data. Perhaps the buffer in the display is too short, or the microcontroller too slow to read all the data.
What kind of cable do you use ? How long is it ? Can you make a photo of your project ?
Are those long strings really needed ?
How many bytes per seconds are transmitted to the display ?
Perhaps the problem is in the sketch. Can you make a minimal test sketch that shows the problem ? Can you show us the sketch ?
@KK959, we call this a XY-problem. You are looking for a solution, which has not to do with the problem.
DS16(x,y,'Any long strings ....',c); where (x,y) are pixel position.
I know the problem is in the display module, it is not fast enough to receive data. For example, if I write one row of messages, there is no problem. But if need to refresh several rows of data, some data will be missed in the display. On the other hand, if I insert some delay between the data sends, the display is fine.
You may think that I can just use the delay to fixed this problem. But my project is a arpeggiator with real time control and real time display, if the delay is too much, the playback will be sluggish !
Concerning the memory usage, memory is always insufficient for me ! If there is more memory, I can add more features to my project !
KK959:
You may think that I can just use the delay to fixed this problem. But my project is a arpeggiator with real time control and real time display, if the delay is too much, the playback will be sluggish !
Don't use the delay() function. The demo Several Things at a Time illustrates the use of millis() to manage timing without blocking. It may help with understanding the technique.
The TX buffer in the Serial library is to allow that the sketch continues, and meanwhile the data will be transmitted from the buffer with interrupts.
The TJC3224T022_011N is the chinese version of a Nextion display. It has been made specifically for China. If you are from the U.S.A. or Europe, you should get a Nextion version. They have different firmware to avoid that others use the Chinese version.
The default baudrate of the Nextion displays is 9600 baud. I have my Nextion running at 38400 baud.
For uploading new firmware, it does support 115200 baud. I don't know if normal texts allow that high baudrate.
Do you use the Nextion Arduino library ? I am not very happen with that library. That library has many delays and waits for a reply and is slow and could miss data. Using 115200 will not make that library faster. It might make the problems with that library even worse.
I have turned off the reply with "bkcmd=0" and use my own functions to transmit data to the display.
Can you do more tests ?
For example with other baudrates, with the reply turned off and with your own functions.
nexSerial.print( "text1.txt=\"Hell World\""); // text1 is the name of the Nextion item
nexSerial.print( "\xFF\xFF\xFF");
Be careful when changing the baudrate. I have lost my Nextion display a couple of times, because the baudrate was set to an unknown value. I had to write a special sketch that tries evertything with 3% increase of the baudrate.
They seem to run default at 115200.
Perhaps the processer in the display can not receive too much data at 115200. You could send the first part of the text, and use "availableForWrite()" as MorganS wrote, then wait until the buffer is empty, add an extra delay, and send the rest of the text.
Now we know the brand, but not the type of the display and we have not seen your sketch yet.