Существует ли соглашение о передаче номеров деталей через последовательный порт?

Question

У меня есть несколько устройств, которые читают RFID-метку и передают серийный номер метки через последовательный порт.

Мне кажется, что "лучше" использовать два байта для каждой цифры серийного номера, тем более что некоторые устройства отправляют завершающий 0x0D 0xA (CR / LF).

Теперь я нахожу одно устройство, которое использует один байт на цифру, поэтому для отправки «12» оно отправляет не 0x31, 0x32, а скорее 0x12. Это означает, что я не могу отличить CR / LF от реального 0xA и 0xD. Я спрашиваю и получаю некоторую вафлю об этом неважно, поскольку строки имеют фиксированную длину - так зачем же беспокоиться о CR LF? И, чтобы быть (не) согласованными, они используют два байта каждый для CR / LF.

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

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

Answer 1

Серийный номер - вещь, которая никогда не становилась стандартной. Способ передачи - это стандарт, но то, что отправляется, всегда зависит от разработчиков аппаратного / программного обеспечения. Большинство устройств имеют какой-то пакет информации. Обычно идет что-то вроде STARTBYTE, DATA, CHECKSUM и sumtimes ~ CHECKSUM (обратная контрольная сумма) и, возможно, STOPBYTE. Контрольная сумма помогает вам убедиться, что ваши данные верны, но при отправке контрольной суммы всего несколько байтов.

Чтобы ответить на ваш вопрос. Это фантастическая идея - обеспечить максимально точные данные. Это означает, что вы даже не хотите путать CR / LF с вашим идентификатором тега. Вы можете либо удостовериться, что это не CR и LF программно - тогда это действительный идентификатор, либо запросить изменение микропрограммы. Кажется, что большинству компаний нравится отправлять серийные данные в виде простого текста. Я не предпочитаю это, так как это громоздко и откровенно трата производительности (если вам нужна скорость в вашем процессе). Мне легче читать каждый байт пакета и интерпретировать соответственно. Вы можете даже попросить их сделать что-то подобное. 0xFF 0x00 ДАННЫЕ0 ДАННЫЕ1 0xFF. это использует 2 начальных байта и стоп-байт. Он отправляет немного больше данных, но помогает убедиться, что вы получаете действительные данные. В вашем коде вы можете проверить на 0xFF 0x00 и 0xFF в конце. Если вы этого не получите, значит, у вас нет действительного пакета.

Если вы не хотите использовать пакеты, вы всегда можете просто проверить CR / LF вместе, я надеюсь, что компании, которые создают RFID-теги, не будут использовать CR / LF в качестве своего идентификатора на одном.

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

1. Формирование информации о пакетах данных
2. Концепции последовательной связи
3. Пример последовательной связи с устройством
4. Очень хороший веб-сайт по общей последовательной и пакетной интерпретации с примерами кода

Если вам нужна дополнительная помощь, пожалуйста, дайте мне знать.

Answer 2

Всегда включайте байт, который указывает, как долго сообщение - или все сообщение, или только область данных.Он стоит всего один байт (при условии, что сообщения <256 байт) и облегчает анализ сообщения <em>намного .