boris_r_v

Решение вопроса нашлось по этому адресу: http://www.cyberforum.ru/cpp-beginners/thread69549.html Суть - сказать, что не надо выравнивать структуру, правда это, как я понял, не будет работать на ядрах без mmu, но это уже издержки того, что приемник ожидает не выравненную структуру данных, и в моем случае это наложенное ограничение. Если я не прав насчет того, что не будет работать на адрах без mmu - прошу меня поправить, ибо есть мнение, что на девайсах без mmu - это тоже надо будет запускать. Жду конструктивной критики.

Суть проблемы: Есть некая скада которая опрашивает устройства по rs485 и передает данные в сеть по мульткасту До сего времени работа только на x86 контроллерах. После сборки и установки этой же скады, без изменения исходного кода, на контроллер UC-7112-Plus, пакеты udp в которых приходят данные отличаются от пакетам от х86 контроллеров, и не обрабатываются корректно на АРМ. пакет от x86: - good rec tcpdump host maket_main and port 14350 -nX -s 650 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 650 bytes 10:18:17.627340 IP 192.168.0.56.33079 > 224.1.1.1.14350: UDP, length 74 0x0000: 4500 0066 0000 4000 0211 d6a4 c0a8 0038 E..f..@........8 0x0010: e001 0101 8137 380e 0052 af5e 0000 0000 .....78..R.^.... 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 2000 0000 0000 0000 ................ 0x0040: f401 0000 0100 0143 4455 335f 5069 745f .......CDU3_Pit_ 0x0050: 4400 0800 1000 3f00 0700 0000 0000 0000 D.....?......... 0x0060: 0000 0000 0000 пакет от arm: - not good rec tcpdump host moxa-uc and port 14350 -nX -s 650 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 650 bytes 10:21:18.846748 IP 192.168.0.53.1025 > 224.1.1.1.14350: UDP, length 76 0x0000: 4500 0068 0470 4000 0211 d235 c0a8 0035 E..h.p@....5...5 0x0010: e001 0101 0401 380e 0054 2c94 0000 0000 ......8..T,..... 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 2000 0000 0000 ................ 0x0040: 0000 f401 0000 0100 0143 4455 335f 5069 .........CDU3_Pi 0x0050: 745f 4400 0800 1000 3f00 0700 0000 0000 t_D.....?....... 0x0060: 0000 0000 0000 0000 смотрим в строчку 0х0040: f401 0000 0100 0143 - так должно быть а имеем: 0000 f401 0000 0100 0143 - соответвенно данные смещаются, 4455 335f 5069 - это уже полезные данные Вопрос: подскажите в каком месте может быть ошибка? Либо у меня данные не выровнены как то по особому для АРМ либо разное формирование заголовков пакета.

Разобрался. python конечно же пользуется из поставки машины куда слит tool-chain. Нужно еще была libxml2 - ее собрал в тулчайне: cd libxml-2.6.27 ./configure --host=arm-linux-gnu --target=arm-linux CC=arm-linux-gccAR=arm-linux-ar LD=arm-linux-ld RANLIB=arm-linux-ranlib --prefix=/usr/local/arm-linux/libxml2 make make install Стыдно, что сразу не пришло на ум, ну да ладно за то экспу получил. Тема закрыта.

Добрый день. Не дождался от вас ответа, начал искать другие пути решения свой проблемы. из первого что пришла на ум использовать qemu, для эмуляции АРМ, там собрать свой софт, и перетащить на контроллер. Собрал претащил на контроллер - конечно жесразу поимел: ksa: /lib/libstdc++.so.6: version `CXXABI_1.3' not found (required by ksa) ksa: /lib/libstdc++.so.6: version `GLIBCXX_3.4' not found (required by ksa) ksa: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /var/sd/KSA/lib/libxml2.so.2) ksa: /lib/libc.so.6: version `GLIBC_2.3.2' not found (required by /var/sd/KSA/lib/libxml2.so.2) - не беда берем нужные, до самых "статик линкед" библиотеки перетаскиваем на контроллер, запускаем снова и имем уже другую ошибку: Inconsistency detected by ld.so: dynamic-link.h: 62: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed! спросил у гугла, что за сабж, - вернулся опять на ваш форум ветка посвященная шифрованию http://www.moxa.ru/forum/index.php?showtopic=1189 но в моем случае шифрование не причем, хотелось бы у вас узнать из-за чего еще может появляться эта ошибка и как ее побороть. p.s. и еще вопрос: а чего собственно в прошивке контроллера библиотеки такие старые стоят-то, да и gcc-3.x.x - уже как то устарел и морально и технически.

Доброго времени суток. Вопрос больше к разработчикам toolchain. Суть в следующем есть самописный контроллер который работает с самопальным девайсами по rs485. Так вот при компиляции модулей контроллера пользуется питон для генерации стаба и скелетона модуля(хоть терминология корбовская, ее нет, но суть та же), когда все собрано питон больше не нужен. А вопрос в следующем как мне поиметь питон в тоолчайн, чтоб модули собрать.

День добрый. Вопрос в следующем, - есть NPort работающий в режиме удаленного tty(под Linux), через него работает опрос пары устройств. Заказчики ребята не бедные, и устройство для них очень важно, и захотели иметь на те устройства резервированную линию связи. выглядит примернотак: SCADA comp<->ethernet<->DSL-modem 1<->copper twisted pair<->DSP-modem 2<->ethernet<->Moxa NPort<->rs-485<->device, дыблируется все начиная c DSP-modem 1 по Moxa NPort Работать это должно так: пропадает связь по основному каналу связи, инициализирую резервный канал связи (закрываю мертвый tty, открываю новый живой tty) - это в теории и так думали маляры. Для реализации этого переключения необходимо событие что порт отпал, при использовании например usb2serial такое событие есть, а вот linux драйвер для NPort такого события не сгенерил, по ответам драйвера получается что устройство перестало отвечать на запросы. Собственно два вопроса: 1. Так и должно быть? 2. Если так быть и должно то какие пути есть для реализации данной схемы резервирования?