kovalchuk_i_v

У вас ядро 2.6.21? Если да, то там похоже есть глюк (или нюанс который я не понял): Добавлять самой последней стокой в /etc/rc свою программу не надо, она действительно не запускается. добавьте где-нибудь в середине, ближе к концу. у меня это выглядит примерно так: ........ ........ ........ #insmod /lib/modules/2.6.21-uc0/kernel/drivers/usb/gadget/g_file_storage.ko file=/dev/mmca1 LANG=ru_RU httpd & /bin/myprog </dev/mtrm1 >/dev/mtrm1 2>/dev/mtrm1 & # if user defined rc exists then execute it if [ -f /mnt/mmc/userrc ]; then /bin/sh /mnt/mmc/userrc fi

Вот измерительная схема.

Озадачили меня весы сделать, все хорошо, но только ползет в весах ноль. Никак не получается удачный алгоритм отслеживания дрейфа нуля придумать. Кому-нибудь приходилось программно компенсировать дрейф нуля? Подскажите методику!

У меня есть вопрос по работе геркона. Сделал датчик открытия двери на 3-х контактном герконе. Использую НЗ пару контактов. Первые несколько суток все работает. Затем начинаются ложные срабатываня. Т.е. контакты геркона кратковременно замыкаются, находясь в магнтном поле. Еще через насколько суток эти контакты замыкаются и на магнитное поле больше не реагируют. А еще через несколько суток геркон снова оживает, но ложные срабатывания происходят постоянно. В чем может быть проблема? Бракованный геркон? Может быть слишком сильное магнитное поле влияет на свойства геркона? Пробовал несколько герконов (правда брал их в одном месте).

Стоит задача протестировать микросхему NAND-флешь на серийно выпускаемом устройстве. Устройство работает на ucLinux, флеш NAND512W3AOAN6, с файловой системой YAFFS. Столкнулся с тем, что при работе, некоторые микросхемы полностью покрываются BAD-секторами. Сейчас тестирую таким образом: 1) создаётся файл. 2) в файл записывается 1МБ данных. 3) в позицию P1 файла пишется S1, байт. 4) из позиции P2 файла читается S2, байт. 5) goto 3. Числа P1, P2, S1, S2 - случайные. Попалась такая микросхема, которая при работе покрывается bad-секторами, а при тестировании - нет. В чем может быть мой просчёт? Как построить алгоритм теста, чтобы он максимально эффективно выявлял проблемные NAND-флешь?

м.б. я не ясно выразил свой вопрос, попробую переформулировать. Если нужно записать в NAND-флеш готовый образ ФС YAFFS, то как обходить bad-блоки, которые могут попасться?

Система - ucLinux, проц lpc2468. Вот хочу использовать в качестве корневой ФС YAFFS. Но есть проблема: создам я образ ФС, и запишу в соответствующий раздел nand-флеш на устройстве. А если на этом разделе bad-блоки окажутся, как их обходить?

Ситуация немного прояснилась. В модуле "8250.c" для обработки событий контроллера UART, используются 2 функции: 1) serial8250_interrupt - обработчик прерываний. 2) serial8250_backup_timeout - реализует опрос контроллера UART, дополнительно к прерываниям. Опрос производится раз в 200мС. Время опроса соответствует времени задержки при чтении из устройства. При увеличении частоты опроса тормоза исчезают. Пока мне не понятно зачем вообще нужен опрос, если используются прерывания, и почему он оказался так критичен. Есть у кого мысли?

Обратил внимание что на ядре 2.6.21 медленно работает ttyS2, ttyS3 (остальные не проверял, возможно тоже тормозят) Это проявляется при работе с устройством в режиме запрос-ответ: время, между посылкой команды и приемом ответа, на порядок выше, чем в было в ядре 2.6.11. Кто-нибудь сталкивался или знает как решить эту проблему?

что значит "переход"? Были данные в jffs, и надо чтобы они стали в ubifs на том-же носителе? Или же ваше устройство использовало jffs, а теперь вы хотите использовать ubifs? Если вариант 2 то вот вам "последовательность действий": 1. добавить в ядро поддержку ubifs 2. создать на устройстве файловую систему. 3. примонтировать её. вот и все.

Ну какие примеры? Открываешь устройство (ф-ция open("/dev/i2cX",...)), пишешь/читаешь, закрываешь.

Руслан, для того чтобы узнать как настраивается i2c нужно прочитать несколько страниц из user manual для lpc2468, уверяю тебя работа с i2c не сложнее работы uart. После понимания работы контроллера i2c, имеет смысл ознакомится с исходным кодом драйвера i2c, практически там уже все написано, просто добавишь свои устройства.

Flow control добавил, однако ничего не изменилось... Пакеты попрежнему доходят не все. Похоже что проблемы начинаются при посылке фреймов длинной от 512-1024 байт.

Похоже что выключен. Теперь буду думать как включить... Спасибо.

Уважаемые коллеги, а не у кого не возникает проблем с работой ethernet на ядре 2.6.11? Пишу данные в сокет со стороны lpc2468, а вот доходят они не всегда. Причем чем больше обьем данных посылаю в send(fd,...) тем хуже они доходят. При приеме таких проблем не наблюдаю. Кто-либо сталкивался с подобным?

Имеется два потока. поток 1: запускает поток 2, открывает FIFO (Read only), читает FIFO, закрывает FIFO. поток 2: открывает FIFO (Write only), пишет в FIFO, закрывает FIFO. Работа происходит в блокирующем режиме. Проблема возникает при обмене маленьким обьемом данных. В этом случае может возникнуть ситуация, когда поток1 блокируется на открытии FIFO, а поток 2 быстро выполняет всю работу и завершается, при этом поток 1 остается заблокированым на открытии. Как побороть?

Booting ARM Linux: http://www.simtec.co.uk/products/SWLINUX/f....html#ATAG_CORE

Проблема проявлась через несколько часов работы. Закончилась тем, что основная масса блоков помечается как bad (подозреваю, что не пометились только блоки которые не пытались перезаписывать). После стирания всей флеш - ФС снова нормально работает (пока еще).

Сегодня заметил, что после интенсивной работы с файловой системой появилась несколько десятков битых блоков. Использую NAND512W3A0AN6, ФС yaffs, ОС uClinux. Подскажите, люди добрые, куда копать.

Вот пытаюсь выделить большой кусок памяти, с помощью malloc, а больше 4МБайт не выделяется. Как побороть?

Пишите красивый драйвер - и красиво обращайтесь

Отец рассказывал, что в после военные годы был у них в деревне радио-кружок. Вояли там ребята детекторный приемник. Диод делели сами: плавили серу и свинец (кажется), а потом в получившуюся смесь иголкой тыкали, пока нужные точки не находили....

Спасибо за Ethernet, это как раз то что меня интересовало.

Я не пользуюсь uboot, у меня свой загрузчик. Считаю, что баг вызван ошибкой в драйвере. Патчи мне не известны. Повторю немного подробнее свое решение: Поскольку ошибка возникает, когда при загрузке ОС, внешние устройсва посылаю данные в UART платы, можно просто отключить пины RX и TX в загрузчике, перед стартом ОС. Сделать это можно записью "0" в соответствующие биты регистра PINSEL. А перед открытием порта снова разрешите эти пины либо в своей программе, либо в драйвере.

Решается очень просто: перед загрузкой ОС конфигурите пины RX,TX (можно только RX) как порты ввода-вывода. А перед открытием устройства - снова делаете их RX и TX. Дел там на 4 строчки кода. Может быть посмотрите, как ведет себя драйвер Ethernet?