String stops saving characters when ascii(13) is encountered

Projects General Guidance
1

So i am listening to a serial port and saving the incoming messages into string. Problem is the incoming message has carriage return () in the middle of the messages. This outputs weirdly, I am supposedly to recieve 11 characters. But it would seem that my functions only recieves 2, what makes it even weird is for some reason the counting also stops. My theory is it has something to do with ascii 13, but i could not understand why it also breaks out of the while loop (because the counter also stops at 2)

String   Serial1Buffer;
uint32_t   Serial1BufferCount=0;

while((millis() - startTimeMS <= timeOutMS)){ //reads all incoming messages in 5 seconds
    if (Serial1.available()) {
      Serial1Buffer += char(Serial1.read());
      Serial1BufferCount ++;
    }
}

Serial.println("1 - Count: " + String(Serial1BufferCount) + "\t String: " + Serial1Buffer);

outputs
22:02:47.098 -> 1 - Count: 2 String: AT

now if i modify the code a bit to print directly what is received to serial monitor i get this.

  int count = 0;

  while (Serial1.available())
  {
    count++;
    char x = Serial1.read();
    Serial.print(x);//Forward what Software Serial received to Serial Port
    Serial.print("\t\t");
    Serial.println(int(x));
  }

  if (count != 0) {
    Serial.print("Count: ");
    Serial.println(count);
  }

this outputs the full message : (message below is correct even though it says error)

22:03:26.668 -> A		65
22:03:26.668 -> T		84
22:03:26.668 ->         13
22:03:26.668 -> 
22:03:26.668 -> 		10
22:03:26.668 -> E		69
22:03:26.668 -> R		82
22:03:26.668 -> R		82
22:03:26.668 -> O		79
22:03:26.668 -> R		82
22:03:26.668 ->         13
22:03:26.668 -> 
22:03:26.668 -> 		10
22:03:26.668 -> Count: 11
2

attempting to debug fragments is code is difficult can you give more details
the microcontroller being used
what device(s) are you attempting to communicate with
a schematic showing the wiring
complete code of the test program with serial monitor output

3

I think this is more of a langguuage problem rather than mcu / project based. Try this sample code:
I tied this on a raspberry pi pico using earle E philhower's core

void setup() {
  Serial.begin(115200);
  while (!Serial);
}


void loop() {

  String str ="";

  Serial.println ("Starting");
  str += char(65); //A
  Serial.print(str);
  str += char(84); //T
  Serial.print(str);
  str += char(13); //Carriage Return
  Serial.print(str);
  str += char(10); //Line feed
  Serial.print(str);
  str += char(79); //O
  Serial.print(str);
  str += char(75); //K
  Serial.print(str);

  Serial.println();
  Serial.println("DONE");
  delay(10000);
}

This outputs:

23:09:06.055 -> Starting
23:09:06.055 -> AATATAT
23:09:06.055 -> AT
23:09:06.055 -> OAT
23:09:06.055 -> OK
23:09:06.055 -> DONE

which looks very weird. I mean i would understand it going into the next line once, but multiple times and some repeating characters appears also

4

What is the value of timeOutMS? What is the baud rate?
What you get in the buffer is going to depend on how much is received within the allocated amount of time. Since the input is terminating with a carriage return (13) and linefeed (10), it would be more common to read the input until the linefeed was received, then you know that you have the entire string.

5

Looks correct.
1st print "A"
2nd print "AAT" (initial A followed by AT)
3rd print "AATAT" (initial A, 2nd AT, 3rd AT - serial monitor ignores carriage return)
4th print "AATATAT" (initial A, 2nd AT, 3rd AT, 4th AT, again ignoring carriage return, but now recognizes newline.
5th print "AT newline O"
5th print "OAT newline OK" (initial O from previous print)

6

5000, or 5 seconds, baud rate with the slave device is 9800, baudrate to serial monitor is 115200.

13 and 10 are part of the message, it could appear twice or multiple times in a message. and i know that within 5 seconds the message is definitely over, if it not then something went wrong and the message should be ignored.

putting the whole message in one string makes it easier to split and process the message.

7

ahh then something else might have gone wrong from my original code, since a string can definitely store carriage return and line feed

give me a moment to clean up the full code , minimizing it where the error is still there

8

Here it is

void setup() {

  pinMode(device1_RST, OUTPUT);

  Serial1.setRX(device1_RX);
  Serial1.setTX(device1_TX);
  Serial1.setFIFOSize(512);

  Serial.begin(115200);
  Serial1.begin(9600);

  while (!Serial);

  Serial.print("Initializing");
  delay(1000);
  Serial.print(".");
  delay(1000);
  Serial.print(".");
  delay(1000);
  Serial.println(".");

  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, HIGH);

  initModules();
  delay(1000);
}

void loop() {
}

void initModules() {

  char command[] = "AT";
  unsigned long timeOutMS = 5000;

  Serial.print("Checking modules: ");

  Serial1.write(command);

  String   Serial1Buffer;
  uint32_t   Serial1BufferCount=0;

  Serial1.flush();

  unsigned long startTimeMS = millis();

  Serial.println("Waiting response ");
  while ( (millis() - startTimeMS <= timeOutMS) ) {

    if (Serial1.available()) {
      Serial1Buffer += char(Serial1.read());
      Serial1BufferCount ++;
    }
  }

  Serial.println("1 - Count: " + String(Serial1BufferCount) + "\t String: " + Serial1Buffer);
}

Serial Monitor output is :

23:52:46.345 -> Initializing...
23:52:48.356 -> Checking modules: Waiting response 
23:52:53.372 -> 1 - Count: 2	 String: AT

I can confirm with my scope that there are atleast more than 2 characters being recieved, im counting 11 groups of what appear to be 8 bit transmition.

9

How do you know when the string has ended? In other words, the end of the message?

10

For now , i dont know if the message has ended, that's why i put a timeout in the while loop. after it time's out i count if i have the correct number of bits recieved. Sadly right now only 2 is recieved

11

What will you do later? What are these messages?

12

its a problem for another day, i still dont fully understand the message structure. These are reply from a SIM800L module. The reply is fixed when sending the "AT" command . Either i get a reply of

11 character - "AT(CR)(LF)ERROR(CR)(LF)"
or
8 character - "AT(CR)(LF)OK(CR)(LF)"

For some reason this code:

only sees 2

13

Those are validly terminated by a CR. Why not just read up to the CR, and do it twice? In other words, read two lines..

It really looks like you are wrapped up in problems that you created yourself. Normally, lines like an AT response are just read into a buffer one at a time and processed from there as required.

Reading and processing such lines is more than half a century old, the way you're doing things seems completely disconnected with the simple requirement of parsing responses. That is a really common, standard task and you are approaching it in an unusual, I would even say misguided way.

You're in trouble with CR precisely because you are not respecting the purpose that they are there for.

Lastly, using a time out to terminate a serial read operation will come back to bite you. That is a bubbling pot of problems waiting to happen.

14

Which board are you using? I'm not familiar with the functions where you set up Serial1.
Have you tried using a different name for Serial1Buffer? Any warnings from the compiler about that name being redefined???

15

i have some string manipulation in mind that might be usefull in the future,

Also i did try to do that, the serial buffer is empty. So there is nothing to read, even if i process it as a new line

16

This :

Serial1 is basically the hardware uart of the board. No warnings though, but ill try changing it maybe it did have some conflict internally.

17

Great, but I suggest that this application is not an appropriate one to explore whatever of those you have in mind. You should decide whether that, or making this code work, is more important, right now.

18

How so? I dont really like UART, the start and end of a transmittion differs from device to device and you are forced to implement it yourself. If i dont know when is the end of transmission, will i just forever keep waiting on the data even if its not coming? Isnt a timeout the perfect solution to that?

19

Normally you don't need to know the time of the EOT because you are waiting for a complete message, before you can process it.

The exception, a time out may be desirable in case of failure. But bailing out before the entire message is received, usually means the entire message is useless.

You don't "wait forever". You wait until CR.

20

Not in the case of the AT command set.