Определите, подключено ли устройство к порту RS232, не открывая его.

Question

Я работаю над приложением C32 для Win32, для которого я пытаюсь по существу «автоматически определить», было ли устройство подключено к одному из портов RS232, а затем, если оно было отключено.

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

Обнаружение разъединения - то, где я сталкиваюсь с проблемой. Когда я сканирую подключенные устройства, я на самом деле могу отправить данные в порт, чтобы убедиться, что, если есть устройство, это именно то устройство, которое я ищу. Но после подключения этот порт будет уже открыт другим процессом, и я больше не могу открыть этот порт из потока обнаружения. Поэтому я ищу способ открыть порт в «режиме прослушивания» или что-то в этом роде, чтобы я мог просто увидеть, есть ли еще устройство.

Я кратко наткнулся на что-то о просмотре линии DSR или DTR или что-то в этом роде ... но больше не мог найти или как на самом деле это сделать.

Есть предложения?

Редактировать: Похоже, мне нужно уточнить немного больше ... Для обнаружения разъединения я не может отправлять данные на порт RS232 любым способом. Кроме того, я не могу предположить, что у другого приложения фактически открыт порт. Устройство может быть физически подключено, но без и открыть соединение ... но я все еще не могу рисковать отправкой данных на него. Я надеялся, что есть способ просто проверить, есть ли еще питание на этом порту или что-то в этом роде.

Answer 1

Это зависит от подключенного оборудования, будет ли изменение в регистрах состояния модема при отключении оборудования, но если оно есть, вы можете проверить состояние, например, линии CTS или DSR, используя GetCommModemStatus () функция.

Однако существует проблема, связанная с тем, что вам нужен дескриптор файла для COM-порта для вызова любой функции API, и это является исключительным, поскольку документация CreateFile () гласит:

Функция CreateFile может создавать дескриптор коммуникационного ресурса, такого как последовательный порт COM1. Для коммуникационных ресурсов параметр dwCreationDisposition должен быть OPEN_EXISTING, параметр dwShareMode должен быть нулевым (исключительный доступ)

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

Есть способы сделать это, но они связаны с водителем. SysInternals имеет инструмент Portmon , и поиск Google найдет некоторые компании, продающие программное обеспечение для обмена доступом к COM-портам между приложениями, но одновременный доступ AFAIK невозможен при использовании стандартного API.

Answer 2

Похоже, что было бы неплохо иметь этот процесс, который будет уведомлять о подключенных и отключенных событиях, а также передавать данные другому процессу. Пусть ваше приложение работает в слоях, так что существует процесс, который контролирует соединение RS232 и отправляет события приложения верхнего уровня: подключено, отключено, доступны данные и т. Д.

Answer 3

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

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

Условием по умолчанию является то, что поток опрашивает порт каждые несколько секунд, и пока нет ответа, предположим, что устройство не подключено. Как только устройство, кажется, отвечает, измените состояние, чтобы указать, что это так.

Я разработал приложение с несколькими очередями: одно с отключенными потоками, одно с подключенными, но незанятыми потоками, а другое с подключенными и занятыми потоками. Контроллер перемещал потоки между очередями, когда они меняли состояние.