Reading Processing String in Arduino

It's a simple matter. The arduino waits for the start string as follows:

while (Serial.available() == 0){
  };
  while(Serial.available()){ 
    while (!(b==Serial.readString())){
    }
  }

where b = "start"

I send the string from processing as follows:

  myPort.write("start");
  while (myPort.available() > 0) {
    char inByte = myPort.readChar();
    println(inByte);
  }

It doesnt work, and I dont know why, I've tried from processing with newline. Processing can read the data from the arduino (it works when I remove that start wait).

It works when I send start from the arduino serial monitor, without newline.

Anyone have any ideas? How is processing sending out it's strings? Must be an issue of a hidden delimiter.

Please post complete code. I'm sure the error is in the part you didn't post.

Have a look at the examples in Serial Input Basics - simple reliable ways to receive data.

...R

@wvmarle

As far as the Arduino code goes, there is literally arbitrary code following that, I use it in many of my sketches.

@Robin2

I was under the impression that my code was immune to arduino reading incoming bytes too fast. As the inner while loop specifically keeps checking the incoming chars until the strings match.

himmelsteht:
As far as the Arduino code goes, there is literally arbitrary code following that, I use it in many of my sketches.

Surprised it even compiles then. Arbitrary code doesn't sound good to me.

Anyway, without seeing the rest of the code (which will include the various type declarations for the variables used in the snippets - which, it may surprise you, are actually important), you won't be getting any more help as there's nothing more to help out with.

himmelsteht:
As the inner while loop specifically keeps checking the incoming chars until the strings match.

So... what happens if there's a communication error, or something else is transmitted?

Anything to stop buffer overruns?

Any way to prevent your sketch from sitting there forever doing nothing?

@wvmarle

baby steps, I'm interested in seeing whether the code steps out of of those functions, and it's not.

At this point in time I'm not worried about those sort of checks, I've gone through it many times and there can't have been bit errors every time.

I'm just interested in located the source of error with the strings mismatching.

I moved to the IDE 'processing' because it will be easy to do graphics with. I have no problem in MATLAB or C or serial monitor use or even between arduinos. It's gotta be an thing on the processing side, and I thought someone here might be experienced with it, because the forums here are better.

To debug this kind of things I'd normally start to add print statements. Print out what's actually in that string (or is that a String?) every time you receive a character.

Thanks, that's a good idea. I decided to check the serial stream and send it back to the serial monitor. It seemed to be receiving the characters fine. Then I checked the function I was using before again and it was still not working.

The problem was with the Serial.readstring() function, for whatever reason (maybe those outlined in robin2's tutorial).

I had success with using cstrings instead and the following crude statements:

int check = 1;
 int i = 0;
 while (check){
  char c = Serial1.read();
  if(c == Str3[i]){
    i++;
  }
  if(i==(strlen(Str3)-1)){
    check = 0;
  }
 }
  check = 1;

Make check a bool, then you can set its value to true or false. Much better for readability, and it saves a byte of memory. Can't comment further on your snippet due to lack of context.

I've never tried the readString() function. It's blocking and therefore unsafe. I'd rather have my code check for new characters, process them as they come in, and do other things in the meantime. So you'd get something like this:

void loop() {
  if (Serial.available()) {
    // Read and handle this one character as needed.
  }
  // do the rest of the loop() functions.
}

Another thing to make your code (and life) MUCH simpler: use single-character commands. You have 255 codes available in a single byte, it's hard to believe you have that many commands. Probably not even 26 (the letters of the alphabet).

If you must have multi-character commands (e.g. s for start, followed by a number on what to start - if you really can't compress that in a single byte) you have to add start/stop tokens as well, so your code has at least a basic idea of when a command starts.

himmelsteht:
I was under the impression that my code was immune to arduino reading incoming bytes too fast. As the inner while loop specifically keeps checking the incoming chars until the strings match.

If your code is working as you want you are under no obligation to use mine.

...R

himmelsteht:
It's a simple matter. The arduino waits for the start string as follows:

while (Serial.available() == 0){

};
  while(Serial.available()){
    while (!(b==Serial.readString())){
    }
  }





Anyone have any ideas? How is processing sending out it's strings? Must be an issue of a hidden delimiter.

Yes. Your code assumes that when the first char arrives, the rest will be available by the time that while loop comes around for them.

Little bit of reality here:

--- serial chars arrive at baud rate /10 per second. 115200 serial can send chars just under 89 microseconds apart, quick, right?
--- 16MHz Arduino runs 1388 clock cycles in the same time. It can do other things while waiting for data the same way you can do things while waiting for lunch. But it can't make serial chars arrive faster and your while loop ends when no char is available and those 1388 cycles are nothing in the face of blocking code, certainly can't be used for other tasks.

Next you learn to collect chars as they come and only evaluate once the last one has been collected.

PS, don't use String variables on Arduino if you can help it. They're hard on the heap.