MuadDib

Это особенность процессора ARM. При попытке чтения 32-битного слова, не выровненного по адресу, кратному 4, вы получаете результат, отличающийся от ожидаемого. Процессор читает слово, выровненное по адресу, кратному 4, но потом "перекручивает" его разряды так, что запрошенный адрес оказывается в младших разрядах регистра. В вашем случае мы имеем следующую последовательность байтов (первый байт последовательности имеет адрес, кратный 4): 0x00 0x00 0x01 0x00 0x02 0x00 0x03 0x00 Если прочитать первые 4 байта как половину слова и как целое 32-битное слово, результат будет идентичным на обоих платформах: 0x0000 == 0 и 0x00010000 == 65536 соответственно. А теперь читаем невыровненные данные. Платформа x86 пофигистически относится к нарушению выравнивания. Данные читаются с запрошенных адресов. Операция выполняется медленнее, но обычно никто не обращает на это внимание. Читается последовательность байтов 0x01 0x00 0x02 0x00, и в регистре оказывается 0x20001 == 131073 Платформа ARM показывает свой нрав. Она читает _выровненную_ последовательность байтов, включающую запрошенный адрес: 0x00 0x00 0x01 0x00 (т.е. то же число, что и при чтении предыдущего выровненного значения - 0x00010000). После этого искомый адрес выводится в младший разряд слова с помощью процесса, аналогичного операции rotate: 0x00010000 => 0x00000001 == 1). Более иллюстративен пример, когда вы пытаетесь читать на ARMе невыровненное слово, начинающееся с тройки. По той же схеме получаем: Исходные байты: 0x02 0x00 0x03 0x00 Прочитали число: 0x00030002 Перекрутили: 0x00020003 == 131075 - то, что у вас получилось Мораль: выражения типа вашего "ptr32 = (uint32_t*)&ar;" с последующим dereference не зря объявлены undefined behavior. Если вам реально нужно производить такие манипуляции с данными, ваш код должен учитывать особенности вашей платформы (т.е. особенности ARM). Операционная система тут значения не имеет. IMHO, оптимальное решение в вашем случае - хранить все данные выровненными по требованию платформы. Если же речь идет о "плотно упакованном" бинарном протоколе обмена, имеет смысл использовать совет lysenkov'а.

Вы уверены, что кабель у вас с экраном? У экранированных кабелей обозначение идет КВВГЭнг, к тому же на схеме экран не показан. Может, его вообще там нет, и, соответственно, жилы собирают на себя все подряд аки антенна? Доки по Trabtech я смотрел здесь: http://stevenengineering.com/tech_support/PDFs/67PT.pdf. На первый взгляд, схема рекомендациям (fig. 5) соответствует.

Сложно ответить что-то конкретное - информации у меня недостаточно. Прошу вас привести схему контроллерного шкафа (подключение расходомера, питание, заземление, грозозащита). Возможно, по ней я смогу что-то предложить. Схема, рекомендованная электронщиками, ИМХО, больше поможет при борьбе с обычными наводками промышленной частоты, а также спасает от наличия разности потенциалов между разными источниками питания по концам линии. Последнее для вас не актуально (поскольку питание идёт с одной точки), а наличие дополнительной земли в случае с грозовой наводкой в некоторых ситуациях может даже навредить. На мой взгляд, в первую очередь стоит руководствоваться схемами от Phoenix Contact, учитывая, разумеется, и схему, приведенную в посте Komantsev.

Причин могут быть десятки. Наиболее вероятная - скорость нарастания фронта грозового импульса была выше той, на которую рассчитана ваша грозозащита. На ситуацию влияет также способ огранизации заземления, параметры заземляющего устройства и многие другие факторы. ИМХО, в таких случаях проще прокинуть оптику. В итоге может получиться дешевле чем в случае плясок с защитой от перенапряжений.

Уже какое-то время UC-7112-LX Plus работает в распределенной системе сбора данных. Наше приложение опрашивает подключенное по интерфейсу ethernet устройство и периодически отправляет данные на веб-сервер. Для выхода в интернет используется gsm-модем, подключенный к последовательному порту. Для установки интернет-соединения используется ppp-daemon (pppd), запускаемый из скрипта при старте системы. Уже несколько раз случалось, что ppp-соединение обрывается следующим образом. В лог демона помещается такая информация: Terminating on signal 15. Connection terminated. Connect time 2819.8 minutes. Sent 984661 bytes, received 895633 bytes. После этого связь с Интернет пропадает, но, по информации ifconfig, соединение ppp0 остается активным. При этом, ping на произвольные узлы не дает отклика, а наше приложение не может установить обмен с сервером. Причем, судя по всему, connect() отрабатывает нормально (!), но данные по write() уходят в никуда, и прога диагностирует таймаут по read(), не дождавшись отклик сервера. Непонятно, откуда может возникнуть сигнал 15 (SIGTERM). Мое приложение и скрипты никаких сигналов не создают. Ситуация лечится перезагрузкой контроллера и, соответственно, перезапуском ppp-соединения. Сталкивался ли кто-нибудь с чем-то подобным? Откуда может взяться SIGTERM в данной ситуации? Есть ли какие-то рекомендации для устранения такой ситуации?

Присоединяюсь к просьбе о пересмотре данного момента в прошивке девайса. Наличие висящего в воздухе симлинка (в случае неудачи при монтировании SD-карты) ничего не дает, помимо введения пользователя в заблуждение. Более того, опытным путем удалось выяснить, что упомянутый в данном топике скрипт sdpnp пытается монтировать файловую систему карты памяти с устройства /dev/mmc1, а в моем случае это удается сделать только командой mount /dev/mmc /mnt/sd. Файл мегаскрипта находится на read only - файловой системе. Таким образом, пользователю предлагается методом тыка определить, какое же устройство соотносится с SD картой, написать другой скрипт монтирования карточки и вызвать его из соответствующего скрипта в /etc/init.d, заменив вызов sdpnp. Использование аббревиатуры pnp в данном контексте напоминает тонкое издевательство.

На самом деле данное конкретное предупреждение связано со строкой формата vfprintf. Выводится значение типа size_t. Код компилируется под 2 платформы. На uClinux size_t является unsigned long, и в строке должно быть %ld, на Linux - unsigned int, соответственно компилятор ожидает %d. Ситуация потенциально опасна, если sizeof(long) != sizeof(int), что в моем случае не так. Особенно поганая ситуация может получиться, если длина различается, а компилятор использует стек для передачи параметров при вызове функции (в нашем случае для этого задействуются регистры). Тогда в случае некорректного вызова можно поиметь нарушение стека. В моем случае для избавления от warning'ов можно было выкинуть нафиг printf-подобные функции и использовать <iostream>. Однако, поскольку текущий проект - это наш первый проект на uClinux, я изначально решил не рисковать и не использовать громоздкую потоковую библиотеку C++, тем более что семейство printf используется в основном для лога ошибок. Поэтому данную конкретную ситуацию я исправил с помощью define-константы, задающей нужный формат вывода size_t. Но вопрос, разумеется, не в предупреждении, а в том, как заставить компилятор давать нормальный вывод.

Использую сабж для разработки под UC-7112-LX Plus. Версия 1.3 - последняя, скачана с англоязычного сайта производителя. Почему-то сообщения, выводимые компилятором выглядят вот так: dscollection.cpp:320: instantiated from here ../base/fifoconnection.h:353: предупреждение: long int format, unsigned int arg (arg 5) То есть имеем эдакий "пераццкий" перевод а-ля Промт: слово warning заменено на русский эквивалент, все остальное остается по-прежнему. Предположительно, это связано с какими-то настройками ОС (Ubuntu 10.10). К сожалению, парсер компиляторного вывода Eclipse не знает ридну мову и маркирует такое предупреждение как ошибку. Можно как-нибудь (настройками командной строки компилятора или еще как-нибудь) отключить эту эрзац-локализацию?

Я недавно получил возможность поработать с 7112 Plus, поэтому теперь могу ответить на данный вопрос. Упомянутая мной в соседнем топике библиотека без проблем компилируется под plus-версию контроллера. Даже менять имя устройства в функции открытия таймера не нужно (в отличие от случая с uClinux вариантом). Библиотека работает так как и ожидается. Попытаюсь объяснить, что у вас не так 1. Вы переписали функцию wdt_open(), но вызываете не её а стандартную open(). Данная функция не делает запуск таймера вызовом ioctl, следовательно таймер просто не работает. 2. Вы работаете не непосредственно с таймером, а с его драйвером. Когда файловый дескриптор закрывается (а именно это происходит при закрытии приложения, вне зависимости от наличия вызова close() в программе), драйвер, очевидно, прекращает требовать сброс таймера со стороны пользовательского приложения. Судя по тому, что написано в доках, сторожевой таймер работает постоянно и сбрасывается драйвером. Но если пользовательское приложение вызывает wdt_open(), то привилегия сброса передается приложению. Когда приложение так или иначе закрывает дескриптор, операционная система возвращается к старому способу работы с таймером. Во всяком случае, эксперимент это подтверждает. Мне самому такая ситуация не нравится - по идее, при аварийном завершении приложения на необслуживаемой машине должна произойти перезагрузка по сторожевому таймеру, но ее просто не будет. Но что есть, то есть.

Я могу ошибаться, но я не вижу, каким боком mmu относится к делу. Размещение членов структур определяется компилятором, а решения по поводу этого размещения обусловлены в основном требованиями платформы к выравниванию данных. Наличие/отсутствие mmu определяет возможности платформы по гибкому управлению памятью, но никак не выравнивание. Важным моментом, помимо выравнивания и упаковки структур, является размер базовых типов данных. На одной платформе int может быть 4 байта, на другой - 2 байта и т.п. Судя по тому, что лишние 2 байта у вас появились только в одном месте, вполне возможно, что имеет место несоответствие размеров типа данных на разных платформах/компиляторах. В общем, опубликуйте определение структуры, будем посмотреть ИМХО, насиловать ARM-овский компилятор, допуская нарушение выравнивания данных, себе дороже. ARM при работе с невыровненными данными уродует их как бог черепаху (в отличие от x86). Хорошо если в компиляторе этот момент проработан нормально. Тогда вы поимеете только существенное снижение производительности при работе с такими данными. А если нет? Отловить возможные глюки в таком случае будет достаточно сложно. Особенно неприятные моменты могут возникнуть, если в программе используется многопоточность...

Как раз недавно я боролся с фирменной реализацией функций по работе с watchdog из библиотеки moxalib для моего контроллера. Контроллер у меня явно не такой как у вас (UX-7112-LX, uClinux, не поддерживает .so). Обращался непосредственно в поддержку Moxa. Представитель фирмы поделился следующими ссылками: Библиотека Документация по ней Не знаю, какой у Вас контроллер, но судя по makefile, данная библиотека поддерживает множество моделей, вероятно ваш контроллер там тоже есть. Библиотека поставляется в виде исходного кода, так что можете слинковать его как угодно душе. Единственная проблема - библиотека потребовала обработки напильником Во-первых, функция запуска таймера всегда возвращала ошибку, так как использовала неверное имя устройства (было "/dev/swtd", а надо было "/dev/watchdog"). Во-вторых, в makefile не были прописаны необходимые параметры компилятора, в результате библиотека была в принципе неработоспособна. Впрочем, возможно, с вашим контроллером все будет работать сразу.

Доброго Контроллер UC-7112-LX (НЕ "плюс"). Ниже приведены версии, выдаваемые по разным компонентам системы: cat /etc/version Moxa/UC7112 Version 2.3 -- 五 7月 23 15:51:55 CST 2010 # kversion The UC-7112 kernel version is 2.3 # fsversion The firmware version is 2.3 # uname -a Linux moxa.com.tw 2.6.19-uc1MoXaRt #2 Fri Jul 23 15:51:26 CST 2010 armv4tl ARM

Мы хотим использовать SD-карту на указанном в сабже контроллере для накопления данных в случае обрыва связи с сервером. Карта установлена и определяется драйвером следующим образом: mmc0: new SD card at address 0002 mmcblk0: mmc0:0002 00000 976896KiB mmcblk0: unknown partition table Стандартный скрипт, предоставленный производителем (/bin/pnp mount), почему-то пытается смонтировать mmc1: #!/bin/sh if [ "$1" = "mount" ]; then mount /dev/mmc1 /mnt/sd else umount /mnt/sd fi Поэтому я сделал следующее: 1. Отформатировал карту в ext3 ( mke2fs -j /dev/mmcblk0 ); 2. Откорректировал /etc/rc - закомментил вызов скрипта pnp и добавил 2 строчки: #-->sd driver for /dev/mmc1 insmod /lib/modules/2.6.19-uc1MoXaRt/kernel/drivers/mmc/core/mmc_core.ko insmod /lib/modules/2.6.19-uc1MoXaRt/kernel/drivers/mmc/card/mmc_block.ko insmod /lib/modules/2.6.19-uc1MoXaRt/kernel/drivers/mmc/host/moxasd.ko # to mount SD storage if SD is plugined #pnp mount echo Mounting SD card mount /dev/mmcblk0 /mnt/sd Результат: флешка отформатировалась и монтируется (файловая система работоспособна), но с одной оговоркой: монтирование происходит только после команды reboot. После включения питания флешка не определяется. Вот что выдает в консоль контроллер в обоих случаях (привожу только конец вывода, после motd): Включение питания: Clock: old time 1970/01/01 - 00:00:05 GMT Clock: new time 2011/11/03 - 01:59:32 GMT MOXA MU860 UART Device Driver version 2.0 Tty devices major number = 30 Driver 'mmcblk' needs updating - please use bus_type methods Moxa CPU SD/MMC Device Driver V1.1 initialize Modules load OK. Mounting SD card Attempt to mount non-MTD device "/dev/mmcblk0" as JFFS2 mount: Mounting /dev/mmcblk0 on /mnt/sd failed: Invalid argument mmc0: new SD card at address 0002 mmcblk0: mmc0:0002 00000 976896KiB mmcblk0: unknown partition table Attempt to mount non-MTD device "/dev/mmc1" as JFFS2 Перезагрузка через reboot: Clock: old time 1970/01/01 - 00:00:05 GMT Clock: new time 2011/11/03 - 02:02:50 GMT MOXA MU860 UART Device Driver version 2.0 Tty devices major number = 30 Driver 'mmcblk' needs updating - please use bus_type methods Moxa CPU SD/MMC Device Driver V1.1 initialize Modules load OK. mmc0: new SD card at address 0002 mmcblk0: mmc0:0002 00000 976896KiB mmcblk0:Mounti unknown partition table ng SD card Attempt to mount non-MTD device "/dev/mmc1" as JFFS2 kjournald starting. Commit interval 5 seconds EXT3 FS on mmcblk0, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. По-видимому, отличие в том, что при "холодном старте" строка mount отрабатывает до того, как драйвер увидел карточку и выдает ошибку, а после reboot драйвер "просыпается" раньше. На данный момент пришлось прибегнуть к "костылям" - добавить sleep перед вызовом mount в /etc/rc. Итак, вопросы: 1. Как избавиться от sleep, т.е. как надо _правильно_ монтировать карточку в данном контроллере? 2. Смущает строка "Driver 'mmcblk' needs updating - please use bus_type methods", выводимая загрузчиком ОС вне зависимости от наличия SD-карточки. Если надо обновлять драйвер, где его брать и как выполнить обновление? 3. Почему стандартный скрипт pnp обращается к mmc1, в то время как карта видится как mmcblk0? 4. Система при вызове mount пишет, что пытается монтировать устройство "as JFFS2". Может быть, использование ext3 в корне неверно, и мне следовало изначально форматнуть карточку в JFFS2? Если да, то как это сделать? 5. Откуда берется строка "Attempt to mount non-MTD device "/dev/mmc1" as JFFS2" в выводе при загрузки ОС? Если устройство чтения SD-карт - это /dev/mmcblk0, то что такое mmc1? Вообще, подход фирмы Moxa к документированию удивляет... В мануале есть отдельный раздел, описывающий преимущества JFFS2 (со ссылками на сайты девелоперов, ага), но нет ни слова о том как форматнуть флешку в эту файловую систему, ни даже о том, как соотносятся устройства mmc* с железом... Контроллер создан для промышленного применения, а ощущение как от общения с неким полулюбительским устройством, созданным командой борцов за свободу информации

Этот метод сработал. Спасибо огромное!

/etc/localtime в изначальной конфигурации системы не существует. Файл был скопирован на UC-7112 в соответствии с рекомендациями, но система на это никак не отреагировала. Видимо, приведенные вами рекомендации относятся к полноценному варианту Linux (не uc). На форуме ucLinux мне уже попадалась информация, что система не поддерживает zoneinfo. В данной ветке рекомендуют использовать etc/profile для установки TZ, но, как я уже писал выше, это влияет только на telnet-сеанс. Была надежда, что есть более универсальное решение, но, видимо, ничего больше сделать нельзя. Обидно. Придется устанавливать аппаратные часы по Гринвичу. Единственное, что утешает - отмененный перевод на зимнее время. Хоть немного меньше мороки с пересчетом :S