Форум » » Ввод данных через СOM порт » Ответить
Ввод данных через СOM порт
Pavel777: На вход TCP контролера приходит команда вида \хNN\xNN\xNN в дебагере вижу то же самое \хNN\xNN\xNN. На СOM порт приходит команда \хNN\xNN\xNN. В дебагере \xNN \xNN \xNN Как получить непрерывную строку с ком порта, как с ТСР? Пробую разные порты, но везде одно и тоже
Ответов - 8
Igor: Pavel777, проверить соответствие скорости потока и прочих настроек COM-порта автора строки настройкам порта контроллера Crestron. Если соответствуют, при возможности снизить на обеих сторонах до 9600. Если не поможет, еще снизить. Если не поможет, я бы задумался о программной сборке строки на основании протокола. Например, зная начальный и конечный символ строки, ловим её куски и собираем воедино. Или использовать аппаратный шлюз Ethernet <-> RS232, установив оный около контроллера.
Вячеслав: Используйте BUFFER_INPUT в модуле Simpl+ или символ Serial Gather (если есть признак окончания команды и команды не длиннее 255 символов) Вот такой модуль Simpl+ может помочь, но это грубоватое решение при отсутствии признака-разделителя (delimiter) и обработки параметра длины команды скачать тут
Игорь K.: Ничего криминального в построчном отображении символов нет. Так показывает строку Toolbox, Лишних символов, интерпретируемых как перевод строки там нет. Для Парсинга используйте привычные методики. Из предложенных выше, присоединяюсь к использованию Serial Gather (Simpl), или gather (S+), что даст только лишь более привычное, сплошное отображение строки.
Pavel777: Думал, что вопрос в каких-то "секретных" настройках СОМ-порта, с помощью которых сходу можно решить вопрос, но оказалось это проблема. Притом, она не безобидная, символы Substring и serial to analog , работающие с приходящей строкой не работают как надо. Cимвол Gather решает проблему, но оказалось, у меня проблема с разделителем. Помог символ, предложенный Вячеславом, за что ему отдельное спасибо.
PG: Выбранная вами скорость COM-порта достаточно низкая, чтобы контроллер успел обрабатывать (и соответственно отображать в тулбоксе) поступающую информацию побайтово. В случае с TCP отображается содержимое пакета. Попробуйте увеличить скорость COM-порта и байты начнут слипаться.
Viacheslav Alekseev: В любом случае - на целостность посылок не стоит расчитывать, т.к. всегда есть вероятность, что поток разорвется на несколько фрагментов, вплоть до побайтовых, что увидел автор темы. Поэтому, как верно выше отметили - нужно правильно реализоваывать алгоритмы чтения и обработки входящих данных, а именно: 1) складывать все данные в единый буфер, используя BUFFER_INPUT (или STRING_INPUT и собственный буфер в виде переменной внутри модуля - но этот способ не имеет смысла при наличии первого) 2) не забывать про Threadsafe на событие чтения и обработки BUFFER_INPUT 3) в событии чтения организовать бесконечный цикл, в котором последовательно вычленять из входящего буфера команды по мере их появления. Если в протоколе есть разделитель - то Gather() все делает за вас. Если разделителя нет, то бывает признак начала команды и длина команды, анализируя которые, можно дождаться, когда команда пришла целиком, и вырезать её из буфера. Это чуть сложнее, требует всяких проверок (и тут нельзя бесконечный цикл). Если все команды одной длины, можно попробовать использовать GatherByLength() но один левый байт мусора, и все пойдет враскоряку. Придется навешивать всякие проверки и очистки буфера. Если протокол ваш собственный - то карты в руки. Кстати, в TCP и UDP расчитывать на целостосность посылки можно с большими оговорками. На мой взгляд - это "читерство", и надо применять все те же техники, что и КОМ-портом. Ибо это такой же поток и никто не гарантирует вам 1 пакет = 1 событие CHANGE. Например, прилетит 2 пакета, пока Logic Engine занят чем-то важным и сложным. Драйвер сложит данные в буфер чтения ethernet адаптера, а Logic Engine, когда освободится, возьмет и вызовет один CHANGE, и вы получите их все разом. Возможно я ошибаюсь, тогда пусть разработчики ядра и драйверов меня поправят :)
PG: Viacheslav Alekseev пишет: Возможно я ошибаюсь, тогда пусть разработчики ядра и драйверов меня поправят Расчитывать на порядочность разработчиков чего бы то ни было, ИМХО, в любом случае не стоит. Сегодня чит работает, а послезавтра выйдет обновление и кирдык :)
olegny: Причет тут "порядочность"? Нужно оставаться в рамках публично описанного и гарантированного, а все остальное это на свой страх и риск. Viacheslav Alekseev все правильно написал выше. Опираясь на "Семиуровневую модель OSI", целостность сообщения на совести следующего уровня, поверх TCP/UDP или любого стриминга.
полная версия страницы