Возможно ли низкоуровневое управление RS232 (Com-Port) RTS/CTS/DTR/DSR?
Интересно, можно ли и как управлять линиями квитирования RS-232 напрямую из win32 (старый C-API).
Я хотел бы взаимодействовать с внешним оборудованием, и для моих нужд было бы достаточно двух простых линий данных.
Итак, есть ли API для win32, который позволяет мне читать и записывать состояние четырех строк состояния? В обычном последовательном соединении линии квитирования автоматически управляются UART (если аппаратное квитирование включено).
Я помню, что это было тривиально под DOS. Просто нужно было запрограммировать UART напрямую. Выжил ли этот функционал в win32 как-то?
5 ответов
Вы можете управлять RTS и DTR, используя SetCommState(), Вы также можете настроить аппаратное обеспечение или драйвер для управления аппаратным потоком (CTS и / или DSR), или вы можете настроить его, используя SetCommMask() так что вы получаете события, когда эти сигналы меняются.
Достойный обзор здесь: http://msdn.microsoft.com/en-us/library/ms810467.aspx
Обратите внимание, что Win32 Serial Comm API и / или драйвер могут быть привередливыми, поэтому будьте готовы к некоторой отладке того, что происходит в сети.
Я наткнулся на это руководство, когда мне нужно было создать проект для связи с портом RS232. Это полный пример того, как открыть порт, установить некоторые свойства, включая тайм-ауты, чтение / запись и закрыть порт. Хотя ваш проект, вероятно, уже завершен, я надеюсь, что он останется полезным, так как он остается в архивах SO.
Вы все еще можете выполнять подобные типы программирования только для того, чтобы получить доступ к защищенному оборудованию, которое вам потребуется для реализации драйвера устройства. Я предполагаю, что это стало легче с 1980-х годов, когда я выполнял такую же работу.
На самом ли деле Microsoft занимается аппаратным установлением связи? В течение многих лет NT, win2000 и XP не занимались рукопожатием в аппаратном обеспечении. Вместо этого, когда fifo достигнет определенной точки, драйвер устройства вручную изменит строку cts. Это означает, что было невероятно просто вызвать потерю данных драйвером устройства, захватить окно мышью и, например, сделать круг вокруг экрана (убедитесь, что вы снимаете это окно с левой стороны экрана на всех или некоторых проходах). Alt-enter, чтобы перевести командную строку в / из полноэкранного режима, был простым способом вызвать потерю данных. Или что-нибудь еще, что вызывает достаточную задержку прерывания. По сути, аппаратный контроль потока microsofts - это не аппаратный, а программный контроль потока, даже если аппаратное обеспечение имеет возможности аппаратного управления потоком, драйверы microsft не устанавливали этот бит. SeaLevel в конечном итоге все же поддерживал этот бит, ну и, конечно, вам пришлось поместить правильные несвязанные настройки в SetCommState(), чтобы включить его.
Что касается вашей программы, управляющей сигналами, используйте SetCommState().
Есть несколько адаптеров USB to Serial, которые не поддерживают управление потоком DTR/DSR/DCD. Так что, может быть, это ваш случай.