HI
I am trying to install linux_gpib driver(latest driver 4.3) into raspberrypi 3 model b+ (raspbian).
installion seems to be successfull (checks were done with lsmod). But on giving gpib_config the following error appears:
failed to bring board online
failed to configure board
main: No such device
Iam using NI GPIB_USB_HS+ adaptor .
Are there any work arounds possible ?
Best reagrds,
Athira
The hs+ does work, try using the code from svn instead. Also, make sure the gpib udev rule files are getting installed into
/etc/udev/rules.d/
If you configured the library without setting the sysconfdir to /etc then you may have to add some symlinks which point to the files which are default installed in /usr/local/etc/udev/rules.d/
If it is working properly, gpib_config should get run automatically by the udev rules when the adapter is plugged in.
Hello Frank
I tried reinstalling using .
Does the driver linux_gpib depends on the kernel version of linux? I followed different steps from following link https://xdevs.com/guide/ni_gpib_rpi/
When i do step "modprobe ni_usb_gpib" it throws error . Are there any insights to the same ?
Athira
Hello Frank
the above problem seems to get solved with correct header installation. and gpib_config file is installed in /etc. the device in it is edited with device "ni_usb_b".
Still I get the error:
*failed to bring board online
failed to configure board
main: No such device
Is there anything else to be done for the same ?
Regards,
Athira
Hi Frank
on giving dmesg :
[* 1438.309064] gpibcommon: loading out-of-tree module taints kernel.
[ 1438.312275] Linux-GPIB 4.3.0 Driver
[ 1438.328358] niusbgpib driver loading
[ 1438.328509] usbcore: registered new interface driver niusbgpib
[ 1438.328517] gpib: registered niusbb interface
[ 1545.501862] niusbgpib: attach
[ 1545.501872] No supported NI usb gpib adapters found, have you loaded its firmware?
[ 1545.501877] gpib: interface attach failed*
regards,
Athira
What is the output of the "lsusb" command? It should have a line like:
Bus 001 Device 002: ID 3923:7618 National Instruments Corp.
Your dmesg looks like either you ran gpib_config without the gpib adapter plugged in, or NI has issued a new version of the HS+ with a new usb device id.
Hi frank
Yes lsusb gives me the following output:
Bus 001 Device 002: ID 3923:761e National Instruments Corp.
Regards,
Athira
On Thu, Apr 2, 2020 at 12:13 AM Frank Mori Hess fmhess@users.sourceforge.net wrote:
Related
Support Requests: #27
i frank
Yes lsusb gives me the following output:
Bus 001 Device 002: ID 3923:761e National Instruments Corp.
I have two rule files in etc/udev/rules.d/
99-ni_usb_gpib.rules and 98-gpib-generic.rules
Should i chnage the device ids for the same ?
Regards,
Athira
Ok, I added the 761e device id to the kernel module and udev rules. Do the following:
1) delete the existing gpib rules from /etc/udev/rules.d
2) update your linux-gpib svn checkout
3) rebuild and reinstall linux-gpib-user and linux-gpib-kernel
4) reboot (or make sure the old gpib modules are unloaded)
5) try again
If it still doesn't work, send me the portion of the output of "lsusb -v" for your adapter.
Hi Frank
I tried changing the rules files with new device id. Still gpib_config
command gives same error message.
I didn't reinstall instead tried changing the rule file and tried .
Athira
On Thu, Apr 2, 2020, 11:24 PM Frank Mori Hess fmhess@users.sourceforge.net
wrote:
Related
Support Requests: #27
Fixing the udev rules will only affect whether gpib_config is run
automatically when you plug in the adapter. You need the updated kernel
module to make the driver recognize the hardware.
Hi Frank
I tried installing from freshlz checkedout and met with some new error:
on giving gpib_config(after changing device to ni_usb_b):
failed to bring board online
failed to configure board
main: Broken pipe
on giving dmesg the following messegges are seen in kernel:
[ 2953.974909] attached to bus interface 0, address 0x05157767
[ 2953.975230] product id=0x761e
[ 2953.975386] /home/linux-gpib/linux-gpib-code/linux-gpib-kernel/drivers/gpib/niusb/niusbgpib.c: usbcontrolmsg request 0x41 returned -32
[ 2953.975522] /home/linux-gpib/linux-gpib-code/linux-gpib-kernel/drivers/gpib/niusb/niusbgpib.c: usbcontrolmsg returned -32
[ 2953.975538] /home/linux-gpib/linux-gpib-code/linux-gpib-kernel/drivers/gpib/niusb/niusbgpib.c: failed to submit bulk out urb, retval=-2
[ 2953.975548] /home/linux-gpib/linux-gpib-code/linux-gpib-kernel/drivers/gpib/niusb/niusbgpib.c: niusbwriteregisters: niusbsendbulkmsg returned -2, byteswritten=0, i=16
[ 2953.975556] /home/linux-gpib/linux-gpib-code/linux-gpib-kernel/drivers/gpib/niusb/niusbgpib.c: niusbshutdownhardware: register write failed, retval=-2
[ 2953.975563] gpib: interface attach failed*
Note : I have not connected any devices to the adaptor yet. Once gpibconfig returns without any errors i would proceed for the same.
some register writes seems to fail. Are there any steps that should be done for the same ?
-Athira
I have a new theory about your device id. Rather than a new version
of the gpib-usb-hs, you might have an old version which requires a
firmload upload before it is usable (this is how the gpib-usb-b
worked). Try using your adapter under Windows with the NI drivers and
see if it loads firmware. If it loads firmware, you will see the usb
device id change from 761e to a new device id.
Hi Frank
Do you know how to check in windows driver if the firmware is loaded? I
cant find the device ID like in linux in windows except for the serial
number.
regards,
Athira
On Thu, Apr 9, 2020 at 12:35 AM Frank Mori Hess fmhess@users.sourceforge.net wrote:
Related
Support Requests: #27
Hi Frank
adding lsusb -v for the adaptor:
Bus 001 Device 005: ID 3923:761e National Instruments Corp.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x3923 National Instruments Corp.
idProduct 0x761e
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 100
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 100
Okay, your adapter looks quite a bit different from the old HS+, you
have 2 bulk endpoints and no interrupt endpoint. It is going to
require running a usb sniffer on the windows driver to reverse
engineer how it has changed. My old HS+ has extra bulk in/out
endpoints we don't use (plus 2 bulk endpoints and an interrupt
endpoint we do use), it is possible they correspond to the 2 bulk
endpoints on your device and they have now dropped the 3 old endpoints
we use. I'm just guessing though. If I find time, I might try to
sniff my old adapter under windows and see if it uses the 2 extra
endpoints.
Hi Frank
So update for the build would be required for the getting the driver up right ?
Which sniffer can we run in windows side ? what data would you need for the same?
I can try running as well.
Athira
The last time I sniffed usb on windows, I used wireshark with libpcap.
The NI windows software has an interactive test program that lets you
basically call the library functions (ibrd, etc) which is how I
originally reversed engineered it, calling one function at a time and
seeing what it wrote/read from the adapter. There was usually a 1 to
1 relationship between the library functions and the operations the
adapter supported. In addition to the driver source code at
linux-gpib-kernel/drivers/gpib/ni_usb/ni_usb_gpib.c
there is a text file in svn at
linux-gpib-kernel/drivers/gpib/tnt4882/ni-usb-b.txt which consists of
notes I made while originally figuring out how the ni-gpib-usb worked.
Hi Frank
From the device manager in windows, the following id appeared for GPIB adaptor. Does it mean firmware loading for the device ?
USB\VID_3923&PID_7618&REV_0100&MI_00
Ah, yes. That is showing the device id is now 7618 which is the normal device id for a gpib-usb-hs+. If your machine is dual boot, if you reboot into Linux without cycling power, then you should be able to (temporarily) use the adapter in Linux.
What we need now is for you to use the usb sniffer to extract everything that is sent to the adapter when it is plugged in and initialized (before the device id changes to 7618). Then I can extract the firmware from this and you will be able to load the firmware from linux with fxload.
Hi Frank
I just captured the belowusing wireshark. Does this help ?
I don't think your capture includes what we need. It starts with some
packets to a device 1.2.0 which is some kind of video device
idVendor: Realtek Semiconductor Corp. (0x0bda)
then the device 1.5.0 is your gpib-usb-hs+ but it has already had its
firmware loaded, since its produce id has already changed
idVendor: National Instruments Corp. (0x3923)
idProduct: Unknown (0x7618)
So we need the earlier packets when the adapter is first plugged in
and the idProduct is 0x761e.
So after connecting towindows , I disconnected it and connected to raspberry pi (raspbian ) and looks like th edriver is up. this means the firmware was already loaded to it from Windows sidewhen it was connected ?
I guess it is possible, although I expected the adapter to need the
firmware to be reloaded every time it is powered on. Does it actually
work? What does "lsusb" say its product id is?
On Wed, Apr 15, 2020 at 11:26 AM Athira athi@users.sourceforge.net wrote:
Hello Frank
The lsusb -v gives the following :
Bus 001 Device 004: ID 3923:7618 National Instruments Corp.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x3923 National Instruments Corp.
idProduct 0x7618
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x004c
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 5
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 6
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 100
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 100
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 100
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 100
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 7
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 100
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
the device id is changed to 7618.And theadaptor seems to be working with linux even after power on and off.