Связь синхронного/асинхронного последовательного порта с JSSC

Я пытаюсь установить связь между двумя компьютерами, используя последовательный порт, и я новичок в этой области. Мне нужно отправлять запросы с одного компьютера (скажем, A) на другой (скажем, B) и получать ответы на отправленные запросы. Я обновляю пользовательский интерфейс Java Swing ответами.

Для этого я использую библиотеку jSSC. Я просмотрел SerialPortReader примеры и ниже привожу понимание.

Мне придется реализовать SerialPortEventListener на обоих компьютерах. Для отправки запросов будет использоваться метод writeBytes. B будет прослушивать команды, отправленные с помощью SerialPortEventListener, и будет использовать метод writeBytes для отправки ответа. A будет прослушивать данные, используя свою реализацию SerialPortEventListener, и когда данные будут получены, обновит пользовательский интерфейс. Далее мои вопросы.

а) Верно ли мое вышеприведенное наблюдение? Есть ли другой способ сделать это (например, возможно ли, что в протоколе существует метод writeBytes, который будет возвращать ответ?)

б) Я прочитал несколько раз, что связь через последовательный порт может быть как синхронной, так и асинхронной. Но из примеров я не могу понять, реализован ли в этом коде асинхронный или синхронный обмен данными. Как можно реализовать синхронную/асинхронную связь с использованием jSSC? Я не прошу реализации. Просто некоторые рекомендации и какие методы можно использовать.

c) Возможно, что сообщения будут доставлены частично. Например, если я отправлю команду в виде строки «get variableThreeValue», возможно, будет получено только «get» или что-то вроде «get varia» (это может привести к сообщениям типа «get get» и т. д.). ) Как я могу справиться с таким сценарием? Опять же, я не прошу реализации. Просто некоторые рекомендации и какие методы можно использовать.


java serial-port jssc
person Can't Tell    schedule 11.02.2015    source источник
comment
Вы не хотите синхронного. Последовательные соединения обычно асинхронны: стартовые и стоповые биты обрабатываются HW. Если вы не доверяете соединению, вам придется разработать протокол: формат сообщения (длина, порядковый номер, байты, CRC), подтверждение/отрицательное подтверждение для запроса повторной отправки,... Почему бы вам не использовать Ethernet ?   -  person laune    schedule 11.02.2015
comment
@laune Я должен поддерживать связь через порт Wi-Fi и Serail. Радиопередатчик/приемник будет подключен к последовательному порту, и связь будет осуществляться по беспроводной сети. Спасибо за совет. Но я также задавал вопросы, чтобы улучшить свое понимание. Можете ли вы помочь мне с вышеуказанными вопросами, а также?   -  person Can't Tell    schedule 11.02.2015
comment
Проверка и запись ответа.   -  person laune    schedule 11.02.2015

Ответы (2)


arrow_upward
1
arrow_downward

Классический «последовательный порт» — это что-то очень «низкого уровня». Должны быть установлены такие параметры, как скорость передачи данных, стартовые и стоповые биты и управление потоком, а затем считываются и записываются последовательности байтов. Библиотека Java использует прослушиватель для получения событий, которые непосредственно получены из того, что воспринимает последовательный драйвер (вы найдете такие термины, как «линия» в javadoc). Как реагировать, зависит от «другой стороны».

Управление потоком — это то, что вы используете, чтобы избежать переполнения или переполнения приемника. Строки RS-232 содержат C(lear)T(o)S(end) и R(equest)TS, поэтому "аппаратное рукопожатие" является одним из вариантов. В качестве альтернативы US-ASCII определяет управляющие символы XON и XOFF, которые могут быть встроены в поток данных, если это не двоичные данные. Управление потоком не должно быть проблемой, если отправляющая сторона не отправляет на полную мощность или компьютеры значительно различаются по скорости.

Я так понимаю, вы подключите к порту какое-то радиоустройство, в документации к которому должны быть указаны все параметры, а также протокол более высокого уровня, т.е. как передавать и принимать данные. К устройству могут предъявляться особые требования, например, вы должны передать некоторые данные настройки, прежде чем передавать фактические данные. (Если вы соедините два компьютера одним кабелем, то все зависит от вас.)

Как только вы сможете в основном отправлять и получать, вам придется подумать о безопасной передаче. Вам необходимо разработать протокол:

  • формат сообщения, например. содержащий длину, порядковый номер, байты данных, CRC.
  • последовательность сообщений, т. е. кто может отправлять, что и когда, например, сообщение от A к B, подтверждение от B к A, повторение. Или NAK от B, и A должен отправить повторно.
  • Возможно, вам нужен "протокол сеанса", т.е. логин (как в ftp) и выход
  • Тайм-аут: что, если ни одна из сторон не получит другое сообщение в течение T?
  • Вам нужно сердцебиение, то есть сообщение, отправленное, когда канал простаивает, чтобы узнать, что другая сторона все еще «жива».

Соединение WLAN должно сделать большую часть этого ненужным. Настоящего "радио" (какого-то коротковолнового?) я никогда не слышал, но я не радиоспециалист.

person laune    schedule 11.02.2015
comment
Устройство learn.sparkfun.com/tutorials/exploring-xbees-and-xctu, просто для сведения - person Can't Tell; 11.02.2015
comment
Спасибо! Хорошая игрушка. - Я видел управление потоком. Знаете ли вы, что означает XON/XOFF по сравнению с аппаратным обеспечением? - person laune; 11.02.2015

arrow_upward
0
arrow_downward

XON/XOFF — это программное управление потоком. Предположим, что между производителями a и b используются двунаправленные последовательные байты. Если какой-либо из них отправляет байт XON, это означает, эй, прекратите отправлять мне байты, пока я не отправлю вам байт XOFF.

Для оборудования замените байт XON на CTS и байт XOFF на RTS.

person Clyde W. Phillips Jr.    schedule 22.04.2015