boris_r_v

Оговорюсь сразу, что нижеописанная проблема меня еще не коснулась, но возможность ее появления высока, и если она[проблема] имеет красивое решение то хочу чтобы оно стало достоянием общественности. Суть гипотетического трабла: Есть некий встраиваемый контроллер пусть будет UC-7112+, у него два последовательных интерфейса и он где то стоит, чего-то делает и оба его порта заняты. И вот на "его" объекте автоматизации появляется еще устройство, которое надо цеплять к отдельному порту, - к третьему. Еще один контроллер не поставить (АСУ ТП писали пленные индусы сидя в подвале у китайцев), и на другой не заменить (бабосов нема... ), НО есть NPORT который лежит на складе и грустит без работы. И надо через него контроллеру, по легкому, опросить третье устройство. Есть два варианта: 1. использовать tcp-порты NPort и слать на них запросы к устройству, но это требует изменение работы софта, а он умеет работать только с tty-устройствами, а пленные индусы были выкуплены из рабства микрософтом и в качестве дембельского аккорда удалили всю документацию на АСУ ТП. Т.е. вариант с tcp не подходит по принципу "по-легкому". 2. использовать ядерный модуль (driver NPort) - тут встает вопрос как его собрать под ядро контроллера? Вопрос более к комраду "Komantsev", может он по своим каналам прояснить второй вариант? От себя добавлю, что при буду пробовать собрать ядерный модуль тулчейном. о результатах напишу...

а у меня NPort-5250AI держит скорости 300бод а вот циферки 240 не было. хош свой продам у меня как раз один порт погорел... а второй остался... не дорого отдам, но самовывоз из Мухосранска...

kma - учи мат.часть... (wifi ad-hoc mode, nport service) если у мохи заявлена поддержка режима "ad-hoc", то они организуют одноранговую сеть (если даже из коробки и не заработает то update firmware - и все заработает ), вот со средствами отображения может возникнуть вопросы.

Видимо я ошибся. A wireless ad hoc network is a decentralized type of wireless network. - нагуглил по "wifi ad-hoc mode" 1-ая ссылка. Протестил ad-hoc в конторе на буках коллег (по этой мурзилке: https://help.ubuntu.com/community/WifiDocs/Adhoc). Итог: на самом деле это не совсем та точка-точка, как в старину два компа через ком-порты соединяли... - это полноценная одноранговая сеть. Так что у автора поста получится объединить два W2150 в одноранговую сеть - точно, получится подключится к ней с ноута (почти все wifi свистки ноутов режим ad-hoc поддерживают). Но надо будет аккуратно выбирать в этом случае планшет, мне почему-то кажется, что вайфай свистки не всех планшетов поддерживают режим ad-hoc. Ибо сама идея планшета быть в инфраструктуре, и конектится к точки доступа. Так что пожелание к автару если найдет такой планшет - то отписаться, какой - мне тоже в ближайшем будущем это пригодится.

не считайте меня некропостеом, но драйвер mxser включен в ядро Linux очень давно, в версии 2.4.20 он уже был. Так что мешает пересобрать ядро с его поддержкой, если она до этого не была включена. Благо по умолчанию конфиг существующего ядра лежит в /boot/config...

Естественно что два W2150 в режиме Ad-Hoc дадут разные точки доступа, и между ними надо будет переключатся. Чтобы была одна точка доступа: надо использовать любую бытовую точку доступа (хоть тот же dlink dir-320), со встроенным свичем (хабом) - на нем поднимать точку доступа в режиме инфраструкура. В сетевые порты длинка втыкать линки на Nport 5110A - к ком-портам которых подключены ваши датчики. а потом все как писал Komantsev. Хотя по хорошему, это задача автоматизации и надо соответствующим образом решать. Контроллер который опрашивает датчики, хранит архивы данных и имеет Web-морду для отображения информации.

Еще мысль возникла. Если у Вас это единичный экземпляр то ладно. Но если это тиражируемое решение по организации обмена с цифровыми устройствами, - то Вы используете не те решения. Необходимый вам функционал реализуют NPortы, они открывают TCP-порты, которые ассоциируются с serial портами и гоняют между ними трафик. Т.е. драйвера которые дают com-порты в винде ставить не обязательно, ибо драйвера только открывают TCP соединения, и пропускают трафик через себя. Понятно, что NPort по сути это Plug&Play устройства не требующего никакого стороннего софта, а только настройку режимов работы через web-морду. Если все же нужен именно встраиваемый контроллер то пишите в личку, чего надо с софтинкой помогу.

Насчет достояния общественности - очень спорный вопрос. Код поглядел. причину предполагаю - скажите вам использования TCP протокола принципиально или его можно на UDP заменить. Ибо причина подвисаний скорее всего в таймаутах на закрытие и открытие соединений по TCP, а в этой прожке при любом сбое на чтение или запись портов serial & lan происходит закрытие всех портов и потом по новой открываются. Вариантов два: 1. менять TCP на UDP 2. продумать какая нужна реакция на ошибки чтения/записи - я бы оба варианта применил. P.S. или вообще pipe использовать....

Не знаю актуально ли еще, но прошивки на данных контроллерах, а следовательно версии библиотек различны, на 8410-более поздние. Linux, а как я понял он там стоит, имеет поддержку ПО верху вниз. Т.е. то что работало на более ранней версии почти всегда будет работать и на более поздней. Конечно если не сменились мажорные номера либ. Поэтому решение два: 1. Попробовать сделать то же что и для 7410, если не срастется - то: 2. Найти исходники того, что ставилось на 7410, пересобрать тулчейном от 8410, и поставить. Если исходников нет то писать с нуля... - вот такие не радостные перспективы. Когда в конторе не организованно хранение и поддержка ПО.

P.P.S. в файла sd1.tgz - были оставлены только бинарники, которых должно хватить для работы, если чего не заработает, то собрать самим. Полный архив весит порядка 14 мегабайт, а тут ограничение на 4.88 метров - поэтому выкинуть все лишнее.

Доброго времени суток. Утомило меня извлекать sd-card из зверька для обновления ПО (да оно у меня там лежит), да убогий vi заточенный под размер 40х70 символов (под tty-console), - поэтому решил запихнуть на карточку mc и nfs-server, далее идет графомания по теме: "как это было". Что мне было надо: 1. тулчейн - который шел со зверкем 2. исходники нужных пакетов: 2.1. для mc: glib-2.24.2 mc-4.7.0.1 ncurses-5.7 zlib-1.2.7 (zlib не обязательно на зверке она есть) 2.2. для nfs-server: nfs-utils-1.1.4 util-linux-ng-2.17.2 3. google + direct hand + brain Чтобы не иметь дальше проблем с путями библиотек я создал каталог на своей машине, куда монтируется sd на uc-7112+ - это /var/sd. Создание: sudo mkdir -p /var/sd && sudo chown -R boris:users /var/sd. Теперь этот каталог буду указывать в качестве --prefix на стадии configure. С mc проблем не возникло - спасибо за это этому блогу http://3month-of-lif...arm-mc-arm.html Там собирают mc для ucLinux(как я понял) - поэтому все статически линкуется, на uc-7112+ - стоит полноценный linux, поэтому ключи --statiс и подобные ему я опускал. nfs-server - который разбит на куски (как читать тут: http://nfs.sourcefor...owto/index.html) лежит в пакете nfs-utils, который зависит от дрянной библиотеке libblkid, которая перенесена системный пакет линух под названием util-linux-ng, можно конечнобыло и без этой либы собрать но это как то не тру. сборка util-linux-ng: ./configure ARCH=arm CC="arm-linux-gcc" CROSS_COMPILE="arm-linux-" --host=arm-linux CFLAGS="-I/var/sd/include -I/var/sd/include/ncurses" LDFLAGS="-L/var/sd/lib" --prefix=/var/sd --with-ncurses make && make install тут без проблем все собралось. сборка nfs-utils: ./configure ARCH=arm CC=arm-linux-gcc CROSS_COMPILE=arm-linux- --host=arm-linux CFLAGS="-I/var/sd/include -I/var/sd/include/blkid" LDFLAGS=-"L/var/sd/lib" \ --prefix=/var/sd --exec-prefix=/var/sd --disable-gss --disable-nfsv4 --with-tcp-wrappers=no \ --cache-file=arm-linux.cache --with-statedir=/var/sd/sd2/var/nfs --with-statdpath=/var/sd/sd2/var/nfs Почему то все равно спотыкается на проверке libblkid поэтому надо сказать конфигуратору, что он есть: echo "ac_cv_lib_blkid_blkid_get_library_version=yes" >> arm-linux.cache ну и далее make && make install как запустить nfs-server написано в файлике README Далее залить все на флеш и включить зверька. P.S. Для особо ленивых залью то что получилось У меня флеш разбита на два раздела, и на обоих разделах ext2: sd1 - с ситемными либами - она перемонтируется в read-only sd2 - для хранения временной ифомации рабоыт систем контроллероа она - в read-write Вот такая история, много лайков автору...

Прошу прощения за поздний ответ, - я уж не ждал получит хоть какой-то ответ по этой теме. Нет устройств у нас меня нет, поэтому экземпляр на тестирование - это отличный вариант. А вопрос возник потому что - где-то нашел спеку на UC-74xx - там был ARM из той же серии, что и на UC-7112+, а там как я уже писал нет вачдога в его прямом понимании нет.

Доброго времени суток уважаемое сообщество. У меня следующий вопрос: как работает wdt на данном девайсе. В мануале я прочитал как он ДОЛЖЕН работать, выдержки приводить не буду. У кого нибудь сей девайс перегружался когда умирало приложение которое сбрасывало wdt. Спрашиваю потому, что возился с wdt на uc-7112+ - так вот там при смерти приложения которое сбрасывало wdt, ядро начинало его сбрасывать, а на uc-7410+ как это работает хотелось бы узнать, прежде чем его порекомендовать проектировщикам в сметы. Заранее спасибо, друзья.

Решением проблемы при перезагрузке зверька когда основная софтинка сдохнет, стал примерно такой скрипт #!/bin/bash /var/sd/bin/my_soft_start_command 1>/dev/null 2>&1 # - тут имеем блокировку терминала пока прога не вылетит reboot # - тут ребутим зверька #profit Встроенный сторожевой пес при смерти софтины которая его обнуляла начинает обнуляться ядром linux - и не хочет ребутить зверька. А срабатывает только тогда когда ядро повесишь(уже не помню как я его повесил), но делал это намеренно - проверить, когда это уродский таймер перезагрузит контроллер. Большое спасибо сапорту форума за "активное" участие в теме. З.Ы. - эта убогая реализация watchdog - единственное, что мне в Moxa-UC7112+ не нравится. В остальном твердая 4+.

Не надо обзывать меня некропостером.... Но решил по случаю отписать насчет температуры работы moxa uc7112+ Делали испытания на климатику измерительной станции, где в качестве контроллера пользовался сабж испытания были жесткими: -60 градусов - 48 часов, потом разрогрев до +70 в течении суток, влажность 80% и снова двое суток жары, после адского холода. И контроллер за все время не сбоил, исправно слал данные по сети и ловил по rs485. Еще были испытания на восстановление работы после перебоев с питанием при тех же температурах - все штатно... Вот как-то так...

Проблема не в этом да и ладно, актуальность спала, а кому надо ,если умные, и так поймут. А перемонитировать корень в чтение-запись - самый верный путь убить зверька, умрет не сразу, но в самый не подходящий момент, после сброса питания, во время загрузки корневая фс не пройдет проверку, а это к поезке, для замены зверька. Поэтому низзя... Мир.

MuadDib ядро не опознало тип файловой системы, - сделай на ней ext2 и попробуй снова, поддержка ext2 наглухо зашита в ядро, если мне память не изменяет, отключить ее никак нельзя - так что любое ядро линух эту систему опознает без дополнительных пасов руками. Ну и в наличии журналируемой фс на флеше, - это открытый вопрос, холиваров нете полно на эту тему, я для себя решил на флешках ext2, и после загрузки контроллера в скрипте запуска софта mount -o remount,ro /mnt/flash а потом запускаем софт контроллера Для любой флешки хоть sd, хоть cf, хоть NAND on IDE - да и такие были, прям в разъем ide втыкались... И за 13 лет практики, ни одного сбоя файловой системы на флешке из-за перезагрузки контроллера, журналы смогут так... Удачи.

Написал мне тут в личку один участник нашего форума, были у него проблемы с монтированием флеша, и чтобы челу ответить я разобрался как оно происходит. У меня все сразу заработало, поэтому не лез тудой. Так вот После загрузки ядра и передачи управления инит скрипту загрузки системы, по концови запускается скрипт /bin/sdpnp, следующего содержания root@Moxa:~# cat /bin/sdpnp #!/bin/sh case "$ACTION" in 'add') if ! [ -d /var/sd ]; then mkdir /var/sd fi mount /dev/mmc1 /mnt/sd str=`mount | grep mmc1` if [ "$str" == "" ]; then rm -fr /var/sd fi ;; 'remove') sleep 1 umount /mnt/sd rm -fr /var/sd ;; *) ;; esac exit 1 вот тут происходит создания папки куда замонтируется флеш if ! [ -d /var/sd ]; then mkdir /var/sd fi пока все отлично.... но вот следующая строка - это шах и мат логике mount /dev/mmc1 /mnt/sd монтируем флеш не в ту папку которую создали, а в другую /mnt/sd --- пц.пц.пц ...как спросит внимательный читатель, а вот так root@Moxa:~# ls -l /mnt/ drwxr-xr-x 2 root root 0 Jun 2 2009 defdisk lrwxrwxrwx 1 root root 12 Jun 5 2009 ramdisk -> /var/ramdisk lrwxrwxrwx 1 root root 7 Jun 5 2009 sd -> /var/sd root@Moxa:~# оказывается /mnt/sd - это симилинк на /var/sd, и этот симилинк присутвует всегда, вот цели симилинка может и не быть. Симилинк видимо записан в корневой ФС, которая разворачивается при старте зверька, и поэтому все работает.... В доказательство сего провел эксперимент: изъял флешку из зверька и запутил его, - вот вывод root@Moxa:~# ls -l /var drwx------ 2 root root 1024 Dec 10 2005 empty drwxrwxrwx 3 root root 1024 Dec 26 2005 lib drwxrwxrwx 2 root root 1024 Dec 10 2005 lock drwxrwxrwx 3 root root 1024 Dec 10 2005 log drwxrwxrwx 2 root root 1024 Dec 27 19:49 run drwxrwxrwx 2 root root 1024 Dec 10 2005 tmp root@Moxa:~# ls -l /mnt drwxr-xr-x 2 root root 0 Jun 2 2009 defdisk lrwxrwxrwx 1 root root 12 Jun 5 2009 ramdisk -> /var/ramdisk lrwxrwxrwx 1 root root 7 Jun 5 2009 sd -> /var/sd root@Moxa:~# как видно папки /var/sd - нет, а симилинк на нее есть /mnt/sd. НО если в силу какого то сбоя во время эксплуатации, этот симилинк будет уничтожен и пропадет из корневой ФС, то монтирование не случится Это и есть логическая ошибка, создаем одну папку, а монтируем в другую... Я все понимаю тестирование на заводе, в мануле написано черным по англицкому, лейте свой софт на внутреннюю флеш, чтобы он быстрей работал(???). А если он туда не входит, например. По /bin/sdpnp видно что если софт будет на sd-card, то в один прекрасным миг он просто может не загрузиться, когда пропадет симилинк, понимаю маловероятная ситуевина, НО ... Посему огромная просьба к админам данного форума передать эту инфу разработчикам прошивки и поменять данный скрипт ну хотябы вот так: mount /dev/mmc1 /var/sd или всегда ее монтировать в папку /mnt/sd, которая не будет симилинком, а каталогом P.S. Собственно это изменение можно внести и самому, vi есть на борту, а mount -o remount,rw / - нам никто не запретит сделать, только потом обратно не забудьте в ридонли перемонтироваться mount -o remount,ro / Только делать это в брендовой железяке на 13к - как-то ... Да и после этого изменения на горячую измелечение, установка флешки не приводит к монтированию отмонтированию флеша Так что делать или не делать решать Вам.

ну насчет перевода я не в курсе, да и эклисами не пользуюсь, от make and direct hand тащусь, но в данном предупреждении говориться, что имеет место быть попытка инстантировать шаблон у которого 5-й параметр заявлен беззнаковым целым длинным, а устанавливается знаковым целым длинным - т.е. закладываешь себе мину замедленного действия, как в той истории про робота который переварачивался из-за того считал что едет назад и сматывал интерфейсный кабель, а на самом деле просто разогнался так что значение скорости в переменной изменило содержимое 7 бита (считаем с 0) в старшем байте скорости, - из-за чего робот посчитал что, скорость отрицательна, значит едет назад.... либо измени шаблон, либо сделай безопасное приведение типов ... и будет тебе щастье P.S. и личку проверь, я там тебе по флешке отписался.

Упс... да по пункту 1 - это епикфайл. поправил все отлично, перезаписывает значение таймера. Если закоментировать строку //wdt_refresh ( wfd ); и запустить прожку без параметров то зверек как и положено перегружается через 12 секунд, ну или около того, время не замерял. все в соответствии с инструкцией. 4. Special Note When you “kill the application with -9” or “kill without option” or “Ctrl+c” the kernel will change to auto ack the sWatchDog. When your application enables the sWatchDog and does not ack, your application may have a logical error, or your application has made a core dump. The kernel will not change to auto ack. This can cause a serious problem, causing your system to reboot again and again. Теперь по поводу реализации самого sWatchDog, вопросы к админам форума, ибо у них есть прямой выход на разработчиков. 1. sWatchDog - надо понимать как сокращение от Soft WatchDog? - это так для общего развития 2. как сделать так чтобы когда приложение будет остановлено ( не важно как, kill, cntl+C, хоть само свалится, например из-за ошибки приводящей к маленькой утечки памяти, и пропущенной при тестировании) watchdog не начал сбрасываться ядром, а перегрузил систему, ибо в такой реализации таймера профита от него не много. 3. И как этот таймер отреагирует на подвисание самого ядра - ребутнет систему или вместе с ядром повиснет. Заранее спасибо за ответы.

На диске, что шел со зверьком не было исходников методов работы со сторожевым таймером, а статическая библиотека, что так же была на диске не линкуется с динамическими по вполне понятным причинам. Поэтому спасибо обществу подсказали пару ссылок, на исходники библиотеку moxalib и документашку к ней: Библиотека Документашка Там есть исходники работы со сторожевиком, используя их написал такую прожку для управления: [root@fc-14 mmu]# cat wdt.c #include <stdio.h> #include <stdlib.h> #include <sys/ioctl.h> #include <fcntl.h> #include <unistd.h> #define IOCTL_SWATCHDOG_ENABLE 1 #define IOCTL_SWATCHDOG_DISABLE 2 #define IOCTL_SWATCHDOG_GET 3 #define IOCTL_SWATCHDOG_ACK 4 int wdt_open( const char* _t, unsigned _time ) { int fd = -1; fd = open (_t, O_RDWR ); if ( fd < 0 ) return -1; unsigned tt = _time*1000; if ( ioctl (fd, IOCTL_SWATCHDOG_ENABLE, &tt ) ) return -2; return fd; } void wdt_close(int fd) { ioctl(fd, IOCTL_SWATCHDOG_DISABLE, NULL); close(fd); } /* get the status of a watch dog timer Inputs: <fd> file descriptor respresenting the timer Outputs: <mode> the status <time> the timer Returns: 0 on success, failure otherwise */ int wdt_get_status(int fd, int *mode, unsigned long *time) { int ret; struct { int mode; unsigned long time; } nowset; ret = ioctl(fd, IOCTL_SWATCHDOG_GET, &nowset); *mode = nowset.mode; *time = nowset.time; return ret; } int wdt_refresh(int fd) { return ioctl(fd, IOCTL_SWATCHDOG_ACK, NULL); } int main ( int argc, char** argv ) { unsigned tt = 12; if(argc == 2 ) tt = atol (argv[1]); int wfd = open ("/dev/swtd", tt ); if ( argc == 3 ) return 0; int mode; unsigned long time; while ( wfd > 0 ) { wdt_get_status( wfd, &mode, &time ); printf( " mode=%d, time=%d\n", mode, time ); wdt_refresh ( wfd ); usleep( 50000 ); } } собрал запускаю, без параметров root@Moxa:/var/sd# ./wdt mode=0, time=30000 mode=0, time=30000 mode=0, time=30000 mode=0, time=30000 как видно таймаут установлен на 30 секунд, а я ставил на 12 -первая странность, прерываю программу, в конце специально нету метода закрытия сторожевого таймера, по прошествии минуты зверек не перезагружен если указать с двумя параметрами, wdt 1 1 например, то программа завершиться только открыв таймер и записав в него требуемый интервал. По логике, должны опять таки были перегрузиться, но этого не происходит. Общество, скажите что я делаю не так.

Да большое спасибо за ответ и сссылки. Действительно мой зверек там есть.

Нет все таки косяк был в описании структур, они были не выравненны на dword, а умный gcc - их ровнял. Запретил все гуд, и чтобы не поднимать тему насчет выравнивания отвечаю стразу: Да все ясно, когда в протокол обмена заложено выравнивание на уровне проектирования то все отлично, а когда нет... Вот нет, это мой случай - __attribute (( packet )) - gcc-ная нашка, помогла, конечно имеем тормоза, но протокол изменить никто не даст, да 60% idle - нормуль. А вообще на тему выравнивания устроил холивар на http://we.easyelectronics.ru/ARM/rabota-s-ne-vyravnennymi-strukturami-na-armm9.html А насчет mmu - на каком-то форуме прочел, что работа с не выравненными структурами на АРМ это заслуга mmu, удивился - решил спросить у общества. Гранд мерси за ответ. мир.

Ндя... видимо никто не пользовал watchdog в более-менее серьезных промышленных проектах... Админы: - дайте динамическую libmoxalib.so - кстати libmoxa.so - имхо, более корректное название для библиотеки.

Доброго времени суток, форумчане. В контроллере надо, поиметь работу с watchdog таймером. Контроллер построен на базе модульной скада, модули лежат в динамических библотеках(.so), а объектник в котором лежат методы для работы с таймером через moxa-API в архиве(.a) При сборке модуля таймера для скады проблем не возникает, а при запуске имеем ksa: relocation error: /var/sd/arm-ksa/lib/modules/libmoxa_Watchdog_1_0.so: undefined symbol: swtd_open Вопрос возможно ли слинковать статическую библиотеку как часть динамической? На сколько я понимаю нет. Видимо нужен объектник swtd.o, для линковки. P.S вот так собирается модуль moxa:Watchdog make clean; ksmake; make install make[1]: Вход в каталог `/home/boris/moxadev/ksa/moxa/Watchdog/src' rm -f WatchdogFactory.o WatchdogBase.o Watchdog.o libmoxa_Watchdog_1_0.so *.cc *.hh make[1]: Выход из каталога `/home/boris/moxadev/ksa/moxa/Watchdog/src' Using object specifications from /home/boris/moxadev/ksa/moxa/Watchdog/idl/Watchdog.xml make[1]: Вход в каталог `/home/boris/moxadev/ksa/moxa/Watchdog/src' arm-linux-g++ -fpic -I/usr/include/ksa -I/usr/include/ksa/modules -I/usr/include/ksa/modules/moxa -I./ -c WatchdogFactory.cc arm-linux-g++ -fpic -I/usr/include/ksa -I/usr/include/ksa/modules -I/usr/include/ksa/modules/moxa -I./ -c WatchdogBase.cc arm-linux-g++ -fpic -I/usr/include/ksa -I/usr/include/ksa/modules -I/usr/include/ksa/modules/moxa -I./ -c Watchdog.cpp arm-linux-gcc -shared -L /usr/lib/ksa/ -L /usr/lib/ksa/modules -lKSA -L. -lmoxalib WatchdogFactory.o WatchdogBase.o Watchdog.o -o libmoxa_Watchdog_1_0.so cp libmoxa_Watchdog_1_0.so /usr/lib/ksa/modules sudo mkdir -p /usr/include/ksa/modules/moxa sudo chmod a+w /usr/include/ksa/modules/moxa cp *.hpp /usr/include/ksa/modules/moxa make[1]: Выход из каталога `/home/boris/moxadev/ksa/moxa/Watchdog/src'