>>А это поможет в решении проблемы?
>Нет, не поможет. Просто, если в будущем у меня появится перспектива поработать
>с такими устройствами, сразу от них отказаться. Хотя бы намекни абревиатуру
>названия этого устройства.
>Если по существу твоего вопроса, то отследить значение бита четности или его
>наличие на _ПК_ нельзя, даже зная заранее скорость взаимодействия с устройством.
>Объясняю почему. Com-порт на ПК перед началом взаимодействия с внешним устройством
>устанавливается в определенный режим работы: скорость, контроль четности, количество бит в
>байте, количество стоп-битов и т.п. Com-порт не предназначен, точнее в него
>не закладывали такой функционал, чтобы на лету можно было менять режим
>работы в рамках взаимодействия с одним устройством. Автоопределение там тем более
>не заложено. Более того, пожет получиться такая ситуация:
>1)ты установил ком-порт в нужный режим работы
>2)получил первый байт от устройства
>3)начинаешь переключать ком-порт в другой режим работы
>4)пока ты переключал ком-порт, устройство тебе уже успело передать несколько байт, которые
>ты успешно профукал (пропустил)
>т.е. время переключения режима ком-порта может быть достаточно большим, чтобы пропустить переданные
>данные во время самого переключения, особенно это справедливо на больших скоростях
>передачи данных. Например, перед переключением режима ком-порта процессор может отвлечься на
>выполнение другой задачи, на этом ты потеряешь драгоценные миллисекунды.
>Если бы ты программировал микроконтроллеры, то эту задачу можно ещё было бы
>реализовать с некоторыми оговорками, но на обыкновенном ПК да при условии,
>что устройство первым начинает обмен (насколько я понял) - утонченное извращение.
>Реализовать задачу можно, но с очень высокой вероятностью ошибки и пропусками
>байтов. Ну тогда по порядку. Распространяться особо не буду, но скажу, что устройство - игральный автомат, протокол - SAS, на сегодняшний день всеми авторитетами в игральном мире признан как самый лучший протокол для связи с ПК. Дальше: утверждаю, что проверить бит четности на _ПК_ при его наличии _можно_, и для этого совсем не надо каждый раз переключать настройки порта (см. совет от pvl выше). Для этого всего лишь надо один раз настроить порт на проверку бита четности (все равно как). При этом принимающая сторона (serial port) будет его проверять и при несовпадении бита четности с реальным значением паритета принятого байта будет слать в тот же поток код ошибки. Все что остается сделать - для каждого принятого байта самому посчитать паритет и по наличию ошибки определить, какой был бит паритета. Эта схема работает без проблем, тестировалась на скорости 19200, да она, скорее всего, в этом случае вообще значения не имеет - проверка идет на программном уровне уже принятых байтов, поэтому даже на очень больших скоростях можно просто сложить все принятые байты в какой-нибудь временный буффер, а анализировать их когда будет удобнее. Если необходимо взаимодействие в реальном режиме времени, будет несколько сложнее, но в любом случае, эта проверка на бит четности совсем не сложная и даже на медленных компах должна выполняться достаточно быстро. Приблизительно описанная вами проблема возникает при установке необходимого бита четности при отправке с _ПК_ - для этого надо переключать режимы для каждого отправляемого байта. Но даже здесь измерения показали, что для указанной скорости время переключения и _применения_ настроек меньше времени отправки одного байта. Сложность здесь в другом - при переключении настроек порта он пытается применить новые настройки для уже принятых в буффер, но еще не отправленных байтов (при опции TCSANOW), либо ждать их отправки (TCSADRAIN)- но в этом случае время между двумя байтами становится для меня (протокола) недопустимо большим - около 8-10 микросекунд (максимально до пустимо протоколом 5). Можно также флашить буффер (TCSAFLUSH) - но при этом все принятые, но не отправленные байты просто отбрасываются, что, естесственно, плохо. Поэтому я сейчас ищу способ заставить ожидать отправки всех поставленных в очередь байтов меньше времени (возможно, с помощью каких-либо сигналов), либо придется писать какой-то свой драйвер. Если есть мысли по этому поводу, с радостью выслушаю.
|
