Aleksey710 Posted April 13, 2018 Share Posted April 13, 2018 Драйвера последние с сайта (driv_linux_smart_v1_16_13_build_17070314.tar). При попытке сборки (mxinstall) выводит: /usr/bin/ld: ../mxlib/mxlib_64.a(f_alloc.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: ../mxwinlib/wlib_64.a(win-0.o): relocation R_X86_64_32S against undefined symbol `Blank' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: ../mxwinlib/wlib_64.a(win-1.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: ../mxwinlib/wlib_64.a(win-3.o): relocation R_X86_64_32S against `.bss' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: ../mxwinlib/wlib_64.a(win-4b.o): relocation R_X86_64_32S against `.bss' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: ../mxwinlib/wlib_64.a(win-2.o): relocation R_X86_64_32S against `.bss' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: ../mxwinlib/wlib_64.a(win-1b.o): relocation R_X86_64_32 against undefined symbol `Blank' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: ../mxlib/mxlib_64.a(confirm.o): relocation R_X86_64_PC32 against symbol `strlen@@GLIBC_2.2.5' can not be used when making a shared object; перекомпилируйте с параметром -fPIC /usr/bin/ld: final link failed: Некорректное значение collect2: error: ld returned 1 exit status Makefile:20: ошибка выполнения рецепта для цели «msmon» make[2]: *** [msmon] Ошибка 1 Makefile:30: ошибка выполнения рецепта для цели «mon_install» make[1]: *** [mon_install] Ошибка 2 Makefile:56: ошибка выполнения рецепта для цели «utility_install» make: *** [utility_install] Ошибка 2 По lspci 01:00.0 Serial controller: Moxa Technologies Co Ltd Device 1381 Если пробовать собрать только драйвера root@arm:/opt/moxa/mxser/driver/kernel4.x# make ********************************************************************** Debian GNU/Linux 9 \l 4.9.0-3-amd64 MOXA Smartio/Industio Family Multiport Board Device Driver ver 1.16.13 Release Date: 2017/07/03 ********************************************************************** ********************************WARNING********************************** MOXA Smartio/Industio Family driver may not be compatible with Linux Kernel versions newer than 3.11.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 ************************************************************************* root@arm:/opt/moxa/mxser/driver/kernel4.x# make install ********************************************************************** Debian GNU/Linux 9 \l 4.9.0-3-amd64 MOXA Smartio/Industio Family Multiport Board Device Driver ver 1.16.13 Release Date: 2017/07/03 ********************************************************************** ********************************WARNING********************************** MOXA Smartio/Industio Family driver may not be compatible with Linux Kernel versions newer than 3.11.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 Smartio/Industio Family Multiport Board Driver ver 1.16.13 installed successfully. ********************************************************************** Т.е. делает вид, что собирается и устанавливается. НО!!! root@arm:/opt/moxa/mxser/utility/diag# ./msdiag == MOXA Smartio/Industio Family Multiport Board Status Utility(1.4) == - PCI - No PCI device found. - PCIe - No PCIe device found. Подскажите куда копать и что делать? Link to comment
Незнайка Posted April 13, 2018 Share Posted April 13, 2018 Попробуйте 1.16.17 https://yadi.sk/d/JGHw1QBJ3Te4oc Link to comment
Aleksey710 Posted April 13, 2018 Author Share Posted April 13, 2018 root@arm:/opt/moxa/moxa# ./mxinstall Found mxupcie in system... Unloading mxupcie... Unload mxupcie successfully. Build driver for Linux kernel 4.x ********************************************************************** Debian GNU/Linux 9 \l 4.9.0-3-amd64 MOXA Smartio/Industio Family Multiport Board Device Driver ver 1.16.17 Release Date: 2018/01/23 ********************************************************************** ********************************************************************** MOXA Smartio/Industio Family Multiport Board Driver ver 1.16.17 installed successfully. ********************************************************************** Loading driver... ********************************************************************** MOXA Smartio/Industio Family driver ver 1.16.17 loaded successfully. ********************************************************************** root@arm:/opt/moxa/moxa# root@arm:/opt/moxa/moxa/utility/diag# ./msdiag == MOXA Smartio/Industio Family Multiport Board Status Utility(1.4) == - PCI - No PCI device found. - PCIe - PCIe tty device major number= 31. PCIe callout device major number= 34. Board 1 : CP-138E-A series (BusNo=1, DevNo=0) Port 1: 0xffffc2b0818ff000, max. baud rate = 921600 bps. Port 2: 0xffffc2b0818ff200, max. baud rate = 921600 bps. Port 3: 0xffffc2b0818ff400, max. baud rate = 921600 bps. Port 4: 0xffffc2b0818ff600, max. baud rate = 921600 bps. Port 5: 0xffffc2b0818ff800, max. baud rate = 921600 bps. Port 6: 0xffffc2b0818ffa00, max. baud rate = 921600 bps. Port 7: 0xffffc2b0818ffc00, max. baud rate = 921600 bps. Port 8: 0xffffc2b0818ffe00, max. baud rate = 921600 bps. Board 2 : CP-112UL series Port 1: (nil), max. baud rate = 921600 bps. Port 2: (nil), max. baud rate = 921600 bps. Board 3 : CP-112UL series Port 1: (nil), max. baud rate = 921600 bps. Port 2: (nil), max. baud rate = 921600 bps. Board 4 : CP-112UL series Port 1: (nil), max. baud rate = 921600 bps. Port 2: (nil), max. baud rate = 921600 bps. БОЛЬШОЕ СПАСИБО!!! Link to comment
Aleksey710 Posted April 16, 2018 Author Share Posted April 16, 2018 Рано радовался . С данными драйверами мокса не правильно устонавливает скорость. Терминал на одном компьютере через моксу шлет "0" со скоростью 115200. Терминал на другом компьютере с другим , ранее проверенным, преобразователем принимает "0" на скорости 122843. Коэфициент 1.066 Проверили на 9600 и 115200 - коэфициент работает. PS: Коллега сообщил, что подобный эффект был в ранних версиях драйверов. Link to comment
Aleksey710 Posted April 16, 2018 Author Share Posted April 16, 2018 Диаграмма Передачи через моксовский порт и через порт другого устройства(рабочий проверенный). Link to comment
Незнайка Posted April 16, 2018 Share Posted April 16, 2018 Рано радовался . С данными драйверами мокса не правильно устонавливает скорость. Терминал на одном компьютере через моксу шлет "0" со скоростью 115200. Терминал на другом компьютере с другим , ранее проверенным, преобразователем принимает "0" на скорости 122843. Коэфициент 1.066 Проверили на 9600 и 115200 - коэфициент работает. PS: Коллега сообщил, что подобный эффект был в ранних версиях драйверов. Не думаю, честно говоря, что это как то связано с драйверами. Скорее с погрешностью внутреннего осциллятора. Причём предположу, что если карту нагреть (или наоборот, охладить) - результаты измерений будут другими. Синхронизация у нас происходит по старт-биту, а он в каждой посылке. Хотите сказать, что с коэффициентом 1,066 не успеваете передать 8 бит? Link to comment
Aleksey710 Posted April 16, 2018 Author Share Posted April 16, 2018 Рано радовался . С данными драйверами мокса не правильно устонавливает скорость. Терминал на одном компьютере через моксу шлет "0" со скоростью 115200. Терминал на другом компьютере с другим , ранее проверенным, преобразователем принимает "0" на скорости 122843. Коэфициент 1.066 Проверили на 9600 и 115200 - коэфициент работает. PS: Коллега сообщил, что подобный эффект был в ранних версиях драйверов. Не думаю, честно говоря, что это как то связано с драйверами. Скорее с погрешностью внутреннего осциллятора. Причём предположу, что если карту нагреть (или наоборот, охладить) - результаты измерений будут другими. Синхронизация у нас происходит по старт-биту, а он в каждой посылке. Хотите сказать, что с коэффициентом 1,066 не успеваете передать 8 бит? Link to comment
Незнайка Posted April 16, 2018 Share Posted April 16, 2018 Рано радовался . С данными драйверами мокса не правильно устонавливает скорость. Терминал на одном компьютере через моксу шлет "0" со скоростью 115200. Терминал на другом компьютере с другим , ранее проверенным, преобразователем принимает "0" на скорости 122843. Коэфициент 1.066 Проверили на 9600 и 115200 - коэфициент работает. PS: Коллега сообщил, что подобный эффект был в ранних версиях драйверов. Не думаю, честно говоря, что это как то связано с драйверами. Скорее с погрешностью внутреннего осциллятора. Причём предположу, что если карту нагреть (или наоборот, охладить) - результаты измерений будут другими. Синхронизация у нас происходит по старт-биту, а он в каждой посылке. Хотите сказать, что с коэффициентом 1,066 не успеваете передать 8 бит? Но вообще да, если взять 160 измерений на посылку, то получим допустимое отклонение около 0,5%, а здесь аж 6,6, как я понимаю. Link to comment
Aleksey710 Posted April 16, 2018 Author Share Posted April 16, 2018 Рано радовался . С данными драйверами мокса не правильно устонавливает скорость. Терминал на одном компьютере через моксу шлет "0" со скоростью 115200. Терминал на другом компьютере с другим , ранее проверенным, преобразователем принимает "0" на скорости 122843. Коэфициент 1.066 Проверили на 9600 и 115200 - коэфициент работает. PS: Коллега сообщил, что подобный эффект был в ранних версиях драйверов. Не думаю, честно говоря, что это как то связано с драйверами. Скорее с погрешностью внутреннего осциллятора. Причём предположу, что если карту нагреть (или наоборот, охладить) - результаты измерений будут другими. Синхронизация у нас происходит по старт-биту, а он в каждой посылке. Хотите сказать, что с коэффициентом 1,066 не успеваете передать 8 бит? Скорее похоже на сбитый коэффициент. На разных скоростях один и тот же. на картинке Верхний - MOXA(НЕ работает с другими устройствами) Нижний - USB-RS485 преобразователь(работает с другими устройствами) мокса спешит Link to comment
Aleksey710 Posted April 16, 2018 Author Share Posted April 16, 2018 Windows 7 , драйвера с сайта MOXA HyperTerminal 115200 символ "0" (0х30) Каждый второй символ битый. Link to comment
Aleksey710 Posted April 16, 2018 Author Share Posted April 16, 2018 с putty такой проблемы нету Link to comment
Aleksey710 Posted April 16, 2018 Author Share Posted April 16, 2018 Под Windows с putty такой проблемы нету Но нужна работа под Linux. По проведенным экспериментам можно сказать, что сама плата(железо) скорее рабочее (Под Windows скорее работает , чем нет). Ньюанс работы Hyperterm конечно странен, но с другой стороны, другим терминалом (putty) работает нормально. Под Linux идет ускорение передачи с коэфициентом 1.066. И в свете вышесказанного наибольшее подозрение вызывают именно драйвера. По прежнему актуален вопрос: Как сделать так , чтоб все работало нормально? Link to comment
Незнайка Posted April 17, 2018 Share Posted April 17, 2018 Под Windows с putty такой проблемы нету Но нужна работа под Linux. По проведенным экспериментам можно сказать, что сама плата(железо) скорее рабочее (Под Windows скорее работает , чем нет). Ньюанс работы Hyperterm конечно странен, но с другой стороны, другим терминалом (putty) работает нормально. Под Linux идет ускорение передачи с коэфициентом 1.066. И в свете вышесказанного наибольшее подозрение вызывают именно драйвера. По прежнему актуален вопрос: Как сделать так , чтоб все работало нормально? А коллега заодно не сообщил, в какой конкретно версии драйверов этой проблемы не наблюдается? Это здорово помогло бы в поиске причины. Link to comment
Незнайка Posted April 17, 2018 Share Posted April 17, 2018 И ещё вопрос - когда использовали Hyperterminal, что стояло в поле Flow Control? Link to comment
Незнайка Posted April 17, 2018 Share Posted April 17, 2018 И ещё есть мнение, что неплохо бы отключить FIFO #setserial /dev/ttyXXX uart 16450 как то так должно отключаться, по идее. Link to comment
Aleksey710 Posted April 17, 2018 Author Share Posted April 17, 2018 Под Windows с putty такой проблемы нету Но нужна работа под Linux. По проведенным экспериментам можно сказать, что сама плата(железо) скорее рабочее (Под Windows скорее работает , чем нет). Ньюанс работы Hyperterm конечно странен, но с другой стороны, другим терминалом (putty) работает нормально. Под Linux идет ускорение передачи с коэфициентом 1.066. И в свете вышесказанного наибольшее подозрение вызывают именно драйвера. По прежнему актуален вопрос: Как сделать так , чтоб все работало нормально? А коллега заодно не сообщил, в какой конкретно версии драйверов этой проблемы не наблюдается? Это здорово помогло бы в поиске причины. Нет. Очень давно и под Windows. Вопрос понятен, но выяснить точную версию нет возможности. Link to comment
Aleksey710 Posted April 17, 2018 Author Share Posted April 17, 2018 И ещё вопрос - когда использовали Hyperterminal, что стояло в поле Flow Control? 8N1 аппаратное Link to comment
Aleksey710 Posted April 17, 2018 Author Share Posted April 17, 2018 И ещё есть мнение, что неплохо бы отключить FIFO #setserial /dev/ttyXXX uart 16450 как то так должно отключаться, по идее. попробовал. Разницы не заметно. Link to comment
Aleksey710 Posted April 17, 2018 Author Share Posted April 17, 2018 Если Моха работает на более высокой скорости с устойчивым коэфициентом, то если если ей поставить не стандартную скорость , чтоб с учетом коэфициента она давала норму. будет работать или нет? Провел такой эксперимент. MOXA прием коэфициент расчетная скорость полученная скорость 19200 20491 1,067 17994 10245 57600 61576 1,069 53882 10245 115200 123152 1,069 107764 10245 Вопрос. Должна ли была моха работать на нестандартной скорости? Link to comment
Незнайка Posted April 17, 2018 Share Posted April 17, 2018 Если Моха работает на более высокой скорости с устойчивым коэфициентом, то если если ей поставить не стандартную скорость , чтоб с учетом коэфициента она давала норму. будет работать или нет? Провел такой эксперимент. MOXA прием коэфициент расчетная скорость полученная скорость 19200 20491 1,067 17994 10245 57600 61576 1,069 53882 10245 115200 123152 1,069 107764 10245 Вопрос. Должна ли была моха работать на нестандартной скорости? Вообще должна работать. Есть предложение переопределить частоту осцилятора в mxpcie.c, то есть установить её не 14745600, а с учётом коэффициента, т.е. исправить неким таким образом: #define FREQUENCY 13793826 . Самому даже интересно, получится или нет Link to comment
Aleksey710 Posted April 17, 2018 Author Share Posted April 17, 2018 Если Моха работает на более высокой скорости с устойчивым коэфициентом, то если если ей поставить не стандартную скорость , чтоб с учетом коэфициента она давала норму. будет работать или нет? Провел такой эксперимент. MOXA прием коэфициент расчетная скорость полученная скорость 19200 20491 1,067 17994 10245 57600 61576 1,069 53882 10245 115200 123152 1,069 107764 10245 Вопрос. Должна ли была моха работать на нестандартной скорости? Вообще должна работать. Есть предложение переопределить частоту осцилятора в mxpcie.c, то есть установить её не 14745600, а с учётом коэффициента, т.е. исправить неким таким образом: #define FREQUENCY 13793826 . Самому даже интересно, получится или нет 1. После изменения коэфициента (обращаю внимание на мелкий выброс) 2. То что было до изменения 3. Через работающий преобразователь. (типа норма ) Link to comment
Незнайка Posted April 18, 2018 Share Posted April 18, 2018 Ерундой какой то занимаемся. Думаю, надо сделать так: Step 1. Create /etc/modprobe.d/blacklist.conf if it is not exit. Step 2. Add following line into the file blacklist 8250_moxa Step 3. Reboot the systemStep 4. Reload the mxupcie module again. Link to comment
Aleksey710 Posted April 18, 2018 Author Share Posted April 18, 2018 Уже при связи между терминалами Putty/minicom появляются ошибки. Схема тестирования minicom logic16 Putty MOXA USB-RS485 USB-RS485 |_________RS485-2W_________|___________________| Скриншоты Logic2-нормальный0.png и Logic2-4332.png - из putty(USB-RS485) в minicom (MOXA) символ "0" (0x30) проходит нормально (1 стартовый +8 данных = 78 us). Скриншоты Logic2-битый0.png и Logic2-4068.png - из minicom (MOXA) в putty(USB-RS485) символ "0" (0x30) проходит за более короткий временной интервал (1 стартовый +8 данных = 73,24 us) и соответственно не распознается ни анализатором ни приемником другого адаптера. В скриншотах Logic2-4332.png и Logic2-4068.png - временные показатели. В скриншоте Logic2-диаграмма.png показана разница по времени между "нормальным" и "битым" символами. PS: Детально расписал где чего не так. Link to comment
Aleksey710 Posted April 18, 2018 Author Share Posted April 18, 2018 Ерундой какой то занимаемся. Думаю, надо сделать так: Step 1. Create /etc/modprobe.d/blacklist.conf if it is not exit. Step 2. Add following line into the file blacklist 8250_moxa Step 3. Reboot the system Step 4. Reload the mxupcie module again. Вроде как даже заработало. Запустил свое ПО. Наблюдаю... А что это было и почему оно нигде не указано? (В офф. доках не наблюдал). 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