[flammmable 0]

Есть проектируемое устройство, которое предполагается соединить с ПК при помощи RS-232.
С одной стороны было бы неплохо, чтобы устройство отвечало на *IDN? ,набитого в терминале.
С другой стороны при необходимости передачи изохронного (равномерного по времени) потока данных (значения напряжений для ЦАПов данного устройства) было бы нелепо передавать его в текстовом виде - канал потеряет скорость в разы просто так. Как есть идеологические варианты организовать переключение между этими режимами?
 

[MrBearManul 0]

11 минут назад, flammmable сказал:

Как есть идеологические варианты организовать переключение между этими режимами?

А если на текстовую команду, например запрос данных с АЦП, просто тупо отвечать двоичными данными?

З.Ы. Ой, у вас ЦАП. Ну и ладно, шлём текстовую команду, а заней пакет двоичных данных. Потом снова ждём текстовых команд. Примерно как делают терминалы с X/Ymodem-протоколами.

[flammmable 0]

1 minute ago, MrBearManul said:

А если на текстовую команду, например запрос данных с АЦП, просто тупо отвечать двоичными данными?

Спасибо за столь быстрый ответ! Я как раз об этом подумал, когда перечитывал свой вопрос. Но что, если нужно передавать на устройство и текст и поток данных?

[_pv 52]

10 minutes ago, flammmable said:

нужно передавать на устройство и текст и поток данных?

если не городить какой-нибудь стандартный протокол как те же Х/Умодем

можно либо передавать длину следующих бинарных данных в команде, либо с байт-стаффингом сделать символ окончания передачи данных по принятии которого будет переход обратно в приём ascii.

 

[jcxz 184]

28 минут назад, flammmable сказал:

было бы нелепо передавать его в текстовом виде - канал потеряет скорость в разы просто так. Как есть идеологические варианты организовать переключение между этими режимами?

Можно передавать бинарные данные кодированные в base64 или в UUE или любом другом подобном формате. Потеря в пропускной способности канала будет минимальная.

[rkit 1]

Устройство по умолчанию работает в текстовом режиме.

Специальная текстовая команда означает начало двоичного пакета заранее определенной длины.

 

  

10 minutes ago, jcxz said:

Можно передавать бинарные данные кодированные в base64 или в UUE или любом другом подобном формате. Потеря в пропускной способности канала будет минимальная.

Фига себе, 33% = минимальная потеря.

 

[AlexandrY 3]

48 minutes ago, flammmable said:

 Как есть идеологические варианты организовать переключение между этими режимами?

Такое делается интеграцией в дивайс коммуникационного протокола с разделением на логические каналы. 
Таких есть куча готовых с легко портируемыми сорсами, причем с клиентскими частями под PC.
Режимы там переключать не надо, логические каналы работают параллельно. 

[jcxz 184]

1 час назад, rkit сказал:

Специальная текстовая команда означает начало двоичного пакета заранее определенной длины.

Такое можно делать только если линк 100% надёжный и ошибки в канале принципиально невозможны. Иначе - весь обмен повиснет при первой же помехе или при элементарном перетыкании кабеля или даже закрытии COM-порта одной программой (передающей двоичные данные) и открытием другой (терминалом). Элементарно не сойдётся число байт "заранее переданной длине".

И надо ещё будет обучить пользователя успевать выдернуть кабель из двоичной программы и воткнуть терминал точно между пакетами.  

1 час назад, rkit сказал:

Фига себе, 33% = минимальная потеря.

Когда будете городить костыли, чтобы вашим вариантом можно было более-менее терпимо пользоваться, потеряете намного больше 33%.

[Baser 5]

7 часов назад, flammmable сказал:

Как есть идеологические варианты организовать переключение между этими режимами?

Можно не делать никакого переключения режимов, а просто поддерживать на приемной стороне прибора парсинг и текстового и бинарного протоколов.
Только бинарный протокол должен иметь совместимость с текстовым, чтобы их можно было различать. И текстовые команды должны быть пакетными, без бесконечных пауз между символами, как при ручном наборе в терминале.
Например, все команды разделяются паузами и первый байт бинарной команды (SoF) должен быть не ascii.

У меня так реализован парсинг ответов блютус-модуля. Его ответы текстовые, а при наличии соединения с прозрачным режимом, через него могут приходить пакеты двух разных бинарных протоколов. Нормально работает.

[mdmitry 0]

Можно использовать протокол Wake: там есть байт команды, взять две команды, одна означает текстовые данные, другая - бинарные, да, конечно, парсер придется немного доработать по сравнению с оригиналом.

[Eddy_Em 1]

В одной своей старой железке я сдуру рабочий протокол сделал бинарным. Ну, а т.к. отлаживать бинарным протоколом неудобно, добавил еще и текстовый вариант. Чтобы переключиться из бинарного в текстовый и обратно была специальная команда. Т.е. открываем терминал, даем команду перевода в текстовый формат и работаем себе. А после перезапуска или другой команды включается бинарный...

Но бинарный протокол на самом деле оправдан лишь в том случае, если вам нужно гнать бешеные потоки данных (например, от цифрового осциллографа). В остальных случаях надо сразу писать текстовый.