Serial1.peek() on photon/3.3.1 not working correctly due to Serial1LogHandler?

[boddeke]

hello,

we have code for p2/5.8.0 that is optimized to read from Serial2. it uses Serial2.peek() and it all works nice

for reasons beyond this topic we are porting back this code to be used on a photon. only changing Serial2 to Serial1 the code on the photon does not work. after investigation it seems the Serial1.peek() does not work: it actually does read the next char. the test code i inserted:

        char c_prev = Serial1.peek();
        for(int j=0;j<10;j++) {
            c = Serial1.peek();
            if(c!=c_prev) {
               Log.warn("peek problem: %d != %d",(int)c_prev,(int)c);
               // Serial1.printf("peek problem: %d != %d\r\n",(int)c_prev,(int)c);
            }
            c_prev=c;
        }

we use a large read buffer on Serial1 which should easily fit the data we send. there is enough time to process the data (10s between bursts)

now when i turn off Serial1LogHandler (and use the Serial1.printf in the code above): it does work

should i make my own Serial1LogHandler that does not touch the RX stream? (and why would Serial1LogHandler do that??) or my own Serial1.peek() / Serial1.read()?

thanks
frank

[rickkas7]

I don't see any reason why it should behave that way. Since it's not obvious why that would happen the best option is to try and see if you can make it work by whatever means. Also, the 2.x release line for the Photon is closed and there won't be any bug fixes, so you'd need to find a workaround anyway.

The Serial1LogHandler is just a wrapper around StreamLogHandler that passes Serial1 as the stream. The StreamLogHandler treats the parameter as a Print which is a unidirectional output stream, so it shouldn't affect the input stream at all.

[boddeke]

logger does not interfere with peek on the p2 but it certainly does on the photon (actually using 3.3.1, because of needing larger Serial1 buffer size)

i now avoid using peek altogether and it works fine