boris_r_v
-
Posts
106 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Posts posted by boris_r_v
-
-
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, соединив его порты?
-
Хм., так это и смущает, что какая-то беда с игнорированием 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. - игнорирует второй бит и принимает ответ корректно."
-
24 minutes ago, Знайка 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а в разных контроллерах может приводить к тому эффекту о котором идет речь, как бы все таки выяснить есть ли отличия в драйверах у разных контроллерах?
-
1 hour ago, Знайка said:
Интересное наблюдение. То есть с 1 стоповым битом короткий ответ всегда принимается верно? Независимо от того, есть в линии ещё устройства (тот же UPort 1130) или нет?
Да когда поставил 1 стоп бит все за отвечало, устройства друг другу не мешают работать, отвечают штатно все 3 (два коротким ответом, один длинным).
Но все еще интересней:
- Девайсы у которых короткий ответ не имеют в своей прошивке для PIC16F873A указания количества стоповых битов, там по-умолчанию один стоп бит, второй добавляли руками и для этого устройства это не сделано, т.е. стоп бит один. Поэтому логично, что UC-8112 не может корректно вычитать ответ, когда ожидает 2 стоп бита, т.к. неверная настройка ком-порта: на мастере 2 стоп бита, на slave 1 стоп бит. Тут чуда не случилось, все стало ясно.
-
Устройства с коротким ответом, конвертеру UPort1130, контроллерам W321, UC-2110 и PCI-платам Moxa CP-132, CP-114 отвечают хорошо при 2-х стоповых битах настройки мастера, хотя на устройстве 1 стоп бит. Почему при неверной настройке работает стоповых битов все работает? - драйвера устройств по-любому причастны
- Далее: девайс у которого длинный ответ, имеет настройку в прошивке на 2 стоповых бита и с ним прием штатный на UPort1130 и UC8112, не зависимо от того сколько стоп битов ожидает мой софт хоть 1 хоть 2, а в легаси-софте везде и всегда 2 стоповых. Почему UC8112 настроенный на 1 стоповый бит успешно принимает длинный ответ с двумя стоповыми битами?
- Итог: для ответа в 3 байта (короткий ответ) нужно чтобы на UC8112 было верно указано кол-во стоп битов, на остальных устройствах не важно, а для длинного ответа (порядка 130 байт) настройка кол-ва стоп битов не важна на всех устройствах.
Т.е. мое виденье, что ранее во всех устройствах моха были послабления на количество стоповых битов в принимаемых пакетах (как это сделать не знаю), а в UC8112 их убрали и прием коротких ответов на нем логично сломался (не совпали стоп биты). Тут налицо наличие технического долга в софте мастера, т.е. проблема на моей стороне, а не на стороне Moxa. Но почему длинный ответ хорошо принимается на UC8112 с 1 стоп-битом?
И коль уж так углубились в дебри, как-то можно выяснить в чем отличия в драйверах ком-портов в части работы со стоповыми битами между рядом устройств: UPort1130, W321, UC2110, CP132. CP114 и контроллером UC8112?
Просто если в UC8112 инженеры Моха подчистили свой технический долг и это исправление будет тиражироваться на остальные устройства, конкретно меня и моих коллег ждут тяжелые времена ...
Тут везде используются linux драйвера, коллега проверит на windows подскажет.
-
Наметился прогресс:
- на переходнике UPort-1130, контроллерах Moxa W321, UC-2110 - прием устойчиво работает когда выставлено 2 стоп бита ( как устройства и отправляют)
- на переходнике UPort-1130 прием также работает когда выстален один стоп бит, контроллеров w321 uc2110 нет под рукой - проверит не могу
- а вот на uc-8112 - прием заработал только при одном стоповом бите (и длинного и короткого ответов), когда ставлю два стоповых бита - происходит некорректный прием короткого ответа, и корректный прием длинного.
Опрашивал реальные устройства которые по документации (и по исходникам софта который с ними работает с прошлого века) настроены на отправку двух стоповых битов.
-
1 hour ago, Знайка said:
То есть получается, что неверно принимается только 3тий байт, первые 2 принимаются верно?
С конкретно этого устройства должно быть 0х00 0x02 0x96 приходит 0x00 0x20 0xF9 (в десятичной форме 0 32 249), т.е. верно принимается только стартовый бит.
С другого подобного устройства
не принимается ничего.принимается 0х0 0х96 - когда ожидали 0х0 0хFF 0х96, т.е. не приняли второй байт -
On 12/30/2020 at 12:07 PM, Знайка said:
И ещё :
#kversion -a
#uname -a
И SN с обеих UC-8112, с которыми проблема. Поведение ведь не зависит от используемого порта, верно?Первый: это тот на котором эксперименты проводятся:
s/n TAGHB1019002
moxa@Moxa:~$ kversion -a
UC-8112-LX version 3.4 Build 20101418
moxa@Moxa:~$ uname -a
Linux Moxa 4.4.0-cip-rt-am335x #1 Tue Aug 11 19:11:02 CST 2020 armv7l GNU/Linux
moxa@Moxa:~$Второй: который с объекта привезли в надежде успешного решения проблемы
S/N TBZDB1068246
moxa@Moxa:~$ kversion -a
UC-8112-ME-T-LX version 3.0 Build 18110917
moxa@Moxa:~$ uname -a
Linux Moxa 4.4.0-cip-uc8100-me #2 Fri Nov 9 17:50:14 CST 2018 armv7l GNU/Linux
-
On 12/29/2020 at 4:21 PM, Знайка said:
Я про 0 32 249 имел в виду - это в чём?
Это в dec
-
On 12/17/2020 at 7:50 PM, boris_r_v said:
Со 2-го пакет ответа 3 байта, должно быть 0 2 96 приходит 0 32 249
Согласен тут не совсем корректно: "0 2 96" должно быть написано 0х0 0х2 0х96 - тогда б не было путаницы
Ожидаемый ответ 0х00 адрес 0х96 (0х96 - это константа)
-
Да на двух последних осцилограммах полярность обратная по сравнению с первыми двумя.
Слова которыми обмениваемся:
1. те что не работают. Запрос 0x0 0x2 0x3f 0xff 0xff 0xff 0xff 0xff 0xff 0x5 0xfd Ответ: 0х0, 0x2, 0x96
2. тот что работает. Запрос: 0x0 0x20 0x3 0x0 0x0 0x0 0xb3 0x3 Ответ: 0x0 0x20 0x84 0x10 0xeb 0xac 0xbc 0x2b 0x60 0xad 0x3c 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x8d 0x0 0x0 0x0 0xcd 0x1 0x2 0xbd 0xe6 0xd5 0x2d 0x3d 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2b 0x60 0x2d 0x3c 0xe6 0xd5 0x2d 0x3c 0xe6 0xd5 0x2d 0x3c 0xe5 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x2b 0x60 0xad 0x3c 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x6a 0x0 0x0 0x0 0x2b 0x60 0x2d 0x3c 0xe6 0xd5 0x2d 0x3c 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x7 0x0 0x0 0x0 0x0 0x0 0x0 0x3 0xf4 0x69
Во всех запросах и ответах первый байт - стартовый, второй адрес устройства.
А не использование modbus - это легаси, родом из 90-х, когда интернет был редким и дорогим зверем.
-
А что тут скажешь, паузы формально описаны только в Modbus, в данном случае не модбас, поэтому формальных ограничений нет. Поэтому мы можешь оперировать только субьективными трактовками. Хотя ограничения на паузы в стандарте модбас тоже появились не просто так ...
На стороне опрашиваемых железок, кода который бы считал эту паузу и строго по прерыванию от таймера выдерживал нету. Добавить можно, но что делать с уже поставленными образцами, т.е. есть тяжелый легаси, правка которого экономически нецелесообразна, т.к. есть UC21xx который не имеет такой проблемы, его минус - это форм фактор. Это я к и тому, что есть альтернатива опять же от компании Moxa
Поэтому если все так и останется в принципе ничего страшного, UC8112-lx мы купили всего два, и заменить их на UC21xx не стоит огромных денег, а эти отправятся на склад на хранение в ожидании подходящего проекта.
Далее ряд замеченных странностей, которые оставляют надежду на решение проблемы:
- Хорошо бы понять это на время переключения, или что-то иное т.к. на тестовм столе было два однотипных устройства, и картинки которые были ранее - это с того с которого данные не приходят, но был еще один с которого приходили, но не корректные, причем если паралельно читать пакеты из другого tty через python - то там данные приходят верные. Походит на проблему в моем софте, НО есть еще одна странность.
- Есть еще одно устройство другого типа (назовем его УНС), у которого ответ порядка 140байт, а не 3 как у ранее рассмотренных и оно опрашивается без проблем.
- При этом интервал между окончанием запроса и началом ответа на УНС: 80мкс - первая картинка, приложенная к данному посту, вторая - тот же запрос и ответ с большей ценой деления по оси времени.
Подводя итог под вышесказанным, и принимая новую информацию - грешить только на аппаратную часть не получается. потому как если ответ длинный - то все работает с очень малым интервалом, на том же софте и харде.
Поэтому прошу донести эту информацию до разработчика может еще раз заглянут в код tty-драйвера.
Сейчас можно сказать, что комбинация: короткий ответ и малый интервал - не работает, а длинный ответ и малый интервал - работает.
-
Получилось локализовать проблему.
Для этого из боевого софта был выкушен кусок кода которые отвечает за работу с ком-портами и на его основе сделан имитатор подчиненного устройства (slave). Был поставлен экперимен: на одном ком-порту UC8112-lx был запущен софт который опрашивает устройство, на втором ком-порту UC8112 был запущен имитатор. Комп порты в режиме RS-485-2W, обвязаны 2-х проводной линией к которой подключено опрашиваемое устройство. Когда работа имитатор физическое устройство выключалось, когда работало устройство - выключался имитатора, во избежание коллизий.
Пакет запроса - 11 байт, ответа - 3 байта, скорость 19200.
Результат эксперимента: ответы имитатора принимаются, ответы устройства нет.
Почему видно из приведенных ниже осcцилограмм:
- имитатор начинает отвечать через 4мс, после окончания ответа (файл: имитатор_2.jpg);
- устройство начинает отвечать через 0.5мс, после окончания ответа (файл: устройство_2.jpg)
Заставить быстрей отвечать имитатор не получилось - видимо ограничение аппаратной части.
Теперь к странному:
Если опрашивать два одинаковых устройства, но сидящие на разных адресах, то от одного принимается ошибочно 2-й байт из 3-х, от другого вычитываются 2 байта из трех. Причем ПО ждет удвоенное время необходимое для передачи кол-во байт ответа на заданной скорости, и этого не хватает, чтобы дочитать 1 байт, а может времени ожидания хватает на передачу 6 байт в рассматриваемом случае.
К сожалению во время экспериментов я спалил UPort1130, поэтому осциллограмму работы через него предоставлю позже.
Да возможно интервал в 0.5мс на начало передачи ответа и мал, но еще раз повторюсь: на контроллерах W321, W325, UC21xx таких проблем не было.
Если немного пованговать: - то похоже на то, что переключение на прием происходит медленно (тогда все скорее всего плохо) или при переключении сбрасывается буфер уже принятых байт.
Если эту проблему удастся порешать было бы отлично - уж больно формфактор UX81xx хорош по сравнению с UC21xx
Благодарен за любой ответ.
P.S. Ссылка на имитатор: https://github.com/boris-r-v/uc8112.git (исполняемый tty_slave или tty_slave_one)
-
Ну из меня такой себе схемотехник, как сделать внешнюю подтяжку нужно еще уметь .
Проблема в аппаратной части контроллера, потому как сейчас идут пусконаладочные работы по одному объекту где применяется UC-8112-ME-LX с версией 3.0.
И там та же проблема, не работают опрос модулей автоматики, завезли туда с другого объекта UC-21xx, тот же deb пакет и на UC-21xx опрос модулей автоматики работает.
-
Пробовал.
Схема была такая: один порт UC-8112 шлет запросы, второй порт слушает:
cat /dev/ttyUSB0 | xxdИ UPort1130 тоже пытается слушать - но у него загорается одновременно Tx и Rx и линия садится, кто-то делает подтяжку ее к логической 1-це видимо.
Надо по традиции собрать тестовое ПО которым можно поделиться и на котором воспроизводиться эта проблема.
Или если есть какое-нибудь консольное тестовое ПО - поделитесь.
.
-
Доброго времени суток, сегодня наткнулся на странную проблему работы со встроенными tty на UC-8112-lx (ttyM1, ttyM0)
Если вкратце: есть три устройства:
- С 1-го пакет ответа 138 байт, они принимается хорошо
- Со 2-го пакет ответа 3 байта, должно быть 0 2 96 приходит 0 32 249
- С третьего ответ тоже 3 байта вообще не приходит
kversion: UC-8112-LX version 3.4 Build 20101418
порты в нужном режиме:
- setinterface ttyM0 -> Current uart mode is RS485-2W interface.
- setinterface ttyM1 -> Current uart mode is RS485-2W interface.
Проверил другие прошивки с ресурса: https://moxa.ru/shop/comp/risc/uc8100/uc-8112-lx/ на версиях 2.1, 3.2 ошибка та же
НО если подключить к USB порту UPort-1130 и через него опрашивать - все работает корректно.
В /etc есть moxa-config, там moxa-uart-control.json -> /etc/moxa-configs/UC-81X2-LX_old/configs/moxa-uart-control.json.
Если ставить симилинк на moxa-uart-control.json -> /etc/moxa-configs/UC-81X2-LX/configs/moxa-uart-control.json USRT неверное конфигшурируется и не работает вообще
Подскажите куда дальше смотреть и чего еще попробовать.
P.S. до этого работал с UC-2100 - с ним таких проблем не было.
-
Уфф здрасте - давно не заходил.
За драйвер благодарю :)
-
Хороший вопрос, повелитель - давно не имел проблем с драйверами прям года так с 2015-2016. А в то время я драйвера с форума брал на сайте moxa были старые драйвера.
Поэтому ответ - привычка. - Но теперь буду знать
-
Отсутствие информации легко объяснить тем, что подавляющее большинство скад написаны под винду и там другой драйвер.
-
Решение 4-й проблемы, (так себе вариант):
Запретить загрузку ti_usb_3410_5052
Делается довольно просто - указанный модуль помещается в черный список
Я сделал так в каталог /etc/modprobe.d добавил файл blacklist-moxa.conf
Со следущим содержанием:
Quoteinspiron modprobe.d #
cat blacklist-moxa.conf
# This file lists those modules which we don't want to be loaded by
# alias expansion, usually so some other driver will be loaded for the
# device instead.#The module ti_usb_3410_5052 interferes with the operation of the original Moxa Uport driver, mxu11x0 and is therefore blacklisted.
#But this is not the best option, so if you know another option how to remove the alias for specific devices, tell us.
blacklist ti_usb_3410_5052
По другому строку
Quoteblacklist ti_usb_3410_5052
Можно добавить в любой другой файл начинающийся с blacklist....
Выдернуть переходник и выгрузить модули:
Quotermmod mxu11x0 ti_usb_3410_5052 usbserial
Вставить обратно упорт и убедится в отсутствии лишнего модуля
Quoteinspiron modprobe.d # lsmod | more
Module Size Used by
mxu11x0 106496 0
usbserial 53248 1 mxu11x0
rfcomm 81920 4
vboxnetadp 28672 0
Все.
Но нет теперь модуль ti_usb_3410_5052 никогда не будет загружен даже если будет нужен, что не совсем хорошо.
Чтобы этого избежать нужно удалить алиасы из modprobe.alias который храниться в /lib/modules/5.4.0-33-generic
Quotealias usb:v110Ap1151d*dc*dsc*dp*ic*isc*ip*in* ti_usb_3410_5052
alias usb:v110Ap1150d*dc*dsc*dp*ic*isc*ip*in* ti_usb_3410_5052
alias usb:v110Ap1131d*dc*dsc*dp*ic*isc*ip*in* ti_usb_3410_5052
alias usb:v110Ap1130d*dc*dsc*dp*ic*isc*ip*in* ti_usb_3410_5052
alias usb:v110Ap1110d*dc*dsc*dp*ic*isc*ip*in* ti_usb_3410_5052
Но просто удаление не поможет - тут нужно драйвер (ядерный модуль) отвязать от устройства, а это я не знаю как. Возможно пока не знаю
-
4-я ошибка уже не связанная с драйвером от мохи, а возникшая из-за левого левого драйвера загруженного самой убунтой при подключении UPort: Зовут героя так: ti_usb_3410_5052
Как ранее писали где-то в ветках про эти UPortы - необходимо выгрузить ядерный модуль
rmmod ti_usb_3410_5052
Но грабли в том, что при повторном подключении переходника грузятся сразу два драйвера
Quoteinspiron mxu11x0 # lsmod
Module Size Used by
mxu11x0 106496 0
ti_usb_3410_5052 36864 0
usbserial 53248 2 ti_usb_3410_5052,mxu11x0
rfcomm 81920 4
vboxnetadp 28672 0
vboxnetflt 28672 0
-
3-я ошибка сборки (уже позабористей): ошибка в Makefile
Quoteinspiron driver # make
************************************************************************
Ubuntu 20.04 LTS
\l 5.4.0-33-generic
MOXA UPort 11x0 series driver ver 1.3.21
Release Date: 2017/11/27
************************************************************************
**********************************WARNING*******************************
MOXA UPort 11x0 series driver may not be compatible with
Linux kernel versions newer than 4.13.0 .
To download the latest driver, please visit Moxa at: http://www.moxa.com
If you have questions, please contact Moxa support at: support@moxa.com
************************************************************************
*******************************************************************
# MOXA UPort 11x0 series USB to Serial Hub Driver v1.3.21 #
# for Linux Kernel 2.6.x & above #
# #
# release date : 11/27/2017 #
# dir : /home/boris/Distr/Moxa/mxu11x0/driver #
*******************************************************************
make -C /lib/modules/5.4.0-33-generic/build SUBDIRS=/home/boris/Distr/Moxa/mxu11x0/driver modules
make[1]: вход в каталог «/usr/src/linux-headers-5.4.0-33-generic»
make[2]: *** Нет правила для сборки цели «arch/x86/tools/relocs_32.c», требуемой для «arch/x86/tools/relocs_32.o». Останов.
make[1]: *** [arch/x86/Makefile:232: archscripts] Ошибка 2
make[1]: выход из каталога «/usr/src/linux-headers-5.4.0-33-generic»
make: *** [Makefile:48: module] Ошибка 2
Нет четкой подсказаньки как раньше как быть, но гугл нам дает решение: https://askubuntu.com/questions/232840/my-makefile-results-in-no-rule-to-make-target-arch-x86-tools-relocs-c-needed
Cook reciрe:
Заходим в ./mxu11x0/driver и правим Makefile (48 строку или около того):
Нужно: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
Заменить на: $(MAKE) -C $(KDIR) M=$(PWD) modules
Profit - драйвер собрался загрузился
-
2-я ошибка сборки: bison: not found
Quoteinspiron driver # make
************************************************************************
Ubuntu 20.04 LTS
\l 5.4.0-33-generic
MOXA UPort 11x0 series driver ver 1.3.11
Release Date: 2013/10/22
************************************************************************
**********************************WARNING*******************************
MOXA UPort 11x0 series driver may not be compatible with
Linux kernel versions newer than 3.13.0 .
To download the latest driver, please visit Moxa at: http://www.moxa.com
If you have questions, please contact Moxa support at: support@moxa.com
************************************************************************
*******************************************************************
# MOXA UPort 1110/1130/1150/1150I USB to Serial Hub Driver v1.3.11 #
# for Linux Kernel 2.6.x & above #
# #
# release date : 12/16/2014 #
*******************************************************************
make -C /lib/modules/5.4.0-33-generic/build SUBDIRS=/home/boris/Distr/Moxa/mxu11x0/driver modules
make[1]: вход в каталог «/usr/src/linux-headers-5.4.0-33-generic»
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
/bin/sh: 1: bison: not found
make[3]: *** [scripts/Makefile.host:17: scripts/kconfig/parser.tab.h] Ошибка 127
make[3]: *** [scripts/kconfig/parser.tab.h] Удаляется файл «scripts/kconfig/parser.tab.c»
make[2]: *** [Makefile:594: syncconfig] Ошибка 2
make[1]: *** [Makefile:704: include/config/auto.conf.cmd] Ошибка 2
make[1]: выход из каталога «/usr/src/linux-headers-5.4.0-33-generic»
make: *** [Makefile:35: module] Ошибка 2
Решение: apt install bison
-
Здрасте коллеги.
Я думаю админы перенесут этоту ветку куда надо я не придумал где ей будет лучше - Это манул по решению проблемы из названия топика
Итaк есть Ubuntu 20.04
Quoteinspiron Moxa # uname -a
Linux inspiron 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
И драйвер driv_linux_uport1p_v1.3.21_build_17112717.tgz скачаный с этого форума
Проблема: не собирасется.
Трабшутинг:
1-я ошибка сборки: flex: not found
Quoteinspiron mxu11x0 # ./mxinstall
************************************************************************
Ubuntu 20.04 LTS
\l 5.4.0-33-generic
MOXA UPort 11x0 series driver ver 1.3.11
Release Date: 2013/10/22
************************************************************************
**********************************WARNING*******************************
MOXA UPort 11x0 series driver may not be compatible with
Linux kernel versions newer than 3.13.0 .
To download the latest driver, please visit Moxa at: http://www.moxa.com
If you have questions, please contact Moxa support at: support@moxa.com
************************************************************************
*******************************************************************
# MOXA UPort 1110/1130/1150/1150I USB to Serial Hub Driver v1.3.11 #
# for Linux Kernel 2.6.x & above #
# #
# release date : 12/16/2014 #
*******************************************************************
/bin/sh: 1: flex: not found
make[4]: *** [scripts/Makefile.host:9: scripts/kconfig/lexer.lex.c] Ошибка 127
make[3]: *** [Makefile:594: syncconfig] Ошибка 2
make[2]: *** [Makefile:704: include/config/auto.conf.cmd] Ошибка 2
make[2]: *** [include/config/auto.conf.cmd] Удаляется файл «include/config/tristate.conf»
make[1]: *** [Makefile:35: module] Ошибка 2
make: *** [Makefile:9: install] Ошибка 2
Решение: apt install flex
-
Здрасте коллеги, оговорюсь сразу - ниже это мой опыт, статистика компании Moxa может отличаться. Мотивация к написанию поста - смотрю люди тоже мучаются с зависанием npreal & nport 5xxx - для меня это пройденный этап - решение найдено, глюк мохи побежден.
Итого, имею три объекта, запускались в разные года 2016, 2017, 2019 на двух (года пуска: 2016, 2017) стоят по одной штуке MOXA NPort 6650-32 48V, а на третьем (2019) стоят 4 штуки MOXA NPort 5450I, чтобы набрать те же 32 порта. Если интересно, используются в системах мониторинга (СТД-МПК) для съема телеметрии на станциях Салым Св.ж.д., Островной Св.жд. и Кинель Кб.ж.д. соответственно.
Возникшая проблема. - Там где стоят NPort-6000 серии все работает четко и нет проблем - порты не подвисают. А на 5000 серии зависают с рандомным интервалом от 5 минут до часа. Драйвер npreal один и тот же на всех трех объектах, и софт и хард для коммуникации с которым используются NPort так же одинаков. Питание всех четко по номиналу: 48V так 52V, 24V так 28V :). Т.е условия работы идентичны,
Перепрошивка одного NPort 5450 на последнюю на август 2019 года прошивку - эффекта не принесла.
Симпомы болезни: прекращается опрос датчиков телеметрии, исследования показали, что провалившись в системный вызов tcdrain (tcdrain(): waits until all output written to the object referred to by fd has been transmitted) из него уже не возвращаемся никогда. Если учесть, что нужно подтверждение передачи всего буфера - проблема явно в драйвере, но это противоречит устойчиво работающим NPortам 6ххх серии. Вобщем, есть гемор, надо решать его, а не исследовать проблему в коммуникации ядерного модуля и удаленного девайса по tcp (вангую: проблема в tcp - udp на мой взгляд в режимах потоковой передачи данных лучше работает - т.к. потеря одного пакета не критична по сравнению с таймингами tcp).
Решение оказалось простое в моей архитектуре: на работу с каждым последовательным портом выделена отдельная нить (pthread), поэтому ее останов не влияет на работу системы в целом она прогрессирует хоть и менее эффективно. Поэтому решение очевидно: отловить момент останова нити опроса модулей и закрыть и открыть порт.
Видимо вызову close плевать на подвисший tcdrain, а ядерный npreal в этом случае закрывает tcp соединение. А потом по новой open и пока снова не повисним.
В общем уже скоро будет год как этот костыль работает, и никто больше не помнит об этой проблеме. Акромя логов куда валяться варнинги о перезапуске опроса модулей телеметрии.
Если это вам поможет - значит не зря писал - всем удачи.
UC-8112-LX ttyM0, ttyM1 принимают некорректные данные
in Встраиваемые коммуникационные компьютеры
Posted
Считаю в тему закрытой - проблема некорректного приемы была в неверном количестве стоповых битов в ответе slave-устройства, собственной разработки: ожидалось два, а по факту был один.
Результат исследования проблемы:
Благодарности: