boris_r_v
-
Posts
106 -
Joined
-
Last visited
Content Type
Profiles
Forums
Calendar
Posts posted by boris_r_v
-
-
День добрый господа и дамы.
Суть вопроса в жизненном цикле ряда контроллеров на базе RISC процессоров и возможной замене уже снятых с производства.
Конкретно интересует ряд устройств:
1. Moxa W321-lx снят с производства поиск по сайту moxa.ru аналог не показал: Вопрос: планируется появление аналога на платформе UC-2100, если да - то в какие сроки?
2. Moxa UC-2111-lx недавно вышел, на замену UC-7112-Plus. Вопрос: какова длительность его производства, когда планируют прекратить выпуск?
3. Moxa UC-8112-lx в его серии UC-8100 есть контроллеры снятые с производства. Вопрос: сколько он еще будет в производстве?
Как Вы понимаете вопросы не праздные, выбор платформы для IOT особенно с непонятными сроками производства та еще задача.
Заранее благодарен за ответ.
-
модель: NPort IA5250AI
Такое оборудование стоит у заказчика, узнать номера некому, но есть аналогичный в конторе, надеюсь его серийник подойдет:
s/n TAAD01067508
-
Просьба выслать вличку волшебный скрипт перезагрузки NPort 5-й серии. Данная проблема стала проявляется
-
Вам подойдет готовое решение в виде MGate
Если нужно все же кодить самостоятельное решение—то смотрите в сторону libmodbus
-
Собственно проблематика ясна из названия, но уточню ,пропадание конфигурационного файла /etc/default/hostapd происходит не при каждой перезагрузке.
Уважаемое сообщество сталивался ли кто-то еще с подобной проблемой?
-
В плане околонаучного бреда: как вариант можно поробовать сменить прошивку UC на NPORT, например от 5230. Т.к. отличия только в прошивке, аппаратная платформа одна и таже, но это может штатный boolloader не дать сделать - т.к. можно убить зверька экспериментами.
Так что на свой страх и риск- так сказать.
-
Прекрасно, что комрад "Незнайка" так близко к сердцу воспринимает поднятую проблему - это залог ее успешного решения. Но в этом топике идет не обсуждение скилла участников, а несоответсвие linux nport драйвера linux system calls convections. (для примера: man syscalls, второй абзац посвящен обработке ошибок происходящих во время вызова)
Для решения данной проблемыв рамках обсуждения поступила два предложения:
1. Писать отдельную прослойку для работы с последовательными портами nport - плохой вариант по двум причинам: 1) неединообразно с другими устройсвами 2) нарушение инкапсуляции функций системы
2. Исправить ядерный модуль (добавить соответствие соглашению по системным вызовам) - отличный вариант, но что мешает производителю оборудования это сделать - это же его продукт и опыта у него гораздо больше в данном вопросе?
P.S.
Ну и интересна актуальность рассматриваемой проблемы и насколько приведенные ранее цифры в 99% точны - может на самом деле я "сгущаю краски" или, что наиболее вероятно - всех интеграторов и так все устраивает, с эксплуатацией введенных систем она редко связывыются. Или, как вариант, windows драйвер работает более корректно с системными вызовами?
P.P.S. Очень хотелось бы услышать комментарии технического специалиста по данной тематике, должна же быть объективная причина нестандартному поведению ядерного модуля.
-
понятно, что с помошью ряда костылей и подпорок, названных, к примеру: midleware(portabl) layer. Эта задача решается, но ИМХО одидается, по—умолчанию. стандартное поведение: не получается выполнить запрос — верни ошибку и двигаемся далее. Потом пишем обработчик, на случившуюся ошибку. А тут тебе по не ошибок, ни работы—только ступор нити в системном вызове. Вот об этом речь у комрада xxxxAxxxx.
-
1 hour ago, Незнайка said:
Странно слышать вопрос о том, куда встраивать обработчик от человека, у которого в подписи "embedded arm-device coding"
Я понимаю, что с точки зрения разработчика (ПО?) хочется взять всё готовое и использовать как своё. Но, кмк, в данном случае, требовать от драйвера ещё и проверять целостность вашей сетевой инфраструктуры - это уже несколько избыточно. Проверяйте доступность NPort и генерируйте ошибки. Драйвер то откуда знает, что и как, может у вас спутник с задержкой в 15-20 сек (а такое у нас тоже встречается)?
В рантайме проверить доступность не проблемма - но как мне нить вытащить из kernelspace если она уже там и ждет завершения системного вызова. Допускаю, что я не могу все знать, но про завершения вызова на уровне ядера ( из ядерного моделя npreal2) из user space не слыхал ни разу, а именно это вы предлагаете делать.
Тут приложение зависнет в системнов вызове ранее, чем я узнаю о пропадании пинга на nport.
Вроде доступно олбъяснил что не получитсья решить проблемуу из приложения user space
-
Позвольте и свои 5-коп вставить:
Есть аналогичная проблема, при разрывае линка. команда записи данных в последовательный терминал: ssize_t write(int fd, const void *buf, size_t count); from (unistd.h) проваливается на уравень ядра и не держиться там пока линк не поднимут.
Хочется спросить у господина "Незнайки" - куда встраивать обработчик ошибки если нет сообщения об ней? Или ваш ответ был сделан "просто так"?
-
Есть два мнения:
1) нужно проверить настройки последовательного порта, может банально включено программное управление потоком.
2) если связь по сети неустойчива - может быть все что угодно, в линукс драйвере например функции write/read в этом случае с рандомным результатом заканчиваются: то ожидаемо, то с некорректно и/или с большим интервалом.
-
SNMP работает, но собранных логов нет.
К RSTP вопросов.
Вообщем путем нехитрого вдумчивого чтения логов коммутатора разрешились оба вопроса:
1) изменения топологиии так как теряется связь между коммутаторами на продолжительное время;
2) а по второму вопросу - подолжительное время перешло в разряд ВСЕГДА ( это судя по логам после ребута 7-й порт так устойчивый коннект неувидал, потом два последовательных - это инженер на объекте снимал его.)
Тему прошу считать закрытой, если мнение админа совпадает с моим - что тема не несет рационального зерна - то удалите ее.
-
День добрый, господа и дамы.
Исходные данные граблей: два коммутатора, включен протокол RSPT, дублирующего кабеля нет, расстояние между коммутаторами по кабелю 1[метр] кабель гарантированно цел (его длина 1 метр и он просматривается глазами).
Описание проблемы: узлы включенные в разные коммутаторы перестают видеть друг друга, перезагрузка коммутаторов не помогала им (узлам сети) наладить связь (время включенного состояния коммутатора около 20минут). При это система мониторинга сети видит, что оба коммутатора к сети присутствуют.
Снятые логи со второго свича у которого Bridge Priority больше чем у соседа.
Вопрос:
1. Исходя из приатаченных картинок можно сделать вывод, что проблема в дребезге кабеля по 7-му порту которым коммутаторы связаны? или нет.
2. Почему после включения коммутатора, он в сети появился, но за 20 минут работы связь между узлами не появилась?
Буду благодарен за любую помощь.
P.S. я понимаю, что при таких исходных условиях никакого спанинг протокола не нужно (не мой выбор), но надо понимать в чем причина такого поведения сети.
-
Подозреваю - тебе Захар нужно пересобрать эти исходники с помощью toolchain (набор кросс-компиляторов) и залить на зверька и дальше что-то делать с получаемыми данными.
Вообще - то это не тривиальная задача, по сути тебя просят сделать самописный ПЛК, под какую-то конкретную задачу.
Я бы на твоем месте поискал подходящее железо для этой задачи у тех же самых адамов должно что-то быть.
-
Премного благодарен, за помощь
-
Сорян за некропост, но можно в эту тему скинуть фотографию с обратной стороны печатной платы.
А то все распаяли - нашли пробитый кондер, который коротил, - теперь спаять надо, а что куда паять не помним.
Заранее благодарен за помощь.
-
Немного офтоп, но может тут утилиту выложить, и тему заморозить - раз такой ажиотаж.
-
тогда просвети, т.е. если я так сделаю
int fd = open("/dev/ttyS0", .... );
...
uint8_t buff [12];
bzero( buff, sizeof(buff) );
write( fd, buff, sizeofg(buff) )
То на уровне физики у меня будет сформировано 12 посылок, и каждая из них будет обернуты в старт-стоп биты? ( и биты ли)
И кто в этом случае будет выступать в качестве признака пустого канала?
Ну или если много буков - то ткните в первоисточник.
Заранее благодарен.
-
Пару моментов
1. При закрытии терминала(сессии) все процессы у которых специально не обрабатывается сигнал SIGINT(вроде) умирают.
2. Проверил на w325 - у меня вообще не получилось сделать запуск описанным ранее способом. Походу реализации su разные.
3. gcc - это компилятор, для компиляции программ нужен набор системных библиотек и <b>заголовоных файлов</b>, как раз и из-за последних на контроллере ничего собрать не получиться - там их нет, д аи жутко медленно будет. Поэтому и была придумана кросс-компиляция. - это когда ты на х86 собираешь программки для arm.
А теперь ответ: gcc для moхa UC-7112+ - странная штука, скорее всего не существующая в природе. если надо что то собрать то поищи программинг гайд и пользуй тоолчайн с диска.
Например тут: http://www.moxa.com/support/support_home.aspx?isSearchShow=1
-
-
Успех
100% успех, прошивка встала.
"Незнайка" огромное спасибо за помощь и за то что обогатил меня новыми знаниями и опытом - про xmodem не знал и в serial-coinsole до этого не работал.
Еще раз огромное спасибо.
-
окай - мерси
Кстати с запуском то не от рута - получилось?
-
А.а.а. - ну сорян.
Тогда хотелось бы уточнить насчет 1.2 в чем была ее глюсность и если ее залиф не сломает рекавери - то может ее попробовать?
-
А возможен такой вариант кинуть сюда всё что есть а я попробую перепрошиться из рекавери.
Ну и как вариант может где то есть 1.3 с корректно указанным номером девайса, - вся проблема же в этой строке, - что рекавери не дает прошить если имя устройтсва не совпадает, как я понял.
Moxa UC-2111-lx UC-8112-lx RoadMap цикл производства
in Встраиваемые коммуникационные компьютеры
Posted
Благодарю