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.

В рантайме проверить доступность не проблемма - но как мне нить вытащить из 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 с корректно указанным номером девайса, - вся проблема же в этой строке, - что рекавери не дает прошить если имя устройтсва не совпадает, как я понял.