Краткий ответ: serial.read () не может сказать, сколько байтов нужно прочитать. Либо у вас есть некоторые предварительные знания о том, как долго сообщение, или данные, которые вы отправляете, имеют некоторые средства для обозначения границ между сообщениями.
Подсказка; зная, насколько длинным является сообщение, вам также необходимо знать местонахождение в потоке принятых байтов сообщения, которое фактически началось. Вы не знаете наверняка, что полученные байты точно выровнены с отправленными байтами: возможно, вы не запустили приемник до передатчика, поэтому они могут быть не в состоянии.
При любой сериализации возникает вопрос: самоограничение или нет? Буферов протокола Google нет. Я не думаю, что Пикл тоже. ASN.1 BER, по крайней мере, в некоторой степени. Как и XML.
Дело в том, что модули XBee (при условии, что вы используете модули от Digi) являются просто ненадежными переносчиками байтов, поэтому все, что вы проходите через них, должно быть каким-то образом разграничено, чтобы получающий конец знал, когда у него есть полный сообщение. Таким образом, если вы передаете сообщение или протокол Google Buf, вам нужен какой-то другой способ кадрирования сериализованных данных, чтобы получающая сторона знала, что у него есть полное сообщение (то есть видно конец и конец). Это может быть так же просто, как некоторый байтовый шаблон (например, 0xffaaccee00112233), используемый для обозначения конца одного сообщения и начала следующего, выбранный так, чтобы он вряд ли имел место в самих отправленных сообщениях. Ваш код на принимающей стороне будет считывать и отбрасывать данные до тех пор, пока не будет обнаружен этот шаблон, затем будет считывать последующие данные в буфер до тех пор, пока он не увидит этот шаблон снова, и только тогда он попытается отобрать / де-GPB данные обратно в объект.
В ASN.1 BER сам поток данных включает в себя одно и то же, что экономит ваши усилия. Он использует теги, значения и поля длины, чтобы сообщать своим декодерам о поступающих данных, и если входные данные не имеют смысла для декодера по сравнению с исходной схемой, неверно сформированные данные легко игнорируются.
Такая проблема также существует в сокетах tcp, хотя, по крайней мере, с такой доставкой более или менее гарантировано (первые байты, которые вы получаете, являются первыми отправленными байтами). Соединение Digimesh не достигает того же уровня гарантированной доставки, что и tcp-сокет, поэтому необходимо, чтобы принимающее приложение знало, что оно синхронизировано с отправителем, что-то еще (например, шаблон байтов кадрирования).