Serial.peek: подсмотреть байт и принять решение

В один порт ко мне стучались двое: GPS-приёмник со строками вида $GPRMC… и служебные сообщения соседней платы с решёткой в начале — #temp=24. Вычитывать всё подряд read()-ом нельзя: первый байт уже вынут, и решить, кто пришёл, не по чему. Спасение — peek: он показывает следующий байт, не вынимая его из буфера, и решение «читать или выбросить» принимается до того, как байты потеряны.

Serial.peek — третий способ заглянуть в порт рядом с available и read: первый говорит, сколько байт ждёт, второй достаёт, третий — подсматривает. Разберём, что peek возвращает на пустом буфере, почему его нельзя складывать в char бездумно и как на нём собирается порт-сортировщик с двумя протоколами сразу.

Механика простая до скучности, но порядок слов важен. Serial.available() возвращает число ждущих байтов; Serial.read() достаёт самый старый и двигает очередь; Serial.peek() показывает тот же самый старый, но очередь не двигает — повторный peek вернёт тот же байт, пока вы его не вычитали read-ом. На пустом буфере и read, и peek возвращают -1. Отсюда золотое правило пары: сначала available, потом peek/read — иначе сравнение с байтом на пустом месте.

Грабля самозванца: peek возвращает int, и только -1 — признак пустоты. Записав результат в char, вы превращаете -1 в байт 0xFF: пустой буфер становится неотличим от настоящего байта 255, и разбор пойдёт по неверной ветке. Держите peek в int, как в примерах ниже. Классический цикл с peek уже мелькал в уроке-калькуляторе: while (available && peek == ' ') read(); — выедает пробелы перед знаком, не трогая само слово. Тот же приём в уроке про терминал устройства чистит хвосты перед разбором команд.

Главная работа peek — маршрутизация. Пока очередь не тронута, первый байт — это ярлык всего сообщения: доллар — NMEA от GPS, решётка — служебная телеметрия соседа, цифра — команда без слов. Один просмотр — и вы либо вычитываете строку целиком, либо молча выбрасываете её до перевода строки, не потревожив чужие строки. Так на одном порту уживаются несколько говорящих, и разбор NMEA получает свой доллар, а счётчик мусора — свой остаток.

Внимательный читатель спросит, почему служебные строки выбрасываются циклом read, а не readStringUntil. Ответ — в праве на отсутствие терминатора: если линия дрогнула и перевода строки не будет, readStringUntil продержится секунду на таймауте и вернёт хвост, а цикл с available просто вычистит всё, что есть, и пойдёт дальше. В горячем потоке секунда — это та самая копилка буфера, переполнять которую себе дороже.

Вторая тонкость — согласованность маршрутов. Пока вы копите NMEA через readStringUntil, приходящие следом байты другой строки подмешаются в ту же копилку: порт один, и очередь одна на всех. Поэтому сортировщик живёт в loop без delay: чем чаще он заглядывает, тем меньше шансов, что две строки перемешаются. Если перемешивание всё же случается — это сигнал, что скетч где-то долго стоит: место такой остановки ищут тем же способом, что и переполнение приёмного ящика в уроке про буфер.

Один нюанс из практики: peek хорош и для ловли паузы. Мой счётчик мусора рос байтами, и по его темпу я видел, что линия живёт: поток от GPS на 9600 бод — примерно 960 байт в секунду, и если за секунду не пришло ничего, разговор кончился, можно переводить стенд в сон. Арифметика байтов в секунду с ловушкой кварца 8 против 16 МГц — в уроке про скорости и рассинхрон.

Чего peek не заменяет: он не умеет ждать. В отличие от find, peek не блокируется в ожидании байта — пусто так пусто, проверяйте available и возвращайтесь на следующем проходе. Просмотр без available перед ним — половина затыков: сравнение с -1 на пустом буфере уводит разбор в ветку мусора, и честный байт, приехавший микросекундой позже, будет посчитан неверно.