Знайка Posted January 11, 2021 Share Posted January 11, 2021 6 minutes ago, boris_r_v said: Возможно, я с вами бы и согласился если не одно, но: оба контроллера UC21xx & UC81xx построены на одном и том же процессоре Armv7 Cortex-A8, (на UC8112 распаян am3352bzcza100) который имеет 6 штук UART на микросхемах TL16C550 согласно документации: 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 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
boris_r_v Posted January 11, 2021 Author Share Posted January 11, 2021 Хм., так это и смущает, что какая-то беда с игнорированием 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
Знайка Posted January 11, 2021 Share Posted January 11, 2021 "игнорировать нечего" - это не так, в таком случае за второй стоп принимается старт следующего, дальше ждём 0 в линии, принимаем его за старт, ну и т.д. В этом случае первый байт посылки будет приниматься верно, а все остальные, соответственно, нет. Link to comment
boris_r_v Posted January 11, 2021 Author Share Posted January 11, 2021 16 minutes ago, Знайка said: "игнорировать нечего" - это не так, в таком случае за второй стоп принимается старт следующего, дальше ждём 0 в линии, принимаем его за старт, ну и т.д. В этом случае первый байт посылки будет приниматься верно, а все остальные, соответственно, нет. Хм, так нет на стороне мастера второго единичного стопового бита, после первого наступает пауза (логическая 1-ца), потом старт бит нового байта - 0 и принимаем следующий байт. не вижу пока как можно по вашему описанию из 0х02 получить 0х20 и из 0х96 получить 0хF9, не похоже на сдвинутые байты, да и кодовое растсояние более 1 ... Надо еще раз обдумать и пописать биты. Но https://github.com/boris-r-v/uc8112.git - тестовый софт в котором повторяется эта проблема при использовании 2-х портов UC-8112 Не понятно в чем причина, что UPort трафик с п.1 корректно принимает через tty_sniffer.py Если есть возможность протестировать его на UC21xx было бы отлично, - помнится как то мне удаленку давали на контроллер для тестов - сейчас можно повторить это с UC2112, соединив его порты? Link to comment
Знайка Posted January 11, 2021 Share Posted January 11, 2021 13 minutes ago, boris_r_v said: Хм, так нет на стороне мастера второго единичного стопового бита, после первого наступает пауза (логическая 1-ца), потом старт бит нового байта - 0 и принимаем следующий байт. не вижу пока как можно по вашему описанию из 0х02 получить 0х20 и из 0х96 получить 0хF9, не похоже на сдвинутые байты, да и кодовое растсояние более 1 ... Надо еще раз обдумать и пописать биты. Но https://github.com/boris-r-v/uc8112.git - тестовый софт в котором повторяется эта проблема при использовании 2-х портов UC-8112 Не понятно в чем причина, что UPort трафик с п.1 корректно принимает через tty_sniffer.py Если есть возможность протестировать его на UC21xx было бы отлично, - помнится как то мне удаленку давали на контроллер для тестов - сейчас можно повторить это с UC2112, соединив его порты? Если у нас 2 стоп бита - принимаем из линии 11 значений. Не проверяя значение 11того. Потом ждём 0 и начинаем приём следующих 11. 1. Не смотрел.Не на чём. И из текста понял, что имитатор как раз таки работает. То работает, то не работает. То с паузами, то без. Теперь выясняется, что вообще параметры связи разные на сторонах линии. Завтра что откроется? 2. Там совершенно точно другая ПЛИС. 3. UC-2112 сейчас в наличии нет, но в любом случае за удалёнкой на support@moxa.ru PS. Попрошу: пишите, плз, конкретные вопросы. Ну что бы были внятные ответы Link to comment
boris_r_v Posted January 12, 2021 Author Share Posted January 12, 2021 Считаю в тему закрытой - проблема некорректного приемы была в неверном количестве стоповых битов в ответе 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-устройств. Благодарности: Компании Moxa, что делает такое "лояльное" оборудование, хотя конвертер ICP COM i-7561 тоже не заморачивается со стоп битами; Знайке - за участие в решении проблемы. Link to comment
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now