I've already posted my question on stackoverflow, but would like to draw attention specifically from the arduino forum readers.
In brief, I'm trying to use Serial.find() to wait for EOL characters, ASCII 13, and ASCII 10.
I'm having problems compiling code with Serial.find(charCr) if my target char variables are defined as char charCr= 13; and char charNl= 10; with the compiler complaining that Stream.h expects *char, a pointer, not a value.
Using the reference operator Serial.find(&charCr) and Serial.find(&charNl) allows the code to compile, but the conditions are never met if (Serial.find(&charCr) && Serial.find(&charNl)){do_stuff_when_EOL_found;}
I will also cross-post the answer once I have one.
I don't think I do, but when I use Serial.find(charCr) I get a compile error, which asks for a pointer
tEBTap.ino:89:27: error: call of overloaded 'find(char&)' is ambiguous
ftEBTap.ino:89:27: note: candidates are:
In file included from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/HardwareSerial.h:29:0,
from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:221,
from ftEBTap.ino:3:
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Stream.h:59:8: note: bool Stream::find(char*) <near match>
bool find(char *target); // reads data from the stream until the target string is found
^
C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Stream.h:59:8: note: no known conversion for argument 1 from 'char' to 'char*'
I'd included that info in full in the stackoverflow post, but didn't want to XPost all the content for brevity.
right.. that was my thought, and as i said in my original post, it allows the code to compile, but the condition is never met.
From help on stackoverflow, it seems the documentation is incomplete, and Serial.find(inputVar) expects the input variable to be a string, not char, or at last string made up of chars.
char crlfnl[3] = {13, 10, 0};
seems to work, but I think my theory for my code is failing in other respects.
I also now think that Serial.find() operates in a destructive manner, with respect to buffer content, like Serial.read() does, and not Serial.peek()... This would also explain why the conditional wouldn't be met with the &charCR solution, because its a double conditional, and if it finds one first, drains the buffer, then finds the next on the next while iteration, the if condition is never true.
man, it would be nice to have a non-destructive Serial.peekFind() or something, because my hopes were to wait until EOL was found by using Serial.find() then parse the integer found before the EOL in the serial buffer using Serial.parseInt()... but it seems I'll have to work out another solution.
Why not just use Serial.read() and your own code to see what the character is?
Many attempts to "simplify" the programmers task cause more problems than they solve. Read (from the founder of StackOverflow) the law of leaky abstractions
From help on stackoverflow, it seems the documentation is incomplete, and Serial.find(inputVar) expects the input variable to be a string, not char, or at last string made up of chars.
bool find(char *target); // reads data from the stream until the target string is found
That sure suggests to me that the function expects a string for the terminator.
You have access to the source code. If the compiler is complaining about your assumptions, check the source.