Is there better way to remove '\n' character from Serial Buffer while executing Serial.readBytesUntil() function?

Projects Programming
21

readBytesUntil() only times out if it doesn't see the specified terminator character
so why not just specify the "control" char that is at the end of the number?

22

It is of course up to you to use ReadBytesUntil or a different way... Whether the timeout appears or not finally depends on the application.

I'm not arguing against the use, just answered your question :wink:

23

long story short that's the answer to the question why it does not work

24

I don't know if I miss something, but I had just a peek at this topic and the problem seems to me pretty easy. I'd like to summarize the problem here (more than 20 posts are too many for this to be described ;-))

If you enter "1234.56" it's a 7 characters string, so it is 8 bytes long together with '\n': as "sizeof myData - 1" is equal to 7, readBytesUntil() won't wait for the terminating character and returns immediately, and in this case you get the value 1234.56 on the Monitor. But the '\n' is still inside the serial buffer, so the next loop will get inside the "if (n != 0)" because "n" is 1, then the next "readBytesUntil()" immediately recognises the terminating byte, thus returning nothing, and "m" equals to zero, so the atof() of a null string is zero.
Test it here:

char myData[8];

void setup()
{
  Serial.begin(9600);   //to enable serial link between PC, SM, IDE, UNO
  Serial.println("START");
}

void loop()
{
  byte n = Serial.available();
  if (n != 0) //there is at least one character in Buffer
  {
    Serial.println("loop");
    byte m = Serial.readBytesUntil('\n', myData, sizeof myData - 1); //'\n' is not saved; m =
    
    Serial.print("m=");Serial.print(m);Serial.print(" myData=");
    for (int i=0; i<sizeof myData; ++i) {
      Serial.print(myData[i], HEX);
      Serial.print(" ");
    }
    Serial.println();

    myData[m] = '\0';         //insert null-chracter at the end of string array
    //---- reconstruct 1234,56 from the recived ASCII coded 1234.56 -----
    float y = atof(myData);  //atof()= ASCII to float function
    Serial.println(y, 2);
  }
}

Just give the buffer more space (e.g. "char myData[10];" or more) and it'll work fine.

25

just work through the tutorial I have linked. Pay special attention to example 2.

26

Now,I have been able to detect the flaw in my understanding:

There are eight symbols in my message (1234.56 and '\n'). The string array size is eight. The 3rd argument of the Serial.readbytesUntil() function is seven (sizeof myData - 1). As a result, the Serial.readBytesUntil() function terminates (before encountering '\n' or time-out) after reading only seven characters (1234.56) from the Serial Buffer. The '\n' character remains in the Buffer. In the next cycle, the loop() function finds '\n' and immediately terminates producing 0.00 agianst int y = atof(myData).

The lesson for me is to declare the array size sufficiently large (at least "one and half times") of the message length, which has been suggested in post #5, #24 with elegant clarification.

The above scheme (larger array size) ensures that the Serial.readBytesUntil() function detects/reads the '\n' character from the Buffer before encountering sizeof myData -1 or time-out; as a result, there is no-more character left in the Buffer; the loop() function does not produce 0.00 (in the next cycle) anymore.

27

you got it !

28

In the past I had been studying/experimenting atof() function with small float numbers (xx.xx) and arbitrary array size of 10 and I never observed 0.00 after the target data. (Now, I know why that worked.)

This time (with the given example of 1234.56 and array size 8) during online tutorial class, I was astonished to see 0.00 after the target data item. I tried few ways (without success) to supress 0.00.

Later on, I had to provide the following (clumsy) codes to the pupil for inclusion near the end of the loop() function to supress 0.00.

Serial.end();
Serial.begin(9600);

I am happy that I could bring the issue in the Forum and extending my thanks to all participants for handling the case pataiently and giving me space for understanding.

29

Yes, that's what this forum is really good for.

I'm sure you would have found out sooner or later by yourself! But sometimes one cannot see the forest for the trees... :wink: