Есть продвижения на этом фронте? Верим и ждём.

скажем так...драйвер кое-какой есть... но нету заинтересованности в дальнейшем...

То что нет заинтересованности, очень удивляет. У нас работают несколько экземпляров E14-440. Устройство хорошее, при выборе решающим обстоятельством было наличие хоть какой-то поддержки Linux. Правда пришлось повозиться над доработкой драйвера, но это проще, чем делать с нуля. Этот положительный опыт относится к Linux 2.4.x.

Недавно попробовали собрать драйвер под 2.6.x. Спасибо авторам полезных советов, которые промелькнули на этом форуме. Почти нормально заработало, надеюсь до конца доведем.

Хотелось бы, чтобы заявленное отсутствие заинтересованности не вылилось в официальный отказ LCard от Linux. Как только позволит время, постараюсь изложить в этом форуме опыт работы с Linux+LCard. Надеюсь, это поможет разработчикам.

PS. Наш опыт отнсится только к E14-440. Других изделий LCard у нас нет.

Насчет Linux.
Есть значительное количество задач сбора данных с параллельной их обработкой. И эти задачи надежнее работают под Linux или что то более специализированое.

И отсутсвие драйверов приводит к тому, что платы пригодные для непрерывного сбора данных не закупаються именно потому, что нет драйверов под Linux.

Никаких запросов по драверам Вы не услышите, потому что чаще всего в таких случаях делают поиск оборудования именно начиная с просмотра списка драйверов и дальше просто не смотрят.

Вот E14-440 хорошая вещь и с Linux работает хорошо и наша программа под нее хорошо заточена, а сейчас мы как раз думаем перейти на другой АЦП только потому, что нет проверенных драйверов под ядро 2.6.

P.S.: Кстати сейчас поставить дравера под ядро 2.4 тоже нетривильная задача т.к. изменилать структура размещения модулей ядра начиная с 2.4.20 в Slackware. Пришлось пути изменять.

Тут скорее лучше обеспечить не столько общие либы сколько общий интерфейс получения данных и для Linux (да и WIN) доработать (предложить) решения на основе одной из RTL расширения ядра.
Это имеет большой смысл т.к. платы имеют небольшие допустимые интервалы между выборками данных из них (3-12мс всего). Пусть лучше все накапливается в буфферах в памяти ЭВМ на 2-3 сек. чем теряется.

закончил проект под Виндоусом и дошли руки до портирования под Линукс.. а тема тут что-то заглохла ))
итак, имеется e140 ( до e440 тоже пока руки не дошли )
Ubuntu 7.10 kernel 2.6.22

alpha3 версия драйвера работает
правда для того чтобы собрать пришлось закомментировать #include <linux/config.h> ибо такого файла вообще не обнаружил нигде о.О

для работы с драйвером alpha3 достаточно сделать
insmod ldevusb.ko
ldevpci.ko мне не нужен, а вот ldevice.ko ругается что device busy

Но вот в пятой альфе изменилась последовательность загрузки модулей и теперь из-за невозможности загрузить ldevice.ko отказыается загрузиться ldevusb.ko

в syslog наблюдаю следующее:
lcard: Staring LDev driver...
lcard: Unable register major!!!
ldevusb: Unknown symbol ldev_register
ldevusb: Unknown symbol ldev_add
ldevusb: Unknown symbol ldev_remove

думаю можно...

README.TXT на koi8-r
исходники на cp1251
ужос....

даёшь UTF-8 и ru_RU.UTF-8 !!

/home/barada/dev/LCard/dio/ldevpciu.c: В функции ‘ldriver_init’
/home/barada/dev/LCard/dio/ldevpciu.c:1114: ошибка: implicit declaration of function ‘pci_module_init’
make[2]: *** [/home/barada/dev/LCard/dio/ldevpciu.o] Ошибка 1
make[1]: *** [_module_/home/barada/dev/LCard/dio] Ошибка 2
make[1]: Leaving directory `/usr/src/linux-2.6.23-gentoo-r9'
make: *** [modules] Ошибка 2
barada@localhost ~/dev/LCard/dio $ grep pci_module_init *
ldevpcib.c:   return pci_module_init(&l791_driver);
ldevpciu.c:   return pci_module_init(&l7xx_driver);

какойто хидер не подключен?? или изменился относительно того, с которым разрабатывались дровишки?

а чего комментировать... не работает. у меня линукс машина атлон хр и потому я 64-битное не проверял еще...

А к чему стремиться?

В смысле чего должно показывать?

хмм...я думаю поставить надо 32 бит версию линуха и сравнить...
адреса и типы данных это основное что портит все... возможно я где-то неудачно их выбрал....

чужое прерывание ловит обработчик и пропускает мимо, печатая такое сообщение....

А других теперь и не сыскать вовсе. Если только
не на давно забытых серверах.

да ладно...они почти все 32 бита идут...а для энтузиастов 64.... на сайте слаки даже нету 64, я bluewhite64 выкачал специально...

может тут собака порылась? -

~/dio/test/../include/stubs.h
  33 typedef unsigned long ULONG, ULONG32, *PULONG;

а на самом деле
sizeof(ULONG)=8, 8х8=64.

После танцев с бубнами test стал работать.

Подскажите что записано в test.dat.
Вот начальный фрагмент:

0000000: e1ff 0000 d2ff 0100  ........
0000008: f3ff 0200 feff 0300  ........
0000010: 0900 0001 1200 0101  ........
0000018: 1c00 0201 1600 0301  ........
0000020: 1c00 0002 1700 0102  ........
0000028: 1b00 0202 1600 0302  ........
0000030: 1a00 0003 1500 0103  ........
0000038: 1900 0203 1300 0303  ........
0000040: 1b00 0004 1500 0104  ........
0000048: 1800 0204 1300 0304  ........
0000050: 1900 0005 1200 0105  ........
0000058: 1800 0205 1200 0305  ........
0000060: 1800 0006 1300 0106  ........
0000068: 1800 0206 1100 0306  ........
0000070: 1700 0007 1200 0107  ........
0000078: 1600 0207 1100 0307  ........
0000080: 1600 0008 1100 0108  ........
0000088: 1600 0208 1000 0308  ........
0000090: 1600 0009 1200 0109  ........

Все! Понял!

0000000: e7ff 0000  ....
0000004: c7ff 0100  ....
0000008: e2ff 0200  ....
000000c: deff 0300  ....
0000010: f1ff 0001  ....
0000014: fbff 0101  ....
0000018: 0500 0201  ....
000001c: 0100 0301  ....
0000020: 0600 0002  ....
0000024: 0000 0102  ....
0000028: 0400 0202  ....
000002c: ffff 0302  ....
0000030: 0700 0003  ....
0000034: 0100 0103  ....
0000038: 0500 0203  ....
000003c: 0000 0303  ....
0000040: 0600 0004  ....
0000044: 0100 0104  ....
0000048: 0500 0204  ....
000004c: 0100 0304  ....

Первый short - код АЦП;
далее байт   - канал
далее байт   - отсчет % 0x1f

в смысле в etc/udev/rules.d...

в дебиане сами *.rules в /etc/udev лежат, в /etc/udev/rules.d/ ссылки с цифрами приоритета в начале(как init.d  в общем); т.е. надо точно писать "Скопировать lcard.rules в /etc/udev/rules.d". (новичкам в лине проще будет, мне же просто не нужна была автомат. загрузка т.к. паралелльно с гориновскими драйверами возился)

может новую ветку создать Драйвера под линукс 2.6.х

Ну вот я не уверен что везде одинаково, потому написал лаконично... в слаке ссылок нету...
В общем случае наверно туда куда указывает путь из udev.conf...

тоесть начинает собирать и слетает?

То что сейчас лежит в инете на слаке у меня работает....только что проверил...