Go Down

Topic: Increasing hardware serial buffer size after IDE update (Read 110 times) previous topic - next topic

heinburgh

Hello forum,

I have a project that works very well sending long strings to Ubidots - I increased the hardware serial buffer sizes (RX & TX) to 256 after having issues getting the string through, and after increasing it worked great.

I recently updated my IDE to 1.8.9 macOS version, and obviously overwrote the hardwareserial.h file, so suddenly my sketches that send data to Ubidots truncate the string being sent at the 64th character.

So I went back to the file and edited it to look like this:

Code: [Select]
#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 256
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 256
#endif
#endif


But it still truncates at 64. Then I added these two lines just above the section mentioned above, as per another forum:

Code: [Select]
#define SERIAL_RX_BUFFER_SIZE 256;
#define SERIAL_TX_BUFFER_SIZE 256;


Still no joy.

Can anyone tell me what else I need to do to get my buffers back to 256 bytes?

Thanks in advance!

heinburgh

No I realise the correct way of doing this is to give the buffer chance to empty itself at its own pace, so I tried changing this snippet:

Code: [Select]
Serial1.println(postRequest);
      Serial1.flush();


with this, in an attempt to "do the right thing."

Code: [Select]
int reqLen = (postRequest.length());
 for (int z = 0; z < reqLen; z++)
      {
        Serial1.print(postRequest[z]);   
        delay(5);
      }
      Serial1.println();


The result is exactly the same - string cuts off at 64'th character.



heinburgh

Ok, for the other mac owners out there - the solution is to find THE RIGHT VERSION OF THE FILE!

instead of opening up your Arduino package and going to:
 contents/java/hardware/arduino/avr/cores/arduino/hardwareserial.h

you need to go to:
 user/library/arduino15/packages/arduino/hardware/avr/1.6.23/cores/arduino/hardwareserial.h


pert

Thanks for taking the time to post an update heinburgh. You're definitely not the first to run into this. Note that for some people the active version of HardwareSerial.h will indeed be under the Arduino IDE installation folder. It depends on whether they have installed Arduino AVR Boards via Boards Manager or not.

The easiest way to find the active hardware package location is as follows:
  • Select a board from the hardware package you want to find from the Tools > Board menu
  • File > Examples > SPI > BarometricPressureSensor (or any other SPI example sketch)
  • Sketch > Show Sketch Folder
  • Move up folder levels until you reach the one that contains boards.txt. HardwareSerial.h will be under the cores/arduino subfolder.

heinburgh

Thanks @pert, appreciate the tip.

But to get back to the root of the problem, how do I TX the serial data to a sim800C modem in the correct way? I'm dealing with IOT and TX / RX from Ubidots can get tricky if the strings get larger that 256 bytes, which is the case most of the time.

Like I mentioned earlier in this thread I tried to slow down the transmission to the modem with different time settings, but nothing.

pert

The only problem with transmitting strings longer than the buffer is that the call to Serial.print() will block the execution of the rest of your program until there is enough space in the buffer to hold the remaining unsent portion of the string. If that blocking behavior is a problem, you can use Serial.availableForWrite() to determine how much free space there is in the TX buffer:
https://www.arduino.cc/reference/en/language/functions/communication/serial/availableforwrite

As for receiving strings larger than the RX buffer, that is certainly a problem. Once the buffer is full, any incoming serial data is simply discarded. The only solution to that is to try to receive the data as fast as possible by communicating at the highest baud rate you can and disabling interrupts as little as possible.

Go Up