lysenkov

#include <time.h> #include <errno.h> #include <stdio.h> #include <string.h> #define CLOCK_MONOTONIC 1 int main() { struct timespec t1; if(clock_gettime(CLOCK_MONOTONIC, &t1) < 0) printf("clock_gettime() error: %s\n", strerror(errno)); else printf("clock_gettime() ok\n"); return 0; } Результат выполнения - clock_gettime() error: Invalid argument Библиотеки стоковой прошивки собраны без определения CLOCK_MONOTONIC. Если мы его определяем сами, то в библиотеках поддержка не появляется. Резюмирую: I. в стоковой прошивке существует 2 проблемы: 1) компилятор неверно формирует команды сопроцессора из-за чего портится стек. Проблему можно обойти использованием эмулятора сопроцессора (soft-float). 2) библиотеки и, возможно, ядро собраны без определения CLOCK_MONOTONIC, из-за чего невозможно (или я не знаю как) измерять интервалы времени с высокой разрешающей способностью; II. в прошивке 1.2.10 обе эти проблемы решены, но появилась другая - ужасно медленно работают операции с плавающей точкой, выполняет их "железный" сопроцессор. Проблему можно было бы обойти, используя soft-float, но в прошивке 1.2.10 и в соответствующем тулчейне библиотеки soft-float напрочь отсутствуют. Я вижу два пути обхода/решения проблем: I. обход: сделать прошивку на основе 1.2.10, но включить в нее и в соотв. тулчейн библиотеки soft-float и даже собрать тулчейн, чтобы он использовал soft-float по умолчанию; II. решение: заставить таки работать железный математический сопроцессор с нормальной производительностью. Зачем-то он встроен в W406? Может (должен) он умеет работать быстрее эмуляции, а не 10 раз медленнее, как сейчас. P.S. Готов ответить на Ваши дополнительные вопросы, если они будут. P.P.S. тут лежит компилятор http://arm.cirrus.com/files/tools/arm-linux-gcc-4.1.1-920t.tar.bz2, который использует математический сопроцессор, не имеет ошибки, приводящей к порче стека при использовании сопроцессора и в котором есть CLOCK_MONOTONIC Только библиотеки его приходится подпихивать. Тестовая программа из первого сообщения выполняется за 4.04 сек.

Здравствуйте! Я уже почти согласен использовать soft-float, т. к. он действительно в разы быстрее работает, но в стоковой прошивке отсутствует поддержка CLOCK_MONOTONIC и определение его "вручную" никак не добавляет его поддержки в библиотеках - при его использовании функция clock_gettime() возвращает ошибку. К сожалению, для измерения интервалов времени в высокой разрешающей способностью я замены найти не смог. Прошивка на ftp есть уже 1.2.12, только что в ней изменилось - неизвестно...

Опять возвращаемся к истокам, т.е. использованию стоковой прошивки и неиспользованию арифметического сопроцессора для обхода этой проблемы: http://old.moxa.ru/f...mentation-fault ? А хотелось заставить работать сопроцессор быстро и без глюков...

Здравствуйте! Есть ли новости по этой теме?

Другой компьютер: OWEN ПЛК323 (процессор производителя Atmel) Тулчейн: arm-linux_3.1.2_Build_13082610.sh Прошивка: Свежее у меня нет...

Работает, спасибо!

Спасибо! Есть мысль: у компилятора есть всякие разные ключи :-) Компилятор понимает -mcpu=ep9312 -mfpu=maverick Эти опции, по идее, должны заставить компилятор сгенерить код, максимально подходящий под процессор и сопроцессор W406. Проблема в том, что все библиотеки скомпилированы без этих ключей и линкер, естественно, отказывается это собирать...

Спасибо, получил. Завтра буду пробовать...

Выяснил, что виной падения производительности являются операции с плавающей точкой. Если оставить только целочисленные вычисления, то процессоры идут "ноздря в ноздрю" Возникает следующий вопрос: почему soft-float сильно обгоняет "железный" математический сопроцессор? Прошивка не стоковая В стоковой проблема: http://www.moxa.ru/f...entation-fault/

Здравствуйте! Попал мне в руки другой пром. контроллер, похожий по аппаратным возможностям на W406-LX. Вот его процессор: А вот процессор MOXA W406: Как видно, процессоры очень похожи, как минимум у них одинаковое ядро. Тактовые частоты тоже одинаковые. Более того, у другого контроллера нет арифметического сопроцессора и медленнее память. Берем простую программу (можно сильно не изучать - простейшая числодробилка): #include <stdio.h> #include <time.h> #include <malloc.h> #include <string.h> int func(double* k) { *k -= 11234.32; return *k; } int main() { int i, j, n, m, z=0; long long l1, l2; double dt; struct timespec t1, t2; clock_gettime(CLOCK_MONOTONIC, &t1); for(i=0; i<1000; i++) for(j=0; j<1000; j++) { l1 = i*j; l2 = l1%(i+1); dt = l2+j; n = dt+i*(l2-123); m = n/12; l1 = func(&dt); z += l1-m; } clock_gettime(CLOCK_MONOTONIC, &t2); l1 = ((long long)t1.tv_sec)*1000+t1.tv_nsec/1000000; l2 = ((long long)t2.tv_sec)*1000+t2.tv_nsec/1000000; dt = l2-l1; printf("dt=%.3f sec, z=%d\n", dt/1000, z); return 0; } компилируем и запускаем. на W406-LX время выполнения ~30 секунд. На другом контроллере ~5,4 секунд. Различные ключи оптимизации у компилятора пробовал, разница все равно огромная. Версия gcc для W406 - 4.4.2, для другого контроллера - 4.3.2 Тесты я начал проводить после того, как заметил большую разницу в скорости работы прикладной программы. Вопрос: почему такая огромная разница в производительности?

Здравствуйте! Тоже простите за столь долгое раздумье... Реле используется ABB модель CR-P024DC2, сопротивление обмотки постоянному току 1400 Ом, параллельно обмотке включен модуль CR-P/M-42V, который представляет из себя защитный диод, включенный обратной полярностью параллельно обмотке реле и цепочку из токоограничительного резистора и индикаторного светодиода в прямой полярности. Схема включения стандартная по документации: контакт GND MOXA на колодке входов/выходов подключен к "-" источника питания, DO0 - к обмотке реле, "+" питания к другому выводу обмотки реле. Алгоритм лишнего включения реле все-таки немного другой. При выключенном реле и перезагрузке W406 реле включается на несколько секунд, затем выключатся. Я эту проблему "обошел" другими путями, поэтому на данный момент она не сильно актуальна, но в будущем хотелось бы какого-то ее решения...

Тоже интересует. Заранее спасибо!

Суда по всему внутренняя флеш болеет? А какова статистика отказов встраиваемых компьютеров? Мне особенно интересно по малышам, вроде W315, UC-7xxx на risc-процах. Например, в смартфонах бэд блоки во встроенной флеши - ситуация абсолютно рядовая.

Последовательность определенная. От программ никак не зависит. На выход DO0 подключено реле - обмотка запитана от того же источника питания, что и W406. Параллельно обмотке реле включен защитный диод и индикаторный светодиод для визуального контроля, поэтому наблюдать удобно. При подаче питания, ровно как и при перезагрузке случается следующая последовательность: 1. Реле включается на 2-3 сек. 2. Реле выключается на 8-10 секунд.3. Реле включается. Временные интервалы приблизительные, с секундомером не стоял. Реле остается включенным - это такой логический ноль у MOXA Далее программой выход управляется абсолютно нормально в т.ч. может быть восстановлен в предыдущее состояние. Но после снятия/подачи питания или при перезагрузке вне зависимости от текущего состояния выхода повторяется алгоритм 1. 2. 3. В идеале, перезагрузка не должна влиять на текущее состояние выхода - вдруг перезагрузка случилась по wathdog'у или просто пора операционку презагрузить? (Ибо uptime встроенного линукса по любому меньше MTBF и прикладухи обычно грешны) ) Переподача питания - пусть встанет в определенное состояние и не дергается, а в идеале возвращать предыдущее состояние. Моя ситуация - реле управляет запуском дизель-генератора. ,Он, собака, стартует за 1-2 секунды, а потом 5 минут минимум работает (турбо-таймер). Пропадание питания на W406 в моем случае почти не реально, а вот перезагрузка... Простите за много букв.

Здравствуйте! При перезагрузке W406-LX несколько раз передергиваются дискретные выходы. Если они используются для управления чем-либо - понятно, что происходит. Как устранить этот эффект? Firmware 1.2.10