Есть такая трабла:
Есть софт работающий с устройством через COM порт, но для работы использует свой драйвер. В софте видно только физически существующие порты (выртуальные не видно).
Можно ли как то создать виртуальный ком порт который будет видно как апаратный?

Здравствуйте, FlashBack, Вы писали:

FB>Есть такая трабла:
FB>Есть софт работающий с устройством через COM порт, но для работы использует свой драйвер. В софте видно только физически существующие порты (выртуальные не видно).
FB>Можно ли как то создать виртуальный ком порт который будет видно как апаратный?

да скорее всего в софтине в диалоге выбора порта жестко забиты COM1 и COM2
Если бы было сделано честное перечисление портов, то имхо все было бы видно.

Здравствуйте, x-code, Вы писали:
XC>да скорее всего в софтине в диалоге выбора порта жестко забиты COM1 и COM2
XC>Если бы было сделано честное перечисление портов, то имхо все было бы видно.

Там список, в который в зависимости от количества реальных портов добавляются до COM4. Виртуальный пробовал делать COM3 — не видит...

Нашёл драйвер com2com c которым мой софт работает. Теперь такой вопрос.

Софт не передаёт данные в привысном для ком порта виде а просто выставляет какой либо вывод в 1 или 0. Com2com сквозь себя это протаскивает как есть, то есть осталсь только на виртуальном порте смотреть состояние ног.

Как можно выставить к слову TX в 1 или 0?

Здравствуйте, FlashBack, Вы писали:

FB>Есть софт работающий с устройством через COM порт, но для работы использует свой драйвер. В софте видно только физически существующие порты (выртуальные не видно).
FB>Можно ли как то создать виртуальный ком порт который будет видно как апаратный?

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

Здравствуйте, FlashBack, Вы писали:

FB>Как можно выставить к слову TX в 1 или 0?

Установить бит 6 в LCR. Из-под Win32 — SetCommBreak/ClearCommBreak.

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Подозреваю, что используемый драйвер — из разряда GiveIO, тупо открывающего аппаратные порты для доступа из пользовательского приложения, иначе никакого драйвера не требуется. А софт, как я понимаю, досовский?
Нет. Это WinPic800 — сойт для программатора типа PonyProg — a. Хочу его к программатору BidiPro подвязать...
А задача просто в том, чтобы перехватить то, что выдаёт софт на виртуальный ком порт, послать запрос к BidiPro на LPT порт, и прислать ответ опять на ком порт.

А установка Э бит 6 в LCR. Из-под Win32 — SetCommBreak/ClearCommBreak." что даст? Можно поподробнее?

P.S. Софт использует выходы : DTR,RTS и TXD. Как вход использует CTS.

Здравствуйте, FlashBack, Вы писали:

FB>А задача просто в том, чтобы перехватить то, что выдаёт софт на виртуальный ком порт, послать запрос к BidiPro на LPT порт, и прислать ответ опять на ком порт.

Если софт действительно работает с портами напрямую — можно убрать драйвер и сделать приложение, которое возьмет этот процесс под отладку, реагируя на попытки процесса читать/писать порты, и подсовывая ему нужные значения. Если же евонный драйвер работает по запросам от приложения и лезет к портам сам — придется писать свой драйвер, который вместо этого лезет в LPT.

FB>А установка Э бит 6 в LCR. Из-под Win32 — SetCommBreak/ClearCommBreak." что даст? Можно поподробнее?

Куда подробнее-то? Состояние Break — это постоянно активный уровень на линии Tx. Приемником отрабатывается установкой бита 4 в LSR.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Куда подробнее-то? Состояние Break — это постоянно активный уровень на линии Tx. Приемником отрабатывается установкой бита 4 в LSR.

Я с последовательным портом не работал, для меня это всё не так просто... Я вроде как могу послать IOCTL запрос для установки Break и снятия, а как считать?

P.S. Добавлю, что на данный момент есть:
2 виртуальных ком порта связанные виртуальным нульмодемным кабелем. Софт подключаю на один порт, а свой обработчик на другом.

Здравствуйте, FlashBack, Вы писали:

FB>Я с последовательным портом не работал, для меня это всё не так просто...

Так, может, уже пора что-нибудь почитать про то, как эти порты работают и управляются? В сети по этому вопросу статей и литературы море.

FB>Я вроде как могу послать IOCTL запрос для установки Break и снятия

Можете и через IOCTL, но в Win32 есть полный пакет функций для работы с портами.

FB>а как считать?

Флагами состояния отображается.

Злой ты человек
Я уже стока доквы прочёл, что голова лопнула. А ответа нет...
Конкретно проблема как считать/записать ножку! ком порта?

Plz. название функции напиши для работы с ногами, а то у меня уже лёгкое помешательство развилось...

Здравствуйте, FlashBack, Вы писали:

FB>Злой ты человек

Я не злой, просто ликбез более уместен в более других разделах, но не здесь. Для успешной работы на низком уровне нужен определенный склад мышления, которого у тебя пока не видно

FB>Конкретно проблема как считать/записать ножку! ком порта?
FB>Plz. название функции напиши для работы с ногами

Нет в Win32 "функции для работы с ногами". Оно там организовано по-другому. Читай в разделе MSDN "Communications Resources". Мог бы и сам по приведенным названиям функций открыть раздел и прочитать его весь. Конкретно состоянием выходов управляет функция SetCommState.

Здравствуйте, FlashBack, Вы писали:

FB>Конкретно проблема как считать/записать ножку! ком порта?
FB>Plz. название функции напиши для работы с ногами, а то у меня уже лёгкое помешательство развилось...

EscapeCommFunction; позволяет устанавливать/сбрасывать ноги Tx, RTS, DTR. Для Tx эквивалентна уже упоминавшимся SetCommBreak/ClearCommBreak, для RTS и DTR требуется предварительная установка разрешения ручного управления ногами в соответствующих битах DCB (RTS_CONTROL_ENABLE, DTR_CONTROL_ENABLE).
Только скорее всего Вас занесло не туда — таким способом в Win32 данные (Tx) в порт не пишут.
Прочитать состояние RTS и DTR можно через GetCommModemStatus. Обычно отслеживают изменение состояния этих линий через WaitCommEvent.
Вообще API для работы с COM портом в Win32 прост — писать через WriteFile (иногда может пригодиться TransmitCommChar), читать через ReadFile. Всё остальное — настройки для этих операций (установка таймаутов, DCB и пр.)

Здравствуйте, wallaby, Вы писали:

W>EscapeCommFunction; позволяет устанавливать/сбрасывать ноги Tx, RTS, DTR. Для Tx эквивалентна уже упоминавшимся SetCommBreak/ClearCommBreak, для RTS и DTR требуется предварительная установка разрешения ручного управления ногами в соответствующих битах DCB (RTS_CONTROL_ENABLE, DTR_CONTROL_ENABLE).
W>Только скорее всего Вас занесло не туда — таким способом в Win32 данные (Tx) в порт не пишут.
W>Прочитать состояние RTS и DTR можно через GetCommModemStatus. Обычно отслеживают изменение состояния этих линий через WaitCommEvent.
W>Вообще API для работы с COM портом в Win32 прост — писать через WriteFile (иногда может пригодиться TransmitCommChar), читать через ReadFile. Всё остальное — настройки для этих операций (установка таймаутов, DCB и пр.)


Спасибо, почти самое то...
Проблема в том что мне не надо просто байт передать и байт принять. Есть софт который именно управляет ногами, я его прогоняю через com2com и вешаю свою программу на втором порту. Т.е. мне надо считывать сотояние ног , конретно проблема считать состояние ноги RX, остальные можно через CommStat взять...

Здравствуйте, FlashBack, Вы писали:

FB>Проблема в том что мне не надо просто байт передать и байт принять. Есть софт который именно управляет ногами, я его прогоняю через com2com и вешаю свою программу на втором порту. Т.е. мне надо считывать сотояние ног , конретно проблема считать состояние ноги RX [..]

Строго говоря, это в WinAPI это невозможно. Возможно следующее — если передатчик на своей стороне вызывает (в терминах WinAPI) SetCommBreak, линия Tx (для приёмника — Rx) переводится в состояние логического нуля и удерживается в этом состоянии какое-то время (до вызова передатчиком ClearCommError). Приёмник может отследить переход в состояние Break (продолжительный логический нуль на Rx) с помощью WaitCommEvent, после чего следует вызвать ClearCommError и посмотреть, установлен ли флаг CE_BREAK в lpErrors. Не знаю, сколько времени должен удерживаться логический нуль для определения состояния Break, но ясно что как минимум на порядок дольше времени передачи бита традиционным способом (через WriteFile).

[sorry]
имелось в виду "до вызова передатчиком ClearCommBreak", разумеется.
[/sorry]

Здравствуйте, wallaby, Вы писали:

FB>>конретно проблема считать состояние ноги RX [..]

W>Строго говоря, это в WinAPI это невозможно.

А что, где-то это возможно?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А что, где-то это возможно?

Непосредственно с регистрами микросхем UART очень давно дел не имел, да и разные они бывают — может, где-нибудь и возможно. Понятно, что для организации последовательной связи это не только не нужно, но и мешает.

Здравствуйте, wallaby, Вы писали:

ЕМ>>А что, где-то это возможно?

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

В 8250/82450/82550 такой возможности нет. С линии RX можно снять либо слово целиком, либо состояние Break, а оно регистрируется не раньше, чем линия достаточно долго пробудет в активном состоянии.