Jump to content
Форум по продукции MOXA

UC-8112-LX ttyM0, ttyM1 принимают некорректные данные


Recommended Posts

6 minutes ago, boris_r_v said:

Возможно, я с вами бы и согласился если не одно, но: оба контроллера UC21xx & UC81xx построены на одном и том же процессоре Armv7 Cortex-A8, (на UC8112 распаян am3352bzcza100) который имеет 6 штук UART на микросхемах TL16C550 согласно документации:

  1. https://www.ti.com/lit/ds/symlink/am3357.pdf?HQS=TI-null-null-alldatasheets-df-pf-SEP-wwe&ts=1610364078338&ref_url=https%3A%2F%2Fpdf1.alldatasheet.com%2F
  2. https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf?ts=1610351324922

Т.е. железо в обоих контроллерах с большой долей вероятности одинаковое, стоп биты как раз UARTы отмеряют, сл-но остается разница настройках микросхем UART в tty-драйверах контроллеров.

Согласно Table 4-235 по второй ссылке TL16C550 синхронизируют только первый стоп бит, независимо от кол-во указанных, но если бит STB в line control register установить в 1 то можно задавать различные варианты 1, 1.5, 2 стоп бита в зависимости от количества бит на символ. Это я к тому, что разная настройка UARTа в разных контроллерах может приводить к тому эффекту о котором идет речь, как бы все таки выяснить есть ли отличия в драйверах у разных контроллерах?

 

 

 

Я не смогу задать вопрос "есть ли отличия", на него просто не будут отвечать. Даже внутри серии UC-8100 есть существенные отличия по архитектуре между ревизиями, и я так думаю что с UC-21xx ситуация может быть такой же. Смотрю в указанную таблицу и не понимаю, что вас смущает - явно же написано, что читается всегда только 1 стоп бит, ну и понятно, что что на передачу можно задать произвольную комбинацию?

Link to comment

Хм., так это и смущает, что какая-то беда с игнорированием 2-го стоп бита. Т.е. если я ставлю 1 стоп бит на передачу и прием - то все хорошо. Если я ставлю 2 стоп-бита на прием и передачу то UART в slave-device игнорирует второй стоп-бит, принимает запрос, выполняет его и отвечает с 1-м стоп битом,  а UC-8112 не может корректно принять ответ - игнорировать нечего, а так ждал и поэтому расстроился, и не принял ответ.

Можно вопрос задать так: "Почему UC81xx при задании 2-х стоп битов некорректно принимает ответ от slave-device, у которого в ответе 1 стоп бит, хотя согласно Table 4-235 (https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf?ts=1610351324922) должен игнорировать второй стоп бит от устройства? При этом в UC-21xx в той же ситуации работает согласно Table 4-235. - игнорирует второй бит и принимает ответ корректно."

 

 

Link to comment

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

Link to comment
16 minutes ago, Знайка said:

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

Хм, так нет на стороне мастера второго единичного стопового бита, после первого наступает пауза (логическая 1-ца), потом старт бит нового байта - 0 и принимаем следующий байт. не вижу пока как можно по вашему описанию из 0х02 получить 0х20 и из 0х96 получить 0хF9,  не похоже на сдвинутые байты, да и кодовое растсояние более 1 ... Надо еще раз обдумать и пописать биты.

Но

  1. https://github.com/boris-r-v/uc8112.git - тестовый софт в котором повторяется эта проблема при использовании 2-х портов UC-8112
  2. Не понятно в чем причина, что UPort трафик с п.1 корректно принимает через tty_sniffer.py
  3. Если есть возможность протестировать его на UC21xx было бы отлично, - помнится как то мне удаленку давали на контроллер для тестов - сейчас можно повторить это с UC2112, соединив его порты?
Link to comment
13 minutes ago, boris_r_v said:

Хм, так нет на стороне мастера второго единичного стопового бита, после первого наступает пауза (логическая 1-ца), потом старт бит нового байта - 0 и принимаем следующий байт. не вижу пока как можно по вашему описанию из 0х02 получить 0х20 и из 0х96 получить 0хF9,  не похоже на сдвинутые байты, да и кодовое растсояние более 1 ... Надо еще раз обдумать и пописать биты.

Но

  1. https://github.com/boris-r-v/uc8112.git - тестовый софт в котором повторяется эта проблема при использовании 2-х портов UC-8112
  2. Не понятно в чем причина, что UPort трафик с п.1 корректно принимает через tty_sniffer.py
  3. Если есть возможность протестировать его на UC21xx было бы отлично, - помнится как то мне удаленку давали на контроллер для тестов - сейчас можно повторить это с UC2112, соединив его порты?

Если у нас 2 стоп бита - принимаем из линии 11 значений. Не проверяя значение 11того. Потом ждём 0 и начинаем приём следующих 11.

1. Не смотрел.Не на чём. И из текста понял, что имитатор как раз таки работает. То работает, то не работает. То с паузами, то без. Теперь выясняется, что вообще параметры связи разные на сторонах линии. Завтра что откроется? :ph34r:
2. Там совершенно точно другая ПЛИС.
3. UC-2112 сейчас в наличии нет, но в любом случае за удалёнкой на support@moxa.ru

PS. Попрошу: пишите, плз, конкретные вопросы. Ну что бы были внятные ответы :rolleyes:

Link to comment

Считаю в тему закрытой  - проблема некорректного приемы была в неверном количестве стоповых битов в ответе slave-устройства, собственной разработки: ожидалось два, а по факту был один.

Результат исследования проблемы:

  • В контроллере UC-8112-lx, по сравнению с его аппаратным близнецом UC-2112, по разному прописана работа с УАРТами;
  • Это привело к тому, что при неверной настройке количества стоповых битов (master ждет 2, slave шлет 1), обмен на UC-8112 не работает, а на UC-2112 работает;
  • Также экспериментально установлено, что информационный обмен при неверной настройке стоповых бит работает на следующем оборудовании Моха CP-131, CP-114, UPort-1130, UPort-1400,  W321, W325, UC-7112+, 
  • Все перечисленное оборудование успешно работает с неверными настройками, а применение UC-8112 позволило выявить проблему в прошивке slave-устройств.

Благодарности:

  1. Компании Moxa, что делает такое "лояльное" оборудование, хотя конвертер ICP COM i-7561 тоже не заморачивается со стоп битами;
  2. Знайке - за участие в решении проблемы.
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...