Работа с com портами

← →
red_imp © (2006-10-12 17:47) [0]

Возникла проблема - нужно принимать данные с устройства которое подключено к сом порту и определенным образом обрабатывать эту информацию, с помощю демки которая шла с оборудованием принимает все нормально но при просмотре лога приема данные передавались в виде какойто абракадабры типа - "S.~~..#u" и т.д. Подскажите пожалуйста как организовать прием данных в читаемой форме.

← →
Ketmar © (2006-10-12 17:50) [1]

настройки порта правильные?

← →
guav © (2006-10-12 17:58) [2]

> с помощю демки которая шла с оборудованием принимает все
> нормально но при просмотре лога приема данные передавались
> в виде какойто абракадабры типа - "S.~~..#u" и т.д

Это наверное значит, что "S.~~..#u" - не какая-то абракадабра а правильные данные, с точки зрения протокола обмена ?

← →
red_imp © (2006-10-12 18:06) [3]

Ketmar ©

Да вроде да.

guav ©

> Это наверное значит, что "S.~~..#u" - не какая-то абракадабра
> а правильные данные, с точки зрения протокола обмена ?

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

← →
ANB © (2006-10-12 18:12) [4]

> Скорее всего только вот не знаю как перевести эти данные
> в форму которую я мог бы использовать

Может сначала почитать описание протокола обмена ?

← →
red_imp © (2006-10-13 16:08) [5]

ANB ©

Да протокол там стандартный rs 485 в описании его нашел что:

1). Часто встречаются протоколы на основе ASCII-кода. Управляющие символы и данные передаются в виде обыкновенных ASCII символов. Посылка может выглядеть так:
В HEX виде: 3Ah 31h 32h 52h 53h 34h 38h 35h 0Dh
В ASCII виде: ":" "1" "2" "R" "S" "4" "8" "5" /ПС/....
2). Можно организовать протокол с непосредственной передачей двоичных данных
3) Протокол может быть "чисто" двоичным, то есть без выделения специальных управляющих символов

Никогда с этим не работал, может ктото подскажет в каком направлении стоит дальше искать

← →
atruhin © (2006-10-13 16:12) [6]

Это описание работы порта. Тебе нужно описание прикладного протокола, узнать у производителя оборудования.

← →
red_imp © (2006-10-13 16:27) [7]

atruhin ©

А если его нет тогда можно чтото сделать? Просто дали задние написать прогу которая будет снимать данные с контроллера, в описании устройства написано что работает через протокол rs 485. К производителю обратится довольно таки проблематично

← →
Германн © (2006-10-13 17:04) [8]

> Подскажите пожалуйста как организовать прием данных в читаемой
> форме.

Принимать байты и выводить их с помощью IntToHex

← →
Kolan © (2006-10-13 19:18) [9]

Возьми шпион LGComSpy++ - супер вешь для таких дел...

← →
YurikGL © (2006-10-14 23:59) [10]

> А если его нет тогда можно чтото сделать? Просто дали задние
> написать прогу которая будет снимать данные с контроллера,
> в описании устройства написано что работает через протокол
> rs 485. К производителю обратится довольно таки проблематично

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

← →
Германн © (2006-10-15 02:10) [11]

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

Имхо, для автора любой протокол сложный! Он пока умеет только читать текст.

> в описании устройства написано что работает через протокол
> rs 485.

Это не то...Необходимо описание прикладного протокола, который используется устройством + знание управляющих сигналов, при которых принимаемые данные верны... Как средство, при отсутствии описания, можно предложить схему по которой задействованы 3 порта на 1 устройство, на 2 программа - демка, а третий связывает порт демки с твоей программой, которая выкидывает то что пришло от демки на порт устройства и наоборот, при этом выводя данные например в Мемо в НЕХ виде. При помощи такой "прослойки" можно попытаться расколоть прикладной протокол, я не думаю что он очень сложный для понимания :))))

Всем спасибо за ответы, буду пробовать

> medved_68 © (15.10.06 18:46) [12]
>
>Как средство, при
> отсутствии описания, можно предложить схему по которой задействованы
> 3 порта на 1 устройство, на 2 программа - демка, а третий
> связывает порт демки с твоей программой, которая выкидывает
> то что пришло от демки на порт устройства и наоборот, при
> этом выводя данные например в Мемо в НЕХ виде. При помощи
> такой "прослойки" можно попытаться расколоть прикладной
> протокол, я не думаю что он очень сложный для понимания

Иногда этого мало, имхо. Иногда нужно знать "In/Out" с точностью до одного байта. А ещё, иногда, нужно и работать напрямую с выводами микросхемы UART!
Пусть автор пробует. Результаты его проб можно будет обсуждать более конкретно.

Германн Да нет здесь явно не тот случай!!! Большинство такой байды работает даже без аппаратного управления потоком, ожидая тупого подтверждения приема набором ASCII кода + контрольная сумма и маркер конца. :))) А пока не пришло шлют как обалделые одно и то же. :))) Хотя может и ошибаюсь но в любом случае:

> Пусть автор пробует. Результаты его проб можно будет обсуждать
> более конкретно.

полностью одобрям и поддержам!!!! Ж)))

Работа с com портами Найти похожие ветки