Rs 232 framing error - Исправление ошибок и поиск оптимальных решений проблем

Содержание

RS232 Unusual «Framing Error»
Неизвестный UART: теория
RS-232
Работа над ошибками
Мажорирование
Оверсемплинг
Ошибки логики
Заключение

RS232 Unusual «Framing Error»

I have an old piece of instrument that suppose to connect with a Windows XP machine. I keep getting «Framing Error» messages on the instrument panel while the PC side shows that the instrument could not be found.

The instrument uses RS232C in a 9 pin serial port to connect to the PC. If I understand correctly, RS232C is the same as the prevailing RS232 on Windows XP. I have tested the serial port on the XP machine with Hyper Terminal, and made sure I use the proper «straight through» type of cable. The cable has been used on the same location with other instrument and worked properly.

In order to connect the instrument with an XP machine, I have set the following parameters to be the same on both sides:

However, on the instrument side, there is an item called «terminator» with CR, LF, and CR+LF settings, which is not available on the serial port settings for Windows XP. I tries all three settings but none worked.

What should I do next?

According to the service manual:

An RS232C format serial port is available at the DE-9 connector J3. U8 provides voltage level translation from +5 volts and ground to ± 12 volts. Direct I/O control lines are used for all signals because of the timing critical nature of the communications protocol. Two data lines (TXD/RXD) are used and two control lines (RTS/CTS) are available for hardware handshaking if enabled by the software. .

Источник

Неизвестный UART: теория

Можно с уверенностью сказать, что с момента публикации первой версии стандарта RS‑232 в мае 1960 года и по настоящее время, было написано приблизительно 10 9 независимых реализаций UART на всём, чём угодно. Однако, подобно «Hello world» в мире прикладного ПО, а также мигания светодиодом — «Hello world» в мире цифровой электроники (сигнализирующий об успешной настройке оборудования и среды разработки) — процесс написания UART способен проиллюстрировать особенности языка или платформы, демонстрируя применение тех или иных синтаксических конструкций для решения практических, насущных и понятных проблем.

В данном цикле статей будет рассказано про написание модуля UART на SystemVerilog, про синтез данного модуля на различных платформах и про некоторые другие аспекты применения UART в ПЛИС. Но прежде, чем писать код, поговорим про сам протокол и про особенности аппаратной части вне контекста ПЛИС.

RS-232

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

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

Правда, без дополнительных условий будет невозможно отправить байт, состоящий из одних единиц, либо отличить последовательность 11010100 от 01010011.

Можно условиться, что к каждому передаваемому байту мы припишем дополнительный служебный бит (старт-бит), заведомо содержащий логический ноль. Тогда после паузы в передаче данных, приёмник при получении нисходящего фронта будет готов к приёму оговоренного количества бит, содержащих осмысленные данные.

Остаётся проблема: что, если будет передаваться длинная последовательность бит, содержащих нулевые значения без пауз между отдельными байтами? Тогда, рано или поздно, накопленная рассинхронизация тактовых генераторов источника и приёмника превысит половину длительности одного бита. И приёмник либо дважды прочитает один и тот же передаваемый бит, либо наоборот, пропустит один из передаваемых битов.

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

Договорившись о наличии старт-бита, стоп-битов, количестве битов данных в рамках одной передачи («символа» в терминологии UART) от старт-бита до стоп-бита и частоте следования бит можно организовать устойчивую однонаправленную передачу данных по одному проводу.

Стандарт RS-232 задаёт значение выходного напряжения логической единицы от −5 до −15 В, а логического нуля — от +5 до +15 В (именно в таком порядке). Данные уровни напряжения не поддерживаются микросхемами ПЛИС напрямую и существует несколько вариантов соединения ПЛИС с компьютером через RS‑232.

Если у компьютера предусмотрен com-порт, то соединение возможно при помощи пассивного кабеля и транслятора уровней. Зачастую трансляторы уровней для RS‑232 (к примеру, ADM3232E) изготавливают с встроенным умножителем (удвоителем) напряжения на основе переключаемых конденсаторов. Он преобразует +3,3 В в приблизительно ±6,6 В, которые используются в качестве уровней выходного сигнала на линии TX. А вход RX делают устойчивым к напряжениям вплоть до ±15 В.

Если у компьютера отсутствует встроенный com-порт, то соединение возможно при помощи внешнего преобразователя USB-RS232 (к примеру, UPort1150).

В этом случае иногда происходит некоторая путаница с разъёмами. Если разъём DB-9 на материнской плате — всегда «папа» (штыри), то разъём на оборудовании почти всегда «папа». Исключение — прецизионные источники питания компании Keithley (которую купил Tektronix). У них разъём «мама» (гнёзда). Разъём же на преобразователях USB-RS232 почти всегда, как и на материнских платах — «папа». Соответственно, он может быть подключен к Keithley непосредственно. Но для большинства оборудования дополнительно потребуется кабель «мама-мама». Разъём DB-9 предусматривает наличие стягивающих винтов. И ввиду того, что их не расположить внутри корпуса оборудования, то ими оснащается именно кабель. А на разъёмах оборудования делают гайки, куда эти винты закручиваются.

У преобразователя MOXA — гайки, у noname — винты. И у обоих в разъёме — штыри.

И, казалось бы, если на преобразователях USB-RS232 стоит разъём «папа» (для соединения с «мамой» кабеля, оснащённого винтами), то на нём должны быть гайки. Однако, данный элемент с вероятностью 50/50 будет также винтом! Зато к Keithley подходит идеально 🙂 В общем, если вы решили соединять оборудование с компьютером и хотите чтобы всё собралось с первого раза, не полагайтесь на то, что «всё стандартизовано, тут не ошибёшься» и обратите внимание:

на разъём в оборудовании и преобразователе (штыри/гнёзда)

на крепления в оборудовании и преобразователе (винты/гайки)

Электронная промышленность предоставляет широкую номенклатуру мостов USB-UART. Благодаря им, при создании устройства можно использовать все аппаратные плюсы интерфейса USB и при этом сохранить относительную простоту программного обеспечения, характерную для RS-232. В дальнейшем мы будем рассматривать именно этот вариант соединения, хотя с точки зрения кода для ПЛИС, разницы между предыдущими тремя примерами нет.

Есть, правда, весьма важный момент. Сам стандарт TIA/EIA-232-F (RS-232) содержит лишь электрические характеристики и размеры разъёмов. Типичные же скорости передачи данных, количество бит данных в символе, а также наличие/отсутствие дополнительного бита контрольной суммы (бита чётности) этим стандартом не оговаривается. Иногда можно встретить утверждение, что перечисленные выше аспекты оговорены в UART («Universal Asyncronous Receiver-Transmitter»), но это общее название некоторого свода обычаев передачи данных. Этому своду не соответствует какой-либо один-единственный написанный и утверждённый стандарт.

Неким подобием стандарта может считаться структура DCB, применяемая в функции SetCommState в Windows API и предназначенная для инициализации com-порта.

Так, в описании данной структуры говорится, что в символе UART может быть 1/1,5/2 стоп-бита. Однако, стандарт «ISO/IEC 7816-3», похожий на «обычный» UART и регламентирующий обмен данными со смарт-картами, предусматривает наличие 0,5 стоп-бита. И, к примеру, микроконтроллер STM32F103 способен через конфигурационные биты «STOP» ([13:12]) регистра «USART_CR2» задать режим работы модуля UART как с этим самым половинным стоп-битом, так и с более распространёнными количествами стоп-битов. А мост FT232R не только не способен поддерживать половинный стоп-бит, но также не способен поддерживать полуторный стоп-бит: только один или два стоп-бита.

Или в описании структуры DCB говорится, что значащих бит в одном символе UART может быть от 5 до 8 штук (в это количество не входит бит чётности). А уже упомянутый мост FT232R способен работать только с 7 или 8 битами. Однако, другой похожий на UART стандарт — MDB («Multi-Drop Bus») — содержит, по сути, 9 значащих бит (8 бит данных, плюс бит режима/направления). И микроконтроллер STM32F103 способен работать как с MDB, так и с 8-битным UART.

Теперь, если мы возьмём материнскую плату или преобразователь USB-RS232, вроде «UPort 1115», мы сможем сказать «где-то там есть RS-232». Однако, если мы возьмём микросхему-мост USB-UART с уровнями на линиях RX/TX равными +3,3/0 В, сложится парадоксальная ситуация: описываемые в TIA/EIA-232-F напряжения нигде не соблюдаются, а протокол, реализуемый этим мостом не описан в самом стандарте. То есть RS-232, упоминаемый в подобном контексте, приобретает некоторые постмодернистские черты симулякра — символа, у которого нет оригинала 🙂

Возможно также соединить линии USB напрямую к ПЛИС и наделить ПЛИС функционалом, позволяющим ей опознаваться компьютером как USB-устройство класса CDC («Communication Device Class») — то есть как com-порт. Однако, тратить (и в весьма большом количестве!) логические элементы ПЛИС на столь обыденную задачу, реализованную в готовых микросхемах USB-UART имеет смысл только в рамках учебных задач, связанных с изучением протокола USB.

Работа над ошибками

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

нестабильности электрических параметров сигнала

нестабильности временных параметров сигнала

нарушение в логике приёма/передачи

Обсудим ряд аспектов, связанных с каждой из этих групп.

Мажорирование

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

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

Предположим, что ошибки в ходе замеров являются независимыми друг от друга и появляются с вероятностью «p». Выпишем в таблицу все 8 возможных комбинаций 3-битного числа. Но вместо единиц в ячейках таблицы запишем вероятность ошибки в конкретном замере («p»), а вместо нулей — вероятность верного считывания («1-p»). Вероятность появления каждой комбинации будет равна произведению содержимого ячеек соответствующего столбца. Поэтому отметим те комбинации, которые всё же приведут к ошибочному считыванию бита при мажорировании, определим вероятности появления этих комбинаций и сложим их всех.

Как видно, вероятность ошибки при мажорировании будет равна:

Или, если раскрыть скобки и упростить выражение, то:

Пока что влияние мажорирования может просматриваться не слишком явно. Для более чёткой картины возьмём десятичный логарифм «p_maj»:

Преобразуем это выражение. Для начала вынесем за скобки логарифмируемого выражения квадрат «p»:

Затем заменим произведение логарифмируемого выражение на сумму логарифмов:

С уменьшением «p», второе слагаемое (второй логарифм) достаточно быстро будет стремиться к десятичному логарифму трёх, который равен 0,477 (так, при «p» равном 10 -2 (одна ошибка на сто бит) это слагаемое уже будет равно 0,474).

Иными словами, если вероятность ошибки равна:

. то вероятность ошибки с использованием мажорирования по трём замерам приблизительно равна:

Здесь «x» по идее должен принимать значения от «0» до «-∞», но при приближении к нулю (то есть при приближении «p» к единице) начнут сказываться допущения. Однако уже при «x», равном «-1» (то есть одна ошибка на десять бит), приближённые значения будут отличаться от точных значений всего на 2%.

Представим, что происходит передача данных по UART с конфигурацией «старт‑бит/8 бит данных/стоп‑бит» на скорости 9600 бит/с и «p» равно 10 -6 . Это означает, что одна ошибка происходит в среднем один раз в две минуты (130 секунд, если точнее). Поиск причины ошибки, появление которой видится квази-случайным и происходит раз в несколько минут, является достаточно неприятным и трудозатратным занятием. Если же мы применим мажорирование, то ошибка, в теории, начнёт возникать с вероятностью 10 -11,523 . Или приблизительно один раз в 16,5 месяцев. Вроде бы отличный результат.

Однако, что если «p» равно 10 -4 ? Что если ошибка происходит один раз в секунду (1,3 секунды, если точнее), но инженер принял решение не кропотливо настраивать различные условия захвата в цифровом осциллографе с целью выявления причин ошибки, а применить мажорирование, и оно сработало идеальным образом?

Тогда «p_maj» будет равно 10 -7,523 . Или приблизительно один раз в 72 минуты — как раз достаточно, чтобы в случае претензий сказать: «Ну и где? Где эта ошибка? Вот, всё же работает! А вы говорите!» и убыть в закат 🙂

Кроме того, предположение о том, что ошибки в различных замерах одного бита являются независимыми не совсем верно. Предположим, что ошибка при считывании очередного бита появляется из-за наводки, скачка в цепи питания, либо чего-то подобного. Если мажорирование не применяется, вероятность ошибки «p» тогда будет равна произведению вероятности возникновения помехи «p_noise» на отношение длительности помехи «t_noise» к длительности бита «T»:

Одинаковую вероятность ошибки может создать как длительная, но редкая помеха, так и короткая, но часто повторяющаяся помеха. Однако, часто повторяющуюся помеху («p_noise» которой много больше, чем собственно «p») будет легче обнаружить, проанализировать и выявить её источник. А редко повторяющаяся помеха, та, от поиска которой, по идее, и должно защитить мажорирование, будет длительной помехой, способной в ряде случаев «накрыть» сразу несколько замеров.

В общем, методы коррекции ошибок, применяемые бездумно, способны как решить проблему, так и в отдельных случаях оказаться заметанием мусора под ковёр или вообще не сработать.

Оверсемплинг

Представим, к примеру, ардуиновский микроконтроллер ATmega328P. В нём битрейт модуля USART задаётся при помощи делителя «UBRR» (он записывается в регистры «UBRRnL» и «UBRRnH») и равен:

Допустим, частота f_OSC равна 10 МГц, а нам требуется получить стандартные 9600 бит/с. Тогда наиболее подходящим значением UBRR будет «64». Благодаря ему удастся задать битрейт, равный 9615,4 бит/с. Погрешность в 0,16% кажется незначительной, однако она накапливается с каждым битом. И для последнего фронта в символе составит 1,44%.

Точность внутреннего RC-генератора для того же микроконтроллера ATmega328P при фиксированной температуре в 25°C и напряжении 3,0 В заявлена ±2%. Во всём диапазоне рабочих температур и напряжений заявленная точность генератора падает до крайне грубых ±14%.

Нестабильность генератора создаёт дополнительную погрешность, которая хоть и не накапливается с каждым битом, но в конце символа способна сложиться с одним и тем же знаком с погрешностью от деления частоты. При этом, суммарная погрешность передатчика может удлинить передаваемые им биты, а суммарная погрешность приёмника — укоротить считываемые им биты. То есть, по сути, погрешности сложатся по модулю.

Если считывание производится непосредственно с частотой битрейта, то рано или поздно возникнет ситуация, когда принимающее устройство зафиксирует появление старт-бита не в середине бита, а в самом его начале (сразу после появления нисходящего фронта) или же в самом конце (перед первым битом данных). Причём сколь угодно близко к фронту. И к последнему биту символа приёмник гарантированно рассогласуется с передатчиком.

Решением этой проблемы является многократное считывание логического состояния на линии RX — оверсемплинг. После первого считывания, результат которого может быть принят за старт-бит, приёмник ожидает половину битового периода и только начиная с этого момента приступает к считыванию бит через равные промежутки времени. При четырёхкратном чтении, ошибки передачи будут отсутствовать при общей временно́й погрешности, доходящей до 25%!

На этом месте может возникнуть пара вопросов:

Какова временная погрешность приёмопередатчиков UART в реальных устройствах?

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

Отвечая на первый вопрос, можно обратиться к документу «Determining Clock Accuracy Requirements for UART Communications», выпущенный компанией Maxim Integrated (на текущий момент она поглощена компанией Analog Devices), который говорит следующее:

It is difficult to quantitatively assess a worst-case acceptable sampling range across a bit’s period. EIA/TIA-232-F does specify a 4% of bit-period maximum slew time for a transmission, but this is difficult to achieve for long runs at 192kbps. But for the purpose of this application note, let us define two data path scenarios. Consider a «nasty» scenario, which can only be sampled reliably within the middle 50% of the bit time. This could equate to a long capacitive RS-232 run. The «normal» scenario can be sampled within the middle 75% of the bit time.

То есть инженеры Maxim Integrated предполагают, что невозможность корректно считать значения на линии RX в течении 25% от длительности бита — это вполне нормальное явление.

Если же проводить тест по маске, к примеру, для платы производства WaveShare с микросхемой FT232RL (с внутренним тактовым генератором) при битрейте 9600 бит/с, то из допуска ±2% от длительности бита последний фронт символа (восходящий фронт стоп-бита) будет «вываливаться» с вероятностью 0,55%. А из допуска ±4% с вероятностью 0,5×10 -5 %. Можно предположить, что допуск в 10–12% (±5…6%) будет достаточно широк для того, чтобы считать вероятность выхода из него несущественной величиной. Если происходит обмен данными между двумя устройствами с допуском в 10…12% у каждого, то имеет смысл говорить об общей погрешности как раз в 20…24%.

Для ответа на второй вопрос представим себе, что у нас есть 8-кратный оверсемплинг и 25% общей погрешности, связанной с временными характеристиками. Два семпла окажутся в зоне 25%. Ещё на один семпл попадает «игла», которую мы пытаемся устранить при помощи мажорирования (ведь исправлять помехи имеет смысл только когда они есть, а словосочетание «есть помеха» означает, что помехи попадают по семплам). Итого мы получим 5 годных для мажорирования семплов к которым добавлено 3 гарантированно ненадёжных семпла.

Подобная конструкция не представляется такой уж надёжной. Поэтому, к примеру, в STM32F103 коррекция ошибок (мажорирование по восьмому, девятому и десятому семплам бита), дополнена механизмом сигнализация об их наличии.

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

Ошибки логики

Является ли ошибкой отсутствие стоп-бита? То есть если был передан старт-бит, затем оговоренные N бит данных, а после этого стоп-бит не появился (линия вместо стоп-бита оказалась в состоянии логического нуля)? Не всегда. Так, стандарт «ANSI E1.11», описывающий протокол обмена данными светотехнического оборудования DMX512, похожий на классический UART, использует при передаче данных аналогичное действие. При номинальной длительности бита DMX512 равной 4 мкс, переход в логический ноль и последующее удержание этого состояния в течение 92 мкс (то есть 23 нулевых бита подряд) или более, называется «break» и маркирует начало очередного пакета данных.

Однако, в общем случае, если передаваемый символ состоял не только из нулей, отсутствие стоп-бита будет, пожалуй, именно ошибкой — «framing error».

Является ли ошибкой отсутствие второго стоп-бита, если на стороне компьютера был выбран режим с двумя стоп-битами, а коммуницирующее устройство было настроено на работу с одним стоп-битом?

Пожалуй, нет. Так, в документации на ардуиновский микроконтроллер ATmega328P написано:

The Receiver and Transmitter use the same setting. Note that changing the setting of any of these bits will corrupt all ongoing communication for both the Receiver and Transmitter. An FE (Frame Error) will only be detected in cases where the first stop bit is zero.

Ещё более подчёркнуто это написано в документации на упоминавшиеся микроконтроллеры STM32F103:

2 stop bits: Sampling for 2 stop bits is done on the 8th, 9th and 10th samples of the first stop bit. If a framing error is detected during the first stop bit the framing error flag will be set. The second stop bit is not checked for framing error.

Относительно современная микросхема Super-I/O NCT6776D, реализующая UART на материнских платах, косвенно ссылается в своей документации на ставшую де-факто стандартом, классическую микросхему PC16550D:

NSER (No Stop Bit Error). This bit is set to logical 1 to indicate that the received data have no stop bit. In 16550 mode, it indicates the same condition for the data on the top of the FIFO. When the CPU reads USR, it sets this bit to logical 0.

А в документации на микросхему PC16550D написано:

If bit 2 is a logic 0, one Stop bit is generated in the transmitted data. If bit 2 is a logic 1 when a 5-bit word length is selected via bits 0 and 1, one and a half Stop bits are generated. If bit 2 is a logic 1 when either a 6-, 7-, or 8-bit word length is selected, two Stop bits are generated. The Receiver checks the first Stop bit only, regardless of the number of Stop bits selected.

Заключение

Типичная схема применения UART — это старт-бит, 8 бит данных и один-единственный стоп-бит. Типичный битрейт — 9600 бит/с (то есть длительность любого бита будет равна 104,17 мкс). В типичном случае «break frame» (большое количество нулевых бит) не применяется и будет просто ошибкой передачи. Так что базово UART относительно прост.

А упомянутые в статье особые случаи являются исключениями. О существовании которых, однако, имеет смысл знать. Также имеет смысл знать о практике применения данного протокола в индустрии. К примеру, посмотреть, какие возможности предоставляют различные микросхемы мостов USB-UART. Их детальный обзор — в другой раз.

Источник

I recently acquired a Keithely 2000 DMM (manufactured around 1997/1998) and wanted to try my hand at data logging. The GPIB port is out of reach for me, since I can’t find the right connector locally and buying one is out of question because of the expense. I was sent an RS232 to USB converter cable, which I want to use.
The first test I did was connecting up the cable to my laptop running Windows 11. I used the Arduino serial monitor to connect up to the right COM port and send commands. I was able to successfully talk to the meter and send commands like :volt:dc:meas? and get readings back from the meter. I was also able to get readings from a Python script written to acquire data.
Now to do actual data logging, I didn’t want to use the laptop since they have a tendency to randomly go into sleep mode and interrupt communication, and, of course, nothing needs to be said about Windows itself. I have a Raspberry Pi 4B running Raspbian which I decided to use. I connected the K2000 to one of the USB ports using the same cable I used with the laptop. I ran the same python script (only the COM port name was changed), but the meter gave me a +800 error — RS232 framing error detected. I installed the Arduino software on the Pi as well and tried to talk to the meter using the serial monitor the same way I had done on Windows, but no luck. I scoped the waveforms on the meter’s RS232 level shifter IC output (to the meter), and noticed that on Rasbpian, there is an extra low bit added after each byte. I assumed this was the problem.
I hooked up a Pi Pico to act as a bridge (https://github.com/Noltari/pico-uart-bridge), and this time the waveforms looked satisfactory, but the meter still gave me the +800 error.
I’ve been trying to talk to this thing using the Pi 4B for days now, and I have run out of solutions :palm: . Would greatly appreciate help or advice.
Thanks, NNNI
P.S. Picture attached is of a scope waveform, white reference waveform is Raspbian, yellow is from Windows. :n is invalid to the meter, but I transmitted only two bytes so it’s easier to debug the timings.
P.P.S The meter’s donor also tried the same thing with his K2000, and he gets the same error so at least it’s reproducible.

Источник

Можно с уверенностью сказать, что с момента публикации первой версии стандарта RS‑232 в мае 1960 года и по настоящее время, было написано приблизительно 10⁹ независимых реализаций UART на всём, чём угодно. Однако, подобно «Hello world» в мире прикладного ПО, а также мигания светодиодом — «Hello world» в мире цифровой электроники (сигнализирующий об успешной настройке оборудования и среды разработки) — процесс написания UART способен проиллюстрировать особенности языка или платформы, демонстрируя применение тех или иных синтаксических конструкций для решения практических, насущных и понятных проблем.

RS-232

У преобразователя MOXA — гайки, у noname — винты. И у обоих в разъёме — штыри.

И, казалось бы, если на преобразователях USB-RS232 стоит разъём «папа» (для соединения с «мамой» кабеля, оснащённого винтами), то на нём должны быть гайки. Однако, данный элемент с вероятностью 50/50 будет также винтом! Зато к Keithley подходит идеально В общем, если вы решили соединять оборудование с компьютером и хотите чтобы всё собралось с первого раза, не полагайтесь на то, что «всё стандартизовано, тут не ошибёшься» и обратите внимание:

на разъём в оборудовании и преобразователе (штыри/гнёзда)
на крепления в оборудовании и преобразователе (винты/гайки)

Работа над ошибками

нестабильности электрических параметров сигнала
нестабильности временных параметров сигнала
нарушение в логике приёма/передачи

Обсудим ряд аспектов, связанных с каждой из этих групп.

Мажорирование

Немного формул

Как видно, вероятность ошибки при мажорировании будет равна:

$p_{maj}=p^3+3(p^2(1-p))$

Или, если раскрыть скобки и упростить выражение, то:

$p_{maj}=3p^2-2p^2$

$log_{10}(3p^2-2p^3)$

Преобразуем это выражение. Для начала вынесем за скобки логарифмируемого выражения квадрат «p»:

$log_{10}{(p^2(3-2p))}$

Затем заменим произведение логарифмируемого выражение на сумму логарифмов:

$log_{10}(p^2)+log_{10}(3-2p)$

С уменьшением «p», второе слагаемое (второй логарифм) достаточно быстро будет стремиться к десятичному логарифму трёх, который равен 0,477 (так, при «p» равном 10^-2 (одна ошибка на сто бит) это слагаемое уже будет равно 0,474).

Иными словами, если вероятность ошибки равна:

…то вероятность ошибки с использованием мажорирования по трём замерам приблизительно равна:

$p_{maj}≈10^{2x+0,477}$

Представим, что происходит передача данных по UART с конфигурацией «старт‑бит/8 бит данных/стоп‑бит» на скорости 9600 бит/с и «p» равно 10^-6. Это означает, что одна ошибка происходит в среднем один раз в две минуты (130 секунд, если точнее). Поиск причины ошибки, появление которой видится квази-случайным и происходит раз в несколько минут, является достаточно неприятным и трудозатратным занятием. Если же мы применим мажорирование, то ошибка, в теории, начнёт возникать с вероятностью 10^-11,523. Или приблизительно один раз в 16,5 месяцев. Вроде бы отличный результат.

Однако, что если «p» равно 10^-4? Что если ошибка происходит один раз в секунду (1,3 секунды, если точнее), но инженер принял решение не кропотливо настраивать различные условия захвата в цифровом осциллографе с целью выявления причин ошибки, а применить мажорирование, и оно сработало идеальным образом?

Тогда «p_maj» будет равно 10^-7,523. Или приблизительно один раз в 72 минуты — как раз достаточно, чтобы в случае претензий сказать: «Ну и где? Где эта ошибка? Вот, всё же работает! А вы говорите!» и убыть в закат

$p=p_{noise}frac{t_{noise}}{T}$

Оверсемплинг

$BAUD=frac{f_{osc}}{16(UBRR-1)}$

На этом месте может возникнуть пара вопросов:

Какова временная погрешность приёмопередатчиков UART в реальных устройствах?
Если приёмник всё равно производит многократное чтение одного и того же бита, возможно ли получаемые данные эффективно использовать также для мажорирования?

It is difficult to quantitatively assess a worst-case acceptable sampling range across a bit’s period. EIA/TIA-232-F does specify a 4% of bit-period maximum slew time for a transmission, but this is difficult to achieve for long runs at 192kbps. But for the purpose of this application note, let us define two data path scenarios. Consider a «nasty» scenario, which can only be sampled reliably within the middle 50% of the bit time. This could equate to a long capacitive RS-232 run. The «normal» scenario can be sampled within the middle 75% of the bit time.

Если же проводить тест по маске, к примеру, для платы производства WaveShare с микросхемой FT232RL (с внутренним тактовым генератором) при битрейте 9600 бит/с, то из допуска ±2% от длительности бита последний фронт символа (восходящий фронт стоп-бита) будет «вываливаться» с вероятностью 0,55%. А из допуска ±4% с вероятностью 0,5×10^-5%. Можно предположить, что допуск в 10–12% (±5…6%) будет достаточно широк для того, чтобы считать вероятность выхода из него несущественной величиной. Если происходит обмен данными между двумя устройствами с допуском в 10…12% у каждого, то имеет смысл говорить об общей погрешности как раз в 20…24%.

Ошибки логики

Пожалуй, нет. Так, в документации на ардуиновский микроконтроллер ATmega328P написано:

The Receiver and Transmitter use the same setting. Note that changing the setting of any of these bits will corrupt all ongoing communication for both the Receiver and Transmitter. An FE (Frame Error) will only be detected in cases where the first stop bit is zero.

Ещё более подчёркнуто это написано в документации на упоминавшиеся микроконтроллеры STM32F103:

2 stop bits: Sampling for 2 stop bits is done on the 8th, 9th and 10th samples of the first stop bit. If a framing error is detected during the first stop bit the framing error flag will be set. The second stop bit is not checked for framing error.

NSER (No Stop Bit Error). This bit is set to logical 1 to indicate that the received data have no stop bit. In 16550 mode, it indicates the same condition for the data on the top of the FIFO. When the CPU reads USR, it sets this bit to logical 0.

А в документации на микросхему PC16550D написано:

If bit 2 is a logic 0, one Stop bit is generated in the transmitted data. If bit 2 is a logic 1 when a 5-bit word length is selected via bits 0 and 1, one and a half Stop bits are generated. If bit 2 is a logic 1 when either a 6-, 7-, or 8-bit word length is selected, two Stop bits are generated. The Receiver checks the first Stop bit only, regardless of the number of Stop bits selected.

Заключение

Источник

RS-232 connections can be difficult and frustrating
to troubleshoot as there can be many sources of errors. Below you
will find a list of the various components involved in a data
transmission, as well as possible problems.
Please check them systematically.

Consult the manual that came with your device and check its actual
settings to verify that:

The fact that you can physically connect a cable
between your PC and device means nothing in terms of internal wiring and does not guarantee that
the correct pins are connected.

If 232key does not work as expected, please press Stop in the Start/stop tab and
then switch to the Event log. If it seems that
232key has already stopped itself, please
see this issue.

The event log is a very useful
troubleshooting tool. In the example below, you can see that
232key has received a total of 10 lines of data from the connected
device. Two lines contained measuring values which were captured
and typed by 232key: «70.8» and «102.1». These captured
values are shown in blue. Non-printable ASCII
control characters are shown in pointy brackets with their decimal
codes («<13><10>» =
carriage return and line feed).

Depending on what you see in your event log, please click on the description that best
describes your
problem:

*Applies only to the Plus and MU version.

a. No data received
from your device is shown in the event log

If the event log only contains 232key’s status messages as
shown below, this means that no data has been received from your
device:

1. Did you choose the correct COM port?

If there are multiple COM ports available on your
system, please ensure that you’ve selected the correct
one. On some systems, if you plug a device into a
different USB port, the COM port may also change. If 232key is listening on the wrong COM port, it
cannot possibly receive any data. The names that 232key
shows in the Input tab are the same as
in the Windows Device Manager under
Ports (COM&LPT). Example:

In the screenshot
above, you can see two built-in COM ports
(COM1 and COM2) and one (virtual) COM port which was
created when an Ohaus scale with a USB interface was
connected to the PC. Note that it shows up as «USB
Serial Port» and
not «Ohaus».
The correct port to set in 232key in order to use the Ohaus scale would therefore
be COM3. The numbers of the COM ports on your
PC will be different.

2. Can you receive data using a different program?

Please try using a free terminal program like hTerm
or

Termite to receive data from your device (instead of
using 232key). If the terminal program doesn’t receive
any data either, then there is
something wrong with the settings of your device or with the
connection between your
device and your PC. Please read the common causes at
the very top of this page or contact your device
manufacturer or dealer for help.

If you do receive data with a terminal program but not
with 232key, please contact us
and send us screenshots of the received data in the terminal software and
of 232key’s
event log (you can also use our
support forum).

Due to the overwhelming amount of
support requests we’re receiving, we may not be able to respond
to you if you ignore the above instructions and expect us to fix
a problem for free that is not caused by our software. 232key is
not magical. If it does not receive data from your device, it
cannot work.

3. Does your device only support request-reply protocols?

Some devices cannot transfer data when a button
is pressed. Instead, the software running on the
computer has to request
the data by sending a command. The following
illustration shows the NCI protocol used by some scales
(mainly price computing scales, but also a few parcel
scales):

These kind of devices cannot currently be used with
232key. You could try
using
232key Pro instead, but please note that some
protocols are even more complicated and require multiple
requests and replies.

b. «Unsent data» message

If you find an «unsent data» message in the event log
(after having pressed Stop in the Start/stop
tab), this means that 232key has received data
from your device, but has not found the
terminator you
specified in the Input tab. This can have two
possible causes:

1. Wrong terminator

The terminator
is the very last character in each line of data sent from the device.
In the example below, the terminator should be «<10> LF», but was
specified as «<13> CR» (in this example, this didn’t
prevent 232key from extracting the measuring value):

Please specify the correct terminator in the
Input tab. You can enter any decimal ASCII code. See our documentation
for further information.

2. Wrong interface parameters (port settings)

If the «unsent data» message is followed by unexpected characters and numbers in
<angle brackets>, your

interface parameters are wrong. All of the
following settings in the Input tab
in 232key have to match the settings of your device:

bits/s, data
bits, stop
bits

and parity. Please refer to the manual
that came with your device to find the correct settings.

The numbers in angle brackets are unprintable characters shown as their decimal codes.

c. «Error [WW]: java.lang.NumberFormatException»

This error appears in the Plus version if:

The
Device you’ve selected in the
Input tab expects numeric values only (this
is the case for all devices except for «Barcode
alphanumeric» and «Barcode alphanumeric extended»).
You’ve modified the regular expression used by
232key to match
non-numeric characters.
You did not remove these characters by entering them in
the
Remove field in the
Process
tab.

What happened then is that 232key tried to convert
the captured non-numeric data into a number, which produced the error.

Solutions:

If you want 232key to type a number, you have to remove the matched non-numeric characters in the
Process tab (in the pictured example, you’d
enter «/» in the
Remove field).
If you want 232key to type all characters as captured, change the
Device in the
Input tab to «Barcode alphanumeric» or «Barcode alphanumeric extended».

d. «Cannot type: ..» error

This message means that 232key has captured a character which it cannot (currently) type. The «Barcode alphanumeric» device can type characters A-Z (case sensitive) and 0-9, while
the «Barcode alphanumeric extended» device can also type a-z and
several other characters (see
entry under «additional devices» here for a complete list).
If a character outside this range has been captured, this error
message is logged and the character is ignored.

We’re constantly working on adding further characters to the
«Barcode alphanumeric extended» device. Due to the low-level
nature of our keyboard simulation and the many keyboard layouts
in use around the world, this can be surprisingly complicated.

e. Framing or parity
errors

These errors appear if the data received by 232key
does not match the expected format at byte level. If you
see a long list of these errors, the

interface parameters configured in the Input
tab are most likely wrong. Please refer to the manual that came
with your device to find the correct settings.

If these errors only appear sporadically, this could mean
that your data has been corrupted.

f. Data received, but 232key
captures and types the wrong part

1. Wrong numeric value typed

If your device transmits multiple values in one line (e.g.
time/date and a measuring value), only the first one will be
captured and typed by 232key. This value might not be the one you’re
interested in. Here’s an example of a complicated data sequence
where 232key types the first number («0,16«) instead of the desired
measuring value («105»):

Solutions:

Try configuring your device to send only the value
you need.
Create a
custom
regular expression to capture only the data you want
(requires a
Plus license).
Contact us so that we can analyze the data and build a
special device profile. Please
send us the content of the
event log tab and the name of your device and manufacturer.
Here’s the event log for the example above after we included a «Tanita
TL-280/TL-290″ profile for our user, showing that the desired value (»
105«)
is now being captured:

2. Letters not captured

Currently, only the «barcode alphanumeric» and «barcode
alphanumeric extended» profiles supports letters. Please make sure
one of these devices is selected in
the Input tab.

g. Data received, but 232key
captures and types too many parts

If your device transmits several lines of data at once, 232key
will process all of them and possibly capture some values you’re not
interested in. The following example shows the output of an Ohaus
STX scale in its default configuration:

As you can see, 232key captures and types part of the date, the balance
ID, part of the model no. and finally the weight.

Solutions:

Configure your device to send only
one value. The scale used in our example can be set to
transmit the «numeric value only» (and then sends only
the weight, a setting which works
fine with the default «Ohaus» profile in 232key).
Create a
custom
regular expression to capture only the data you want
(requires a
Plus license).
Contact us so that we can analyze the data and build a
special device profile. Please
send us
the content of the event log tab and the name of your device
and manufacturer.

Data has been received from your device and is shown
in the Event log, but nothing is shown
in blue (i.e. no data has been captured and typed by
232key).

Please make sure that you’ve selected the right

Device profile in the
Input tab:
The «general» device profile is meant to be used with
measuring instruments and only supports numeric values.
The «barcode alphanumeric (A-Z and 0-9)» device profile
supports characters A-Z (case sensitive) and digits 0-9
while the «barcode alphanumeric extended*» profile supports
all printable ASCII characters.
If you only see a lot of values in pointy brackets,
please ensure that your

interface parameters are correct and that your device is sending data in ASCII
format (currently, 232key does not support
binary formats
like Modbus RTU).

i. Data received and captured, but 232key does not type anything

The event log looks fine, i.e. you can see that data was received
from the connected device and that 232key captured the desired
value (shown in blue), but nothing
is typed into your application.

Make sure that your target application has focus
and is ready to receive keyboard inputs while
232key is running in the background. If you start typing on
your keyboard, the characters should appear in your target
application.
Please try using another target application (like notepad) to see if
the problem persists. Some applications may capture keyboard input
and prevent 232key from working correctly.
Make sure that no error messages appear in the event log
(e.g. »
cannot type» errors).
Try changing the
Keyboard setting in
the
Output tab to match your keyboard
layout or try selecting «All (compatibility mode)».

If you’re using 232key Plus or 232key MU, please also check the following:

Verify that the
Start with key defined
in the
Input tab is not moving focus away
from where you want the data to be typed.
Ensure that no setting in
Process tab
is preventing 232key from typing the received data. With all settings are disabled, the tab should look like this:

j. Several lines of data per second

If you see several lines per second in the event log, your device is set to send data continuously:

Consult its
manual to switch to a mode where data is only sent when a key on the device
is pressed (or data is sent automatically, but only once).

Note: Some devices may only have a «continuous» mode
and unfortunately can’t be used with 232key at this time.

k. Just one line of data and a «stopped» message

If the Event Log only shows one line of data received from the connected device, followed by a
«stopped» message (even though you did not press the
Stop button), then 232key is configured to send «enter» and was
still in focus when the data was received:

This caused the software to immediately «press» the
Stop
button. Please switch to the target application before
sending data from the connected device. If you have not
triggered the data transmission manually, your device may be set
to send data automatically or
continuously.

Note: Some devices can send data so fast that you’ll see several lines ahead of the «stopped» message.

232key does not start

Please make sure you’re using an operating system supported by 232key.
If that’s the case, try disabling your virus scanner (should this
solve the problem, please let us
know which virus scanner you’re using).

232key starts, but then disappears

You have probably configured it to
minimize to the notification area.

No port found

232key needs a (virtual) serial port to communicate with your
device. Make sure the port shows up in the device manager on
your system. If you’re using a RS-232/USB converter, check that
it is plugged in correctly.

Port is in use

Your port is being used by another application. Check that
you’ve selected the right port in the Input
tab and that no other programs are using this port.

Port not valid

The port you selected in the Input tab is not valid. This
could happen if you disconnect a RS-232/USB converter while
232key is running.

Scale not connected to this port (A&D devices only)

232key shows this message if it can’t detect an A&D
device at the specified port. Please make sure that
you’ve chosen the right port in the Input tab and that the
cable is connected to your device and computer.

If you receive this error message, but your A&D device is
working properly as the program continues, please tell us
which A&D scale or balance you’re using. If you’re using a
cable or converter which does not support the RTS/CTS
and DTR/DSC signal lines, select «A&D (no handshaking)»
instead.

Scale connected, but switched off (A&D devices only)

232key has detected an A&D device at the
specified port, but this device does not respond as expected. It
could be switched off or you might be using the wrong type of
cable. A&D scales and balances usually require a straight cable
and will not work with a crossed (null modem) cable.

Note concerning A&D balances with power safe mode: Power safe
mode is currently not detected by 232key, this message will only
appear if your balance is unplugged.

If you receive this error message, but your A&D device is
working properly as the program continues, please tell us
which A&D scale or balance you’re using. If you’re
using a cable or converter which does not support the
RTS/CTS and DTR/DSC signal lines, select «A&D (no
handshaking)» instead.

Error while loading settings

All settings you make in 232key are saved and loaded automatically. If
one or more of these
saved settings are not valid, the error message above is displayed and the
program uses the default setting. This can also mean that a trial
license you used has expired.

Access error while loading settings

Access to the registry was denied. The program cannot load the settings your
settings.

Please ensure that access to the registry (232key) or
ProgramData folder (232key MU) is not blocked by a
virus scanner or similar application.

Access error while saving settings

Your settings are automatically saved when 232key is
closed. If access to the registry (232key) or ProgramData folder
(232key MU) is denied, you’ll see this
error message.

Please ensure that access to the registry is not blocked by a
virus scanner or similar application.

Invalid license key

All license keys purchased from our partner FastSpring
are generated automatically and are guaranteed to be
valid. There are three reasons why you might see this message:

You’re using an outdated version of 232key (this is the most likely reason
and
applies to more than 95% of all support requests
concerning this error). Please switch to the

About tab and confirm that your version number
starts with 2017:

Older versions don’t accept newer
license keys. Please update your software by downloading and
running the
installer
for 232key Plus or
232key MU
(depending on which license you’ve purchased).
You’ve not copied and pasted the complete license key or
your email client has problems displaying it correctly (this
can happen in rare cases when FastSpring’s original email
with the license key has been forwarded to you in HTML
format). Please copy the entire key from the email you’ve
received from FastSpring. If the error persist,
please contact us and
we’ll resend you your license key as a text file. However,
first make sure you’re not using an outdated version of
232key as mentioned above!
You’ve purchased
multiple licenses and copied more than one license
key at one. Please copy only one line (one license
key).

Источник

RS232 Unusual «Framing Error»

Неизвестный UART: теория

RS-232

Работа над ошибками

Мажорирование

Оверсемплинг

Ошибки логики

Заключение

RS-232

Работа над ошибками

Мажорирование

Оверсемплинг

Ошибки логики

Заключение

a. No data received from your device is shown in the event log

1. Did you choose the correct COM port?

2. Can you receive data using a different program?

3. Does your device only support request-reply protocols?

b. «Unsent data» message

1. Wrong terminator

2. Wrong interface parameters (port settings)

c. «Error [WW]: java.lang.NumberFormatException»

Solutions:

d. «Cannot type: ..» error

e. Framing or parity errors

f. Data received, but 232key captures and types the wrong part

1. Wrong numeric value typed

Solutions:

2. Letters not captured

g. Data received, but 232key captures and types too many parts

Solutions:

i. Data received and captured, but 232key does not type anything

j. Several lines of data per second

k. Just one line of data and a «stopped» message

232key does not start

232key starts, but then disappears

No port found

Port is in use

Port not valid

Scale not connected to this port (A&D devices only)

Scale connected, but switched off (A&D devices only)

Error while loading settings

Access error while loading settings

Access error while saving settings

Invalid license key

a. No data received
from your device is shown in the event log

e. Framing or parity
errors

f. Data received, but 232key
captures and types the wrong part

g. Data received, but 232key
captures and types too many parts