Compact Framework последовательный порт и баланс

Question

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

Теперь вопрос в том, как определить, что соединение не было установлено из-за разных настроек? SerialPort.Open не генерирует никаких исключений, чтобы указать, что соединение установлено. Да, настройки действительны, но если они не соответствуют настройкам устройства (баланса); Я нахожусь в неведении относительно того, почему вес с баланса не захватывается.

Есть здесь какие-либо данные?

Answer 1

Не зная никакой дополнительной информации о формате данных, которые вы ожидаете от своего баланса, применимы только общие методы обнаружения несоответствия настроек последовательного порта.

Если настройки UART значительно неверны, вы, скорее всего, увидите множество ошибок кадрирования: когда UART ожидает 1 стоповый бит, он фактически увидит 0. Вы можете обнаружить это с помощью ErrorReceived событие на порту.

private void OnErrorReceived(object sender, SerialErrorReceivedEventArgs e)
{
    if ((e.EventType & SerialError.Frame) == SerialError.Frame)
    {
        // your settings don't match, try something else
    }
}

Answer 2

Последовательные порты используют очень, очень старую коммуникационную технологию, которая использует очень, очень старый протокол, называемый RS-232 . Это довольно просто: две конечные точки имеют синхронизированные тактовые импульсы, и они проверяют линейное напряжение каждый тактовый цикл, чтобы определить, является ли оно высоким или низким (с высоким значением 0 и низким значением 1, что противоположно большинства конвенций ... снова артефакт возраста протокола). Синхронизация часов осуществляется с помощью стоп-битов, которые на самом деле представляют собой просто время отдыха между байтами. Есть также некоторые другие вещи, добавленные в более продвинутые варианты использования протокола, такие как биты четности, XON / XOFF и т. Д., Но все они находятся на вершине этого самого базового уровня связи. Обнаружение несоответствия часов на каждом конце последовательной линии будет почти невозможно - вы просто получите неверные данные на приемном конце. Сам протокол не имеет встроенного способа идентифицировать эту ситуацию. Я не знаю ни одного последовательного драйвера, который достаточно умен, чтобы замечать, что входные данные синхронизируются с несоответствующей частотой. Если вы используете одну из схем обнаружения ошибок, таких как биты четности, вероятностно каждый байт будет объявлен ошибкой. Короче говоря, лучшее, что вы можете сделать, это проверить входящие данные на наличие ошибок (ошибки четности должны обнаруживаться вашим драйвером / программным уровнем, тогда как ошибки в данных, полученных вашим приложением с этого уровня, должны будут проверяться вашей программой - последнему может помочь использование контрольных сумм ).

Answer 3

Если что-то близко, но все еще неверно, объект последовательного порта .NET может даже не дать вам ошибку (то есть, пока не произойдет что-то катастрофическое).

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

Для программного рукопожатия (xon xoff) Вы можете сделать очень мало, чтобы определить, правильно ли он настроен. Объект последовательного порта может делать что угодно, от полного его игнорирования до появления ошибок исключения потоков, в зависимости от базовой реализации драйвера последовательного порта. У меня были драйверы последовательного порта, которые полностью игнорировали xon / xoff и передавали символы прямо в программу - yikes!

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

Другой параметр, который используется реже, - это вывод DTR - терминал данных готов Некоторые последовательные устройства требуют, чтобы это было подтверждено (т. Е. Установлено значение true), чтобы указать, что пришло время начать отправку данных. По умолчанию установлено значение false; Дай переключить это вихрь.

Обратите внимание, что объект последовательного порта ... привередлив. Хотя это и не обязательно, я бы рассмотрел закрытие порта, прежде чем вносить какие-либо изменения.

Edit:

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

• 1200 бод
• Нечетное соотношение
• 1 стоповый бит
• Аппаратное рукопожатие

Он не указывает, сколько битов данных, но устройство говорит, что оно поддерживает 7 и 8. Я бы попробовал оба из них. Он также говорит, что поддерживает 600, 1200, 2400, 4800, 9600 и 19200 бод.

Если вы включили аппаратное квитирование, включили DTR (разные вещи) и циклически переключались между разными скоростями передачи, есть хороший шанс, что это не ваши настройки. Возможно, используемый последовательный кабель неправильно подключен к вашему устройству. Некоторые последовательные кабели представляют собой сквозные кабели, где 1-9 штырьков на одной стороне точно совпадают с 1-9 штырьками на другой. Затем у вас есть «перекрестные» кабели, где кабели «TX» и «RX» коммутируются (так что, когда одна сторона передает, другая сторона получает очень удобный кабель).

Подумайте о том, чтобы посмотреть на таблицу команд в конце руководства; есть команда «версия программного обеспечения для печати», которую вы можете выполнить, чтобы получить какой-то тип эхо.