Stream.find() hangs when used on an Ethernet Client stream.

[GoogleCodeExporter]

What steps will reproduce the problem?
The following code:

void setup() {
  Serial.begin(9600);
}

void loop() {
    int got = Serial.findUntil(",", "\n");
    Serial.print(got);
    Serial.print("\t");
    Serial.println(Serial.available());
}

Given the string "34,345\n", this code should produce "1   3" meaning that it 
found the comma and left the remaining three bytes of the serial stream alone.  
But instead it produces "1   0", meaning it's eliminating the rest of the 
stream.

The point of findUntil() in the original TextFinder was to allow you to skip 
until you found a given target, then keep parsing the rest of the stream.  This 
is as opposed to find(), which just looks for the target and ignores the rest.  

Currently the program above produces the same results with find(",") and 
findUntil("," "\n"), making findUntil() redundant.

Probably the same on readBytesUntil(), though I haven't tested.

Original issue reported on code.google.com by tom.i...@gmail.com on 24 Apr 2012 at 10:28

[GoogleCodeExporter]

Here' another example, testing Stream.find() against the older TextFinder 
library find():

Given the following JSON:

{"messages":177,"Kbytes":56047,"unread":43}

The following TextFinder example finds all three values:

 while (client.available()) {
    if (finder.find("{")) {
      long messages = finder.getValue();
      long kilobytes = finder.getValue();
      long unread = finder.getValue();

      Serial.print("messages: ");
      Serial.println(messages);
      Serial.print("kilobytes: ");
      Serial.println(kilobytes);
      Serial.print("unread: ");
      Serial.println(unread);
    }
}

Result:
messages: 177
kilobytes: 56047
unread: 43

The following Stream.find() example hangs at the first find():

    if (client.find("{")) {
      long messages = client.parseInt();
      long kilobytes = client.parseInt();
      long unread = client.parseInt();

      Serial.print("messages: ");
      Serial.println(messages);
      Serial.print("kilobytes: ");
      Serial.println(kilobytes);
      Serial.print("unread: ");
      Serial.println(unread);
    } else {
     Serial.println("I failed"); 
    }
}

Original comment by tom.i...@gmail.com on 2 May 2012 at 5:31

[GoogleCodeExporter]

In the first example, the problem isn't that findUntil() is consuming extra 
characters, but that the remaining characters haven't yet arrived over the 
serial stream when Serial.available() is called.  That is, Serial.findUntil() 
returns immediately upon receipt of the ',' character, at which point there are 
0 characters available.  Then, Serial.findUntil() runs again, this time on 
"345\n", returning 0 and consuming the remaining characters.  If you add a 
delay (e.g. 200 ms) after the Serial.print("\t"); you'll see the expected 
output of "1     4".  

The second example works for me, if I change "client" to "Serial", although 
it's possible there's some issues with the interaction between the Ethernet 
client and the find function.

Original comment by dmel...@gmail.com on 9 May 2012 at 12:52

• Changed state: Invalid

[GoogleCodeExporter]

It doesn't work on Ethernet or Wifi. Please try it there, as described. Don't 
mark an error "invalid" until you've tested it properly, at least as reported.  
The problem was not with Serial, it was with Ethernet and Wifi.  

The delay is not necessary with the TextFinder version of these commands.  
Perhaps we could go with their algorithms, since they are better?

Original comment by tom.i...@gmail.com on 9 May 2012 at 1:36

• Changed state: New

[GoogleCodeExporter]

Can you post the full code for the Ethernet example?  How did you test it?

Original comment by dmel...@gmail.com on 9 May 2012 at 2:12

• Changed title: Stream.find() hangs when used on an Ethernet Client stream.

[GoogleCodeExporter]

I can close this, right?

Original comment by dmel...@gmail.com on 23 May 2012 at 2:59

• Changed state: Invalid

[GoogleCodeExporter]

Yep,

t.

Original comment by tom.i...@gmail.com on 23 May 2012 at 6:19