время чтения из последовательного порта на окнах

Question

Я пытаюсь реализовать протокол через последовательный порт на машине с Windows (XP). Проблема заключается в том, что синхронизация сообщений в протоколе осуществляется через пробел в сообщениях, то есть х миллисекундный промежуток между отправленными байтами означает новое сообщение. Теперь я не знаю, возможно ли вообще точно определить этот пробел.
Я использую Win32 / Serport.h API для чтения в одном из многих потоков нашего сервера. Данные из последовательного порта буферизуются, поэтому, если в нашем программном обеспечении достаточно (и будет достаточно) задержки, я получу несколько сообщений из буфера порта за одну последовательность операций чтения.

Есть ли способ чтения с последовательного порта, чтобы я мог обнаружить пропуски при получении определенных байтов?

Answer 1

Если вы хотите больше контроля над последовательным портом Windows, вам придется написать свой собственный драйвер.

Проблема, которую я вижу, заключается в том, что Windows может выполнять другие задачи или программы (например, проверку на вирусы), что приведет к проблемам синхронизации вашего приложения. Ваше приложение не будет знать, когда оно было заменено другим приложением.

Если возможно, я предлагаю вашей программе отметку времени окончания последнего сообщения. Когда приходит следующее сообщение, берется другая отметка времени. Разница между отметками времени может помочь в обнаружении новых сообщений.

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

Answer 2

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

Меня всегда удивляет, когда я сталкиваюсь с этими протоколами, в которых нет контекстной информации.

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

Другим подходом может быть использование API-функций CreateFile, ReadFile и WriteFile. Существуют настройки, которые можно изменить с помощью функции SetCommTimeouts, которая позволяет остановить операцию ввода-вывода при возникновении определенного промежутка времени.

Лучше всего сделать это вместе с умозрительным декодированием.

Answer 3

Я так и думал. Вы все выросли с паутиной, а я нет, хотя присутствовал при рождении. Позвольте мне угадать, один байт равен 1 (SOH) или 2 (STX)? IMVEO этого достаточно. Вам просто нужно мыслить нестандартно.

Вы получаете message_delimiter, за которым следуют 4 (длина) и затем 4 байта данных. Допустимое сообщение: , а не эти 6 байтов.

    message_delimiter - 1 byte
    4 - length - 1 byte
    (4 data bytes) - 4 bytes

Допустимое сообщение: всегда ограничено message_delimiter, поэтому оно будет выглядеть как

    message_delimiter - 1 byte
    4 - length - 1 bytes
    (4 data bytes) - 4 bytes
    message_delimiter - 1 byte

Answer 4

Звучит странно, что нет никакого формата данных, определяющего «сообщение» с устройства. Каждое устройство с последовательным портом, с которым я работал, имеет заголовок, описывающий передаваемые данные.

Просто добавьте это, но не могли бы вы использовать системные вызовы Win32 Asynchronous ReadFileEx () и WriteFileEx ()? Они позволяют вам присоединить функцию обратного вызова, и тогда вы сможете управлять таймером внутри обратного вызова. Однако таймер даст вам приблизительную оценку.

Если вам нужно написать собственный драйвер, в Windows Driver Kit есть пример, который показывает, как написать драйвер последовательного порта. Я не могу себе представить, что вы сможете переопределить драйвер шины последовательного порта Windows (драйвер, который непосредственно управляет последовательным портом на вашем компьютере с Windows), но вы можете написать драйвер, который находится поверх шины водитель.