Advantech pci1730 DAQ card
Stuart Braid
be kind of long - you
might want to grab a coffee / whatever before you start reading.
Some background on the problem. I'm useing an Advantech industrial
machine.
Standard Red Hat Enterprise 5 baseline install to get the box up and
running. The
documentation supplied by the comedi group warns that the RH kernel
headers have
been highly modified so I grabbed a copy of the 2.6.20.6 kernel
sources from
kernel.org and used that ( I've already installed that and gotten it
working fineon
another boxen but that's a different headache ). The useual stuff :
make, make
modules, make modules_install, make install and then making the new
kernel the
default in /boot/grub/grub.conf.
All commands described in this posting were done as root.
Advantech supplied drivers for the ethernet and the DAQ cards copied
onto the
machine from CD and built against the 2.6.20.6 kernel and installed.
The ethernet
driver is fine and it looks like the Advantech pci1730 driver is fine
as well :
lspci -vv
03:0e.0 Class ff00: Advantech Co. Ltd Unknown device 1730 (rev 10)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 21
Region 0: Memory at <ignored> (64-bit, prefetchable)
[disabled]
Region 2: I/O ports at d800 [size=256]
cat /proc/modules | grep 1730
pci1730 14592 0 - Live 0xf82ee000
advdrv_core 30228 1 pci1730, Live 0xf82d0000
Create the device files as indicated by the install notes with the
following ( the
insmod and device creation is done at boot in /etc/rc.d/rc.local -
ugly but it works ).
rm --force -rf /dev/advdaq[0-3]
mknod /dev/advdaq0 c 252 0
mknod /dev/advdaq1 c 252 1
mknod /dev/advdaq2 c 252 2
mknod /dev/advdaq3 c 252 3
mknod /dev/advdaq254 c 252 254
chmod 664 /dev/advdaq[0-3]
./advdevice_list
Advantech : advdevice_list version 0.0.01
The 0 Advantech Device:
+--Device Type Name is pci1730
+--BoardID is 0x0
+--iobase is 0xd800
+--slot is 0xe
+--irq is 0x15
+--The Device has not been binded with device file!
+--Please bind this device with device file using
advdevice_bind utility!
After some reading and fiddling around, we opted for the following to
bind the
device ( iobase and irq are grabbed from the lspci listing after
installation ) :
/usr/src/advdaq-1.09.0001/tools/advdevice_bind --iobase 0xd800 --irq
21 pci1730 0 /dev/advdaq0
No errors. Everything looks sweet. Feel free to say "that doesn't look
right" if it
isn't. Run advdevice_list again :
./advdevice_list
Advantech : advdevice_list version 0.0.01
The 0 Advantech Device:
+--Device Type Name is pci1730
+--BoardID is 0x0
+--iobase is 0xd800
+--slot is 0xe
+--irq is 0x15
+--The Device has been binded with /dev/advdaq0
Final check : sample program located in the Advantech driver notes and
slightly
modified here for anyone who has the same problem :
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
/* include the header file */
#include "include/advdevice.h"
#include "include/advdaq.h"
#include <math.h> /* needed for sqrt dependency in a module somewhere
*/
#include <stdio.h> /* only needed to include printf */
int main()
{
PTR_T fd;
INT32S ret;
INT32U port_start = 0;
INT32U port_count = 1;
INT8U buffer;
ret = DRV_DeviceOpen("/dev/advdaq0", &fd); //open the device, get the
if (ret)
{
printf("Error on DRV_DeviceOpen - terminating.\n");
return -1;
}
else
{
printf("DRV_DeviceOpen completed without error.\n");
}
ret = DRV_DioWriteDOPorts(fd, port_start, port_count, &buffer); //DO
operation
if (ret)
{
printf("We assume we got an error on DRV_DioWriteDOPorts.\n");
}
else
{
printf("We assume DRV_DioWriteDOPorts was ok.\n");
}
DRV_DeviceClose(&fd); //close the device
return 0;
}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
To compile with gcc 4.1.2
gcc -o foobar foobar.c -ladvdaq -ldl -lm
./foobar
DRV_DeviceOpen completed without error.
We assume DRV_DioWriteDOPorts was ok.
So : it looks like the driver is loaded and operational.
The problem that I still have to resolve is the comedi interface code.
Advantech no
longer seems to be supporting the code and their on-line support web-
site will allow
you to download comedi-0.7.60 and comedilib-0.7.20. I had a try at
compiling and
installing them but this is the point where I encountered some major
difficulties. I
spent some time trying to patch around them but the main problem was
some basic
assumptions about the differences between 2.4 and 2.6 kernels ( and
no : 2.4 kernels
are not an option because of other hardware considerations here ).
At that point I went and grabbed something that was a little bit more
up to date :
comedi-0.7.76 and comedilib-0.8.1. I followed the installation
instructions and didn't
have any problems building and installing. Both comedi and comedilib
were set
up in /usr/src with a symbolic link /usr/src/kernel pointing to the
2.6.20.6 kernel
directory. The .config used was the same as I've used on another boxen
( pretty
much standard - I can e-mail it if required. The only thing that was
changed from the
default was to change one setting from 4 default serial ports to 16 ).
The following
information is provided by way of verification :
cat /proc/comedi
comedi version 0.7.76
format string: "%2d: %-20s %-20s
%4d",i,driver_name,board_name,n_subdevices
no devices
adv_pci_dio:
pci1730
pci1733
pci1734
pci1750
pci1751
pci1752
pci1753
pci1753e
pci1754
pci1756
pci1760
pci1762
8255:
8255
ls -l /dev/comedi*
crw------- 1 root root 98, 0 Jun 27 11:42 /dev/comedi0
crw------- 1 root root 98, 1 Jun 27 11:42 /dev/comedi1
etc, etc
My problem comes in when I try to use comedi_configure to create the
association
between the actual hardware driver and the comedi virtual device :
comedi_config --verbose /dev/comedi0 pci1730 0xd800,21
configuring driver=pci1730
55296,21,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
Configure failed!: Input/output error
Check kernel log for more information
Possible reasons for failure:
Driver not found
If we check /var/log/messages we see :
Jun 28 09:28:09 riley-mlc kernel: comedi0: adv_pci_dio: board=pci1730,
Error: Requested type of the card was not found!
I've tried a few other completely off the wall combinations on the off
chance that I
might work it out on my own :
comedi_config --verbose /dev/comedi0 adv_pci_dio 0xd800,21
configuring driver=adv_pci_dio
55296,21,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
Configure failed!: Input/output error
Check kernel log for more information
Possible reasons for failure:
Driver not found
Here is the output that was produced in /var/log/messages
Jun 28 09:26:45 riley-mlc kernel: comedi0: adv_pci_dio: board=pci1730,
Error: Requested type of the card was not found!
Jun 28 09:28:09 riley-mlc kernel: comedi0: adv_pci_dio: board=pci1730,
Error: Requested type of the card was not found!
Jun 28 09:37:59 riley-mlc kernel: comedi: valid board names for
adv_pci_dio driver are:
Jun 28 09:37:59 riley-mlc kernel: pci1730
Jun 28 09:37:59 riley-mlc kernel: pci1733
Jun 28 09:37:59 riley-mlc kernel: pci1734
Jun 28 09:37:59 riley-mlc kernel: pci1750
Jun 28 09:37:59 riley-mlc kernel: pci1751
Jun 28 09:37:59 riley-mlc kernel: pci1752
Jun 28 09:37:59 riley-mlc kernel: pci1753
Jun 28 09:37:59 riley-mlc kernel: pci1753e
Jun 28 09:37:59 riley-mlc kernel: pci1754
Jun 28 09:37:59 riley-mlc kernel: pci1756
Jun 28 09:37:59 riley-mlc kernel: pci1760
Jun 28 09:37:59 riley-mlc kernel: pci1762
Jun 28 09:37:59 riley-mlc kernel: comedi: valid board names for 8255
driver are:
Jun 28 09:37:59 riley-mlc kernel: 8255
( Try not to hurt yourselves falling of your chairs and laughing
gang ;) ).
If I use /dev/advdaq0 ( the device file that the Advantech driver
itself seems to be
connected to ) instead of /dev/comedi0, it complains. I've tried
useing
./board_info -f /dev/advdaq0
/dev/advdaq0: Bad address
and
comedi_test
E: comedi_open("/dev/comedi0"): No such file or directory
I did poke around fairly extensively on one of the old legacy RH 7.3
machines that
the system was originally developed for about 6+ years ago. I found a
pci1730.c
source file and yes : it did occur to me that I might need to compile
that and build
it into the comedi group of driver interface modules sitting under the
comedi/drivers
directory. It became very obvious very quickly that the tools that
were used to do
that on the older version have changed / been deprecated and are no
longer
compatible, so I gave up on that after a couple of days. I don't have
a problem doing
that if I have to - I would just need a few pointers to get me moving
in the right
direction, that's all.
Anyway : if I'm doing something really obviously dumb, feel free to
say so. Any advice
would be appreciated.
Regards,
Stuart Braid
Ian Abbott
Try :
comedi_config --verbose /dev/comedi0 pci1730
without the 'base,irq' option. The driver doesn't expect the options to
be 'base,irq', it expects them to be 'bus,slot'. If 'bus,slot' is not
specified, it will grab the first matching card it finds.
According to your lspci output above, you could configure it with
'bus,slot' specified as follows:
comedi_config --verbose /dev/comedi0 pci1730 3,14
(that corresponds to a PCI device at 03:0e.0).
> If I use /dev/advdaq0 ( the device file that the Advantech driver
> itself seems to be
> connected to ) instead of /dev/comedi0, it complains. I've tried
> useing
>
> ./board_info -f /dev/advdaq0
> /dev/advdaq0: Bad address
>
> and
>
> comedi_test
> E: comedi_open("/dev/comedi0"): No such file or directory
Well, you can't have both the Advantech and Comedi add_pci_dio drivers
using the card. If the Advantech driver has already bound the card to
one of its device files (or has maybe already reserved the cards
resources and put the card on a list ready to be bound to a device
file), the Comedi attach routine may find the card, but will error out
if the card's resources have already been reserved by the Advantech driver.
> I did poke around fairly extensively on one of the old legacy RH 7.3
> machines that
> the system was originally developed for about 6+ years ago. I found a
> pci1730.c
> source file and yes : it did occur to me that I might need to compile
> that and build
> it into the comedi group of driver interface modules sitting under the
> comedi/drivers
> directory. It became very obvious very quickly that the tools that
> were used to do
> that on the older version have changed / been deprecated and are no
> longer
> compatible, so I gave up on that after a couple of days. I don't have
> a problem doing
> that if I have to - I would just need a few pointers to get me moving
> in the right
> direction, that's all.
I wouldn't bother trying to get the old Advantech Comedi 0.7.60 drivers
working on a 2.6 kernel. The old Advantech Comedi drivers did support
more features of the cards than the "official" Comedi drivers. They
could have fed these changes back to the Comedi project, but instead
they chose to release their own cut-down version of comedi-0.7.60 with
their own changes and put scary comments in their source code:
// This is An Unpublished Work Containing Confidential And Proprietary
// Information Which Is The Property Of Advantech Automation Corp.
//
// Any Disclosure, Use, Or Reproduction, Without Written
Authorization From
// Advantech Automation Corp., Is Strictly Prohibit.
Which is probably invalid anyway since the whole thing is supposed to be
covered by GPL. But still, the whole way they went about it sucked
donkey balls. **RANT OVER**
> Anyway : if I'm doing something really obviously dumb, feel free to
> say so. Any advice
> would be appreciated.
>
> Regards,
> Stuart Braid
You might find that comedi-0.7.76 builds fine against the normal RHEL5
kernels. If not, the latest "git" snapshots probably would.
--
-=( Ian Abbott @ MEV Ltd. E-mail: <abb...@mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-