Предоставляет ли chrome.serial API целостность данных?

Question

Я пытаюсь понять, является ли его избыточным для меня включение какого-то CRC или контрольной суммы в мой протокол связи. Имеет ли chrome.serial и другие хромированные аппаратных средств связи API, в общем, если кто-то может говорить с ними (например, chrome.hid, chrome.bluetoothLowEnergy ...)

Answer 1

Последовательные коммуникации просто способ передачи битов и его основной причиной существования является то, что это один бит за раз - и поэтому может работать только по одной линии связи, такой как простая телефонная линия. Нет встроенного CRC или контрольной суммы или чего-то еще.

Существует множество систем, которые живут поверх серийных коммуникаций, которые пытаются справиться с тем фактом, что общение часто происходит в шумной среде. Вернувшись в день модемов по телефонным линиям, вам, возможно, придется иметь дело с тем, что кто-то еще в доме может забрать еще одно расширение на телефонной линии и добавить кучу шума в вашу загрузку. Таким образом, были созданы такие протоколы, как XMODEM, обертывание последовательных коммуникаций в более надежной структуре. (Затем, когда XMODEM оказался ненадежным, мы отправились в YMODEM и ZMODEM.)

В зависимости от того, с чем вы разговариваете (например, устройство, подобное Arduino, подключено к последовательному порту USB по проводу длиной 25 см), вы можете обнаружить, что работа над проверкой данных не стоит того, потому что вероятность вмешательства настолько мала, и последствия тривиальны. С другой стороны, если вы разговариваете с контроллером для лазерного оружия, вы можете убедиться, что команда, которую вы отправляете, является полученной командой.

Я ничего не знаю о других системах, о которых вы упоминаете, но я достаточно взрослый, чтобы потратить много времени на выполнение последовательных коммуникаций в 80-х годах (и теперь это снова для устройств, использующих chrome.serial , go figure).

Answer 2

Я использую API-интерфейс Chrome для связи с устройствами Arduino, и мне еще предстоит испытать случайное повреждение в середине обмена (мои обмены - короткие всплески, максимум 50-500 байт). Тем не менее, я вижу, что мусорные байты выходят из строя, если соединение слоеное или кабель «грубо» отключен (как несколько минут назад, когда я споткнулся о кабель FTDI).

В моем проекте некорректно обработанная команда ничего не сломает, и я могу обойтись с помощью протокола master-slave. Из-за этого я разработал довольно тонкое решение: подчиненный Arduino прослушивает «байт внимания» (!), За которым следует командный байт, после чего он считывает фиксированное количество байтов данных в зависимости от команды. Поскольку Arduino сбрасывается до тех пор, пока он не услышит байт внимания и действительную команду, ошибки прерывания обычно возникают, когда соединение вырезается, когда подчиненный «ожидает байтов данных». Чтобы учесть это, первое, что мастер делает для подключения, - это слепо взлететь достаточно байтов AT, чтобы подтолкнуть Arduino через «ожидающие данные» даже в худшем случае. Сырой, но достаточно.

Я понимаю, что мое решение довольно лёгкий, так что я сделал немного серфинга вокруг, и я нашел этот пост, чтобы быть довольно всеобъемлющими: Simple serial point-to-point communication protocol

Кроме того, если вам нужна стратегия для error- коррекции (или над моей стратегией, которая, как я полагаю, является «ошибкой-грубой силой»), вы можете проверить ссылку на технику под названием «Хэмминг» у нижней части этой нити - Это выглядело многообещающе!

Удачи вам!

-Matt