linux-gpib-general — linux-gpib package mailing list

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Michael K <vk...@ya...>]

Hi Jim, I's a '82357B'

$ lsusb -v 


Bus 001 Device 016: ID 0957:0718 Agilent Technologies, Inc. 82357B ()
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0957 Agilent Technologies, Inc.
  idProduct          0x0718 
  bcdDevice            0.00
  iManufacturer           1 Agilent Technologies, Inc.
  iProduct                2 82357B ()
  iSerial                 5 MY49450720
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0027
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          3 HIGHSPEED
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         0 
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      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               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x06  EP 6 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x88  EP 8 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)










On Friday, September 22, 2023 at 12:30:18 PM EDT, Jim Houston <ji...@ov...> wrote: 





Hi Michael,

Good a passed test.  Is this with an Agilent 82357A or B?

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

Hi Michael,

Good a passed test.  Is this with an Agilent 82357A or B?

JIm Houston

On 9/22/23 12:07, Michael K wrote:
> This is what I get ...
>
> [maxwell HPIBtest] 😼 cat HPIBresult
> H 0x01a4
> E 0x01ac
> W 0x01a4
> L 0x01a4
> E 0x01a4
> T 0x01a4
> T 0x0130
>    0x01a0
> P 0x01a0
> A 0x01a8
> C 0x01a8
> K 0x01a0
> A 0x01a8
> R 0x01a4
> D 0x0134
> , 0x0130
> 8 0x013c
> 7 0x0134
> 5 0x0138
> 3 0x01a8
> C 0x0134
> , 0x0130
> 0 0x0134
> , 0x0134
> 4 0x013c
> . 0x0130
> 1 0x0138
> 3 0x0128
>
>
>   0x0128
> [maxwell HPIBtest] 😼
>

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Michael K <vk...@ya...>]

This is what I get ...

[maxwell HPIBtest] 😼 cat HPIBresult 
H 0x01a4
E 0x01ac
W 0x01a4
L 0x01a4
E 0x01a4
T 0x01a4
T 0x0130
  0x01a0
P 0x01a0
A 0x01a8
C 0x01a8
K 0x01a0
A 0x01a8
R 0x01a4
D 0x0134
, 0x0130
8 0x013c
7 0x0134
5 0x0138
3 0x01a8
C 0x0134
, 0x0130
0 0x0134
, 0x0134
4 0x013c
. 0x0130
1 0x0138
3 0x0128


 0x0128
[maxwell HPIBtest] 😼 

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

Hi Everyone,


Spoiler:
Proposed fix for flakey behavior of an Agilent 82357B.  Testers wanted.
Under unusual conditions the 82357B returns an EBUS timeout for all
commands until it is unplugged and plugged back in.  In particular the
problem depends on the last character of the last message received.
The problem doesn't happen in the normal case where the read buffer
is large enough to hold the whole response and the last character is
newline.  The accompanying test program reads characters a byte at a
time and can recreate the problem.  If you have an Agilent 82357B and
an instrument that responds to commands please run the attached program
and send the output to help determine whether this is a common problem
or only specific to my board.

TLDR;

* The problem *
I was trying to use my HP 82357B to read the calibration data
from my HP3478A meter.  It failed with EBUS.

I posted here on July 26th and have been working with Dave Penkler to 
debug this
problem since then.  It wasn't clear if this was flakey hardware or a 
problem
with the Linux-gpib agilent_82357a driver.

The calibration data of the HP3478A can be read a nibble at a time by 
sending a
two character command consisting of a 'W' followed by a byte with the 
8-bit address
of thelocation to be read from the ram.  Tom Verbeure has good description
of the process here:
https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html

The calibration data is returned as a single byte with values in the
range 0x40-0x4f where the lower 4 bits are the value of the addressed
nibble.  The EBUS failure only happened for some addresses.  A 'W1'
command always worked but sending a 'W4' command caused the next
command to receive an EBUS failure.  Once the system returned an EBUS
the only way to recover was to unplug the HP 82357B USB cable and plug
it back in.  Further testing showed that it was the returned nibble
that predicted the failure.  Here is the table:

@ABC HIJK - The next read works.
DEFG LMNO - The next read fails with EBUS

So it was the DI[2] bit which determined the result.

* The Debug *
I had fun chasing this problem.  I started with printks in the driver
and determined that the EBUS was the result of agilent_82357_take_control
failing.  This function is supposed to assert ATN to signal that
the  bytes which follow are command bytes.  This is done automatically
when a command is written or can be done with a user call to ibcac().
The take_control function sends a command to the GPIB bus control
logic in the 82357B and then polls waiting for ATN to be asserted.
In the failure case it timed out waiting for ATN to be asserted.

I used my logic analyzer to capture the GPIB activity, wireshark and
usbmon to capture the USB traffic and Linux ftrace because I got tired
of adding printk's.  Finally I hooked the logic analyzer to the
TMS9914 chip which implements the GPIB control logic in the 82357B.

* History related problems *
We knew that there had been problems with the agilent_82350b driver
which involved the take_control path.  The issue involves the
synchronous option to take_control.  This option determines if
the GPIB controller in the 82357B waits (synchronizes with) a
pending IO before asserting  ATN.  If the sync option is 1 the
controller waits.  If sync is zero the controller just asserts ATN.
The default command path calls ibcac() in the common portion of
the gpib driver with sync=1.  There is logic to try to recover from
a failure to assert ATN by trying a second time with sync=0.
It also checks if the ATN bit is already set in ibsta and will
avoid calling the take_control function.  The problem with the 82350B and
potentially all TMS9914 based designs is that once it has tried to
do a take_control synchronously it is stuck.  A subsequent call
with sync=0 doesn't work.  The work around for the 82350B is
to have the take_control function return a timeout error if it is
called with sync=1.  The ibcac() will call back with sync=0 avoiding
the problem.  If the call is from the user-space library ibcac()
(contrary to the documentation), it doesn't fall back to asynchronous.
It will fail a request with sync=1.  Does it return failure if the ATN
bit is falsely already set in ibsta?  No because if ATN is not asserted
by the controller the firmware will initiate an asynchronous take control
(TCA) on the chip before sending the command bytes.

* Keysight to the rescue *
I also tried to reproduce the problem with the Keysight IO libraries.
They have a version for Linux.  It works with PyVISA and I was able
to send the 'W1' and 'W4' commands to the HP3478A but it always returned
the front panel display value rather than the calibration ram single
byte response which I had expected.  I put some effort into diagnosing
this new problem and believe that it was the result of the IO libraries
always sending a secondary address of 0.  So the PyVISA identifier
GPIB::22::INSTR was interpreted as GPIB::22::0::INSTR.  I could see this
on the GPIB bus using my logic analyzer, and I could see it in the
usbmon trace using Wireshark.  The Keysight IO libraries consist of a
proprietary user space and an open source device driver.  I had hoped
to see if the Keysight software initialized the 82357B the same as
the linux-gpib.  I was able to capture the initialization from the
USB bus using Wireshark.  I tried using the same initialization sequence
in the linux-gpib driver and still had the same EBUS failure.
I wrote a python script which allowed me to use the Agilent driver
bypassing the IO libraries.  This let me send 'W4' command to the HP3478A.
Subsequent commands worked.  I also found that the Keysight code always
used asynchronous take control command to assert ATN.


* Enlightenment *
I shared the captured traces with Dave, and he figured out that the
character being read determined if the take_control function was
being called with sync=0 or 1.  This is the result of another short cut in
the common gpib ibcac() function that will only use the sync option
if the board is a listener on the GPIB bus.  It does this by checking the
LACS status bit.  The agilent_82357a driver gets this status from
the TMS9914 ADSR register.  In the case of my Agilent 82357B this
register was corrupted with the last character of the last message
received.
The failure case with my HP 3478A,  issuing a 'W4' command results
in location 0x34 being read and single character 'F' was returned.
This character was also being returned for reads of the ADSR register.
This corruption of the ADSR register caused the common gpib ibcac()
to call the agilent_82357a_take_control() with sync=1.
This triggers a failure similar to the problem previously seen
with the Agilent 82350B.  The AUX_TCS is sent but the ATN signal
is never asserted.

* Can you reproduce the failure at home?  *
 From the start I was not sure if this was a broken Agilent 82357B
or a problem with the driver.  We still don't know.  We would like
other Agilent 82357 owners to test.  You don't need an HP3478A
to reproduce this problem.  Since the problem depends on the last
character received it would often be masked since a '\n' doesn't
cause the failure.  In normal use the receive buffer is large
enough to hold the whole response and the problem is avoided.
The problem is easy to reproduce if you read a character at a time.
The attached python script takes two arguments the device number
and a command.  Here is an example using my HP6642 power supply:

jhouston@linux-gpib:~$ python3 byte_read.py 4 volt?
b'0' 256
b'.' 256
b'0' 256
b'E' 256
InternalReceiveSetup: command failed
Traceback (most recent call last):
   File "byte_read.py", line 12, in <module>
     ch = inst.read(1)
   File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in read
     self.res = gpib.read(self.id,len)
gpib.GpibError: read() failed: An attempt to write command bytes to the 
bus has timed out.
jhouston@linux-gpib:~$

In this case the 'E' as the last character read triggers the failure.

Dave Penkler ran the attached 'C' program on his Beiming 82357B clone
with an HP34401 dmm without errors.  But as it has its own firmware it
does not prove that there is not a common problem with the Agilents.
$ onebyte -m2 -d7 "MEAS:VOLT?"
- 0x0164
1 0x0164
. 0x0164
9 0x0164
4 0x0164
8 0x0164
E 0x0164
- 0x0164
0 0x0164
6 0x0164

  0x0164
$

* The Hardware *
The Agilent 82357B consists of
a Cypress EZ-USB chip, a GPIB controller chip, a Xilinx XC9536 CPLD
and bus transceivers.  On my 82357B the GPIB controller is labeled
Agilent 1822-0639.  Google searches find this in the BOM for several
HP/Agilent/Keysight products as a TMS9914.  It would be nice to know
the difference between the 82357A and 82357B.  From picture of the
boards posted to the internet they have the same major parts.  Mine
has the same revision label on the Xilinx XC9536 as a rev A board
picture posted on the Sigrok website here:
https://sigrok.org/wiki/Agilent_82357A

The firmware for the Cypress EZ-USB is downloaded using a udev script
which runs fxload.  The A/B revs of the 82357 have different firmware
files from Agilent.  Again we don't know why the firmware is different.
The agilent_82357a driver is used for both and treats them the same.

This might be a hardware problem unique to my 82357B.  In
addition to the failure with the ADSR register corruption, I have
seen other strange behavior.  I have seen bursts of traffic which
include very fast DMA transfers which do not match any request
from the driver.  There is always a chance that connecting a
logic analyzer may effect the circuit under test.  I'm using a
HP16702A and connecting to the TMS9914 using a PLCC clip and flying
leads.  The GPIB is probed using an HP10342.  I don't have
a good ground path for the flying lead probes, but the traces make
sense so I think that the DMA transfers are real.
It would be nice to instrument another 82357 but it is hard to
justify spending the $100 which it is likely to cost.

* The right fix *
I had hoped that this problem was the same as take_control problem
in the agilent_82350b driver.  I tried changing take_control to
only use AUX_TCA.  This fix worked and I was able to read the
calibration ram of the HP3478A.

Once we found that the problem was the result of reads of the
TMS9914 ADSR register being corrupted, we tested various commands
and found that only the AUX_TCS and AUX_TCA would restore the
ADSR register to correct operation.  We tried using the clear
LON (Listener only) command.  This does not restore the correct
function of the ADSR register but seems to make AUX_TCS work
if it is used by the take_control function to assert ATN.

Calling take_control from the agilent_82357a_read function
would restore the correct ADSR register behavior.  I have
tested this and it solves my problems.  Dave Penkler is
concerned that users of the low-level interface
may be surprised that the ATN signal has been asserted.
Having the ATN asserted works well for most high level operations
because the next operation is likely to have to send commands
to setup listen and talk addresses.

The other alternative is to understand when we can trust the
ADSR register and to provide a resonable guess of the GPIB
state when we know that the ADSR is corrupt.

Jim Houston

Re: [Linux-gpib-general] missing "System.map" and depmod skipped

[dave p. <dpe...@gm...>]

Hi Saif,

On Wed, 13 Sept 2023 at 07:51, Saif Mostafa <goe...@gm...>
wrote:

>
>  Thank you for answering, does that mean I can ignore the depmod failing
> and proceed assuming the installation was successful?
>

Yes you can safely ignore that message.

cheers,
/d

>
> Sincerely,
> Saif Mostafa
> ------------------------------
> *From:* dave penkler <dpe...@gm...>
> *Sent:* Friday, September 1, 2023 7:47:17 AM
> *To:* Saif Mostafa <goe...@gm...>
> *Cc:* lin...@li... <
> lin...@li...>
> *Subject:* Re: [Linux-gpib-general] missing "System.map" and depmod
> skipped
>
> Hi,
> The linux-gpib Makefile runs depmod for you. So your installation should
> be fine. In Debian based systems, like Ubuntu, the depmod.sh script fails
> with the message you posted.
> regards,
> /d
>
> On Thu, 24 Aug 2023 at 06:25, Saif Mostafa <goe...@gm...>
> wrote:
>
> Hello,
>
>  I am having trouble installing the linux gpib drivers on Ubuntu 22.04
> LTS. I was able to build using the make command but once I move on to the
> install I get:
> "Warning: modules_install: missing 'System.map' file. Skipping depmod."
>
>  I am sure this is a common problem but I am not really familiar with it.
> I also wanted to mention that I am not entirely sure I am doing all the
> correct steps as I untar the downloaded tarball in the Downloads directory
> and the install file mentioned a lot about having a copy of the kernel
> source. I anticipate this might be one of those "building against a
> different kernel" but I am hoping I could get some help.
>
> Sincerely,
> Saif Mostafa
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
>

Re: [Linux-gpib-general] missing "System.map" and depmod skipped

[Saif M. <goe...@gm...>]

Hi Dave,

 Thank you for answering, does that mean I can ignore the depmod failing and proceed assuming the installation was successful?

Sincerely,
Saif Mostafa
________________________________
From: dave penkler <dpe...@gm...>
Sent: Friday, September 1, 2023 7:47:17 AM
To: Saif Mostafa <goe...@gm...>
Cc: lin...@li... <lin...@li...>
Subject: Re: [Linux-gpib-general] missing "System.map" and depmod skipped

Hi,
The linux-gpib Makefile runs depmod for you. So your installation should be fine. In Debian based systems, like Ubuntu, the depmod.sh script fails with the message you posted.
regards,
/d

On Thu, 24 Aug 2023 at 06:25, Saif Mostafa <goe...@gm...<mailto:goe...@gm...>> wrote:
Hello,

 I am having trouble installing the linux gpib drivers on Ubuntu 22.04 LTS. I was able to build using the make command but once I move on to the install I get:
"Warning: modules_install: missing 'System.map' file. Skipping depmod."

 I am sure this is a common problem but I am not really familiar with it. I also wanted to mention that I am not entirely sure I am doing all the correct steps as I untar the downloaded tarball in the Downloads directory and the install file mentioned a lot about having a copy of the kernel source. I anticipate this might be one of those "building against a different kernel" but I am hoping I could get some help.

Sincerely,
Saif Mostafa
_______________________________________________
Linux-gpib-general mailing list
Lin...@li...<mailto:Lin...@li...>
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] missing "System.map" and depmod skipped

[dave p. <dpe...@gm...>]

Hi,
The linux-gpib Makefile runs depmod for you. So your installation should be
fine. In Debian based systems, like Ubuntu, the depmod.sh script fails with
the message you posted.
regards,
/d

On Thu, 24 Aug 2023 at 06:25, Saif Mostafa <goe...@gm...> wrote:

> Hello,
>
>  I am having trouble installing the linux gpib drivers on Ubuntu 22.04
> LTS. I was able to build using the make command but once I move on to the
> install I get:
> "Warning: modules_install: missing 'System.map' file. Skipping depmod."
>
>  I am sure this is a common problem but I am not really familiar with it.
> I also wanted to mention that I am not entirely sure I am doing all the
> correct steps as I untar the downloaded tarball in the Downloads directory
> and the install file mentioned a lot about having a copy of the kernel
> source. I anticipate this might be one of those "building against a
> different kernel" but I am hoping I could get some help.
>
> Sincerely,
> Saif Mostafa
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] INES GPIB-PCI board: bugs in ver. 4.3.4 and above

[dave p. <dpe...@gm...>]

Hi,
There were no ines related changes between 4.3.3 and 4.3.4 so the problem
might be elsewhere. Please send the gpib related dmesg output.

On Tue, 29 Aug 2023 at 09:19, <tn...@gm...> wrote:

> Hello,
>
> Since version 4.3.3, I am having problems with an INES GPIB-PCI board in
> Debian 11.7 (gcc 10.2.1).
> The GPIB communication works fine in ver. 4.3.3, but in all the versions
> above it (4.3.4 to 4.3.6) the board is unresponsive.
> The required drivers are nec7210 and ines, of which the first is unchanged
> (hence OK). As for ines
> (linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/ines), there are
> some changes from ver. 4.3.3 (working) to the following ones (not working)
> - see below.
>
> Please check the modified code and, if possible, make it work again also
> in versions 4.3.4+
>
> ===========================
>
> The output of lspci -vv is:
>
> 05:01.0 Communication controller: Advantech Co., Ltd. INES GPIB-PCI
>         Subsystem: Advantech Co., Ltd. INES GPIB-PCI
>         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Interrupt: pin A routed to IRQ 21
>         Region 0: Memory at df014000 (32-bit, non-prefetchable) [size=16K]
>         Region 1: I/O ports at b100 [size=32]
>         Kernel modules: ines_gpib
>
>
>
> $ diff
> linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/ines/ines_cs.c
> linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/ines/ines_cs.c
>
> 294c294
> <       .name           = "ines_gpib_cs",
> ---
> >       .drv = { .name = "ines_gpib_cs", },
>
>
>
> $ diff
> linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/ines/ines_init.c
> linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/ines/ines_init.c
>
> 675,684d674
> < static int ines_pci_probe(struct pci_dev *dev, const struct
> pci_device_id *id) {
> <       return 0;
> < }
> <
> < static struct pci_driver ines_pci_driver = {
> <       .name = "ines_gpib",
> <       .id_table = ines_pci_table,
> <       .probe = &ines_pci_probe
> < };
> <
> 689,694d678
> <       err = pci_register_driver(&ines_pci_driver);
> <       if (err) {
> <               printk("ines_gpib: pci_driver_register failed!\n");
> <               return err;
> <       }
> <
> 723,724d706
> <
> <       pci_unregister_driver(&ines_pci_driver);
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] INES GPIB-PCI board: bugs in ver. 4.3.4 and above

[<tn...@gm...>]

Hello,

Since version 4.3.3, I am having problems with an INES GPIB-PCI board in Debian 11.7 (gcc 10.2.1).
The GPIB communication works fine in ver. 4.3.3, but in all the versions above it (4.3.4 to 4.3.6) the board is unresponsive.
The required drivers are nec7210 and ines, of which the first is unchanged (hence OK). As for ines (linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/ines), there are some changes from ver. 4.3.3 (working) to the following ones (not working) - see below.

Please check the modified code and, if possible, make it work again also in versions 4.3.4+

===========================

The output of lspci -vv is:

05:01.0 Communication controller: Advantech Co., Ltd. INES GPIB-PCI
	Subsystem: Advantech Co., Ltd. INES GPIB-PCI
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at df014000 (32-bit, non-prefetchable) [size=16K]
	Region 1: I/O ports at b100 [size=32]
	Kernel modules: ines_gpib



$ diff linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/ines/ines_cs.c linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/ines/ines_cs.c

294c294
< 	.name           = "ines_gpib_cs",
---
> 	.drv = { .name = "ines_gpib_cs", },



$ diff linux-gpib-4.3.6/linux-gpib-kernel-4.3.6/drivers/gpib/ines/ines_init.c linux-gpib-4.3.3/linux-gpib-kernel-4.3.3/drivers/gpib/ines/ines_init.c

675,684d674
< static int ines_pci_probe(struct pci_dev *dev, const struct pci_device_id *id) {
< 	return 0;
< }
<
< static struct pci_driver ines_pci_driver = {
< 	.name = "ines_gpib",
< 	.id_table = ines_pci_table,
< 	.probe = &ines_pci_probe
< };
<
689,694d678
< 	err = pci_register_driver(&ines_pci_driver);
< 	if (err) {
< 		printk("ines_gpib: pci_driver_register failed!\n");
< 		return err;
< 	}
<
723,724d706
<
< 	pci_unregister_driver(&ines_pci_driver);

[Linux-gpib-general] missing "System.map" and depmod skipped

[Saif M. <goe...@gm...>]

Hello,

 I am having trouble installing the linux gpib drivers on Ubuntu 22.04 LTS.
I was able to build using the make command but once I move on to the
install I get:
"Warning: modules_install: missing 'System.map' file. Skipping depmod."

 I am sure this is a common problem but I am not really familiar with it. I
also wanted to mention that I am not entirely sure I am doing all the
correct steps as I untar the downloaded tarball in the Downloads directory
and the install file mentioned a lot about having a copy of the kernel
source. I anticipate this might be one of those "building against a
different kernel" but I am hoping I could get some help.

Sincerely,
Saif Mostafa

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

Hi Dave, Everyone,

I have made some progress on the problem I have with linux-gpib on an 
82375B trying to
access an HP3478.  The problem was that if I sent the command "W1" to 
read a nibble
from the calibration memory, it would produce the correct value "@".  I 
could do this
repeatably, but if I sent an "W4" command, it would get the correct 
reply "F", but all
subsequent attempts would fail with the EBUS -14 error.

I had tracked this down to the agilent_82357a_take_control() using the 
AUX_TCS
command to assert the ATN signal and failing with a timeout.

Since I wrote last, I have tried to replicate the problem using the 
Keysight IO libraries.
The good news is that Keysight now has a version for Linux.  The bad 
news is that
they don't document how to configure it to work with PyVISA.  The PyVISA 
documentation
helped me figure out that I had to supply the path to the shared library but
didn't have the detail.  Eventually I found:

     rm = ResourceManager('/usr/lib/X86_64-linux-gnu/libivivisa.so.7.0.0')

It almost worked.  I would send the "W1" command to the HP3478 and get 
the meter
reading as the reply instead of the expected "@".  This was was 
repeatable except
for one time where it worked correctly and returned the "@".

I was able to get a bit of insight on what was going on by capturing the 
USB traffic
with usbmon and the interface to the driver using strace.  I think that 
the failure
to  read the correct "@" reply was the result of a secondary address 
being sent.
I used GPIB::22:INSTR, but it used GPIB::22::0::INSTR and sent an extra 
0x60 in the
command stream for secondary address 0.

The Keysight IO libraries include an opensource kernel driver.  It 
provides the
connection to USB but doesn't include the GPIB specific code.  I played with
sending commands directly using this driver and was able to send a "W1"
and get an "@" back.

I also came across this discussion of 82357 clones on eevblog:

https://www.eevblog.com/forum/testgear/flood-of-new-agilent-82357b-gpib-usb-adaptors-on-ebay-the-real-deal/200/

The creator of the Bieming GPIB interface said that the 82357B uses the 
NAT9914.
I had been thinking of hooking up the logic analyzer, but when I checked 
for the
power and ground signals, the pin numbers didn't match the NAT9914 data 
sheet.  The registers
described in the NAT9914 reference manual seemed to match up with things I
saw in the usbmon traces.  For example I saw reads from register offset 
4 which
doesn't exist in a TMS9914 but is ISR2 in the NAT9914.  The NAT9914 manual
also describes the initialization sequence including setting a register 
to select the
clock frequency.

After all of this I switched back to playing with the linux-gpib driver.
One of the differences I saw in the Keysight usbmon output was that they
always used the AUX_TCA command to assert ATN signal.  I hacked 
agilent_82357a_take_control
so that it always uses AUX_TCA and my problem is solved.

This leaves the problem of finding a solution which is acceptable for 
inclusion in
linux-gpib.  I suspect that most users don't understand what the sync 
option to
ibcac() does.  Setting sync to 1 means delaying setting ATN if the 
controller believes
that an IO is in progress.  The manual page for ibcac() says that if the 
synchronous
take control times out, that ATN is set immediately.  This is clearly 
not the case
with the agilent_82357a driver.

I'm having trouble imagining the case where this is useful to use the 
synchronous option
when sending a query to a device.  I would change the ibcac() call in
drivers/gpib/sys/ibcmd.c to specify sync as 0.

Jim Houston

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

Hi Dave,

I was premature in saying that the Agilent 82357B had healed itself.  I 
was able to read
the calibration data from the HP3478A with two different scripts. So far 
so good.

Then I got back to thinking about doing the ohms zero calibration and 
the HP3478A was
ignoring the  front panel reset command so I unplugged the Agilent 
82357B from the computer.
This got me back to local control.  When I plugged the Agilent 82357 
back into the computer
I'm back to having the original problem.

I did a few more repetitions of unplugging and plugging in the 82357 and 
the failure
case is much more likely than the working case.  I'm trying to workout a 
pattern.
I'm thinking it might have something to do with the order I powered 
things on.

I would understand if you are ready to write this off as flaky hardware.

Jim Houston

[Linux-gpib-general] Fwd: Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

I should have done reply all.  Then I tried forwarding the original 
message and the
syslog file was too large so I have trimmed it down to just the debug 
messages
from the script now included inline.


-------- Forwarded Message --------
Subject: 	Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure
Date: 	Sun, 30 Jul 2023 12:53:05 -0400
From: 	Jim Houston <ji...@ov...>
To: 	dave penkler <dpe...@gm...>





On 7/30/23 08:23, dave penkler wrote:
> Hi Jim,
> There does not seem to be any timing difference in the two read 
> sequences. However in both traces NRFD is de-asserted for about 8us 
> with different timing offsets, at 473us in gpib4.vcd and 308us in 
> gpib5.vcd, after the transfer of the "@" and "F" respectively. Not 
> sure why NRFD is being de-asserted.
> Is the 3478A the only instrument on the bus at the time ? Also just 
> to clarify: You do receive the "F" in ibterm normally and it is only 
> when sending another command you get the EBUS, or do you get the EBUS 
> on the read of the "F" already ? If you send "W1" repeatedly does it 
> work every time ?
> Sorry for all the questions.
> /d
>

Hi Dave,

I spent a few minutes cleaning up a script to reproduce the problem and 
capture ibsta() and lines()
output after each step.  It ran and didn't fail.  The 82357 has healed 
over night.

So we are dealing with the Agilent 82357B hardware failing in a subtle
way rather than a driver bug.

Since I have spent the time already I will try to answer your questions 
in case they
help someone else in the future.

The HP3478 was the only instrument and was directly connected to the 
Agilent 82357B
before I hooked up the logic analyzer.

I'm attaching syslog output from an earlier attempt along with the 
python script
I was using to reproduce the failure at the time.  I started with the 
script to read
the HP3478 calibration and it is using address values which are non 
printing character
so it isn't as clear as the "W1" vs "W4".  What I see is that the the 
write and read which
cause the failure look ok.  The ibsta() value after the read is 8448 decimal
0x2100 so CMPL and END set.

I'm guessing that the problem and  healing are the result humidity. I'm in
a slightly damp basement and I cranked up the dehumidifier yesterday.

Jim Houston

jhouston@yogi:~$ grep kmsg_ syslog4
Jul 26 16:26:06 t5610 kernel: [ 7295.152917] kmsg_write W
Jul 26 16:26:06 t5610 kernel: [ 7295.161677] kmsg_read resp=b'@'
Jul 26 16:26:06 t5610 kernel: [ 7295.161689] kmsg_ibsta sta=8448
Jul 26 16:26:06 t5610 kernel: [ 7295.161717] kmsg_write W
Jul 26 16:26:06 t5610 kernel: [ 7295.171308] kmsg_read resp=b'D'
Jul 26 16:26:06 t5610 kernel: [ 7295.171354] kmsg_ibsta sta=8448
Jul 26 16:26:06 t5610 kernel: [ 7295.171381] kmsg_write W
Jul 26 21:18:09 t5610 kernel: [ 7295.176033] kmsg_error write() failed: 
An attempt to write command bytes to the bus has timed out.

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

On 7/27/23 12:13, dave penkler wrote:
> It would be interesting to see if there is any timing difference 
> between the W1 and W4 write / read sequence with the logic analyser.
> You might want to try and run ibterm with the -N option. After sending 
> Wn hit enter again to trigger the read. Perhaps a short delay between 
> the write and read may have an effect.
> /d

Hi Dave, Everyone,

I got the logic analyzer hooked up and the transfers for "W1" and "W4" 
look the same to me.
I'm not sure what to try next.

I'm attaching the captured traces.  gpib4.vcd is the 'W1" command, 
gpib5.vcd is the "W4" command.
These are timing captures from  a HP 16702 analyzer with a 16556 card.  
I'm using an HP 10342B
HP-IB interface probe so this is trusted old school technology.

I have a python script to get the traces and  convert them to .vcd files 
which can be viewed
with GTKwave.

I had the 16556 card sampling at 100ns.  With the 1M sample depth this 
gives me 1/10 of a
second.  I decoded the traces by hand and I can see the "W1" command and 
the "@" response
and the "W4" command and the "F" response in the respective traces.
I might be missing something that happens outside my 1/10 second window 
or a glitch which
I miss by sampling at 10 MHz.

I did the test using ibterm and triggering the analyzer on a falling 
edge of DAV and data == A8
to match the W in the command.

I also tried triggering on the DAV falling edge and doing a "W1" command 
after the "W4".
The analyzer didn't trigger so I assume that the Agilent 82357B won't 
send commands
after the "W4" .

Jim Houston

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[dave p. <dpe...@gm...>]

It would be interesting to see if there is any timing difference between
the W1 and W4 write / read sequence with the logic analyser.
You might want to try and run ibterm with the -N option. After sending Wn
hit enter again to trigger the read. Perhaps a short delay between the
write and read may have an effect.
/d

On Wed, 26 Jul 2023 at 22:58, Jim Houston <ji...@ov...> wrote:

>
>
> On 7/26/23 09:01, dave penkler wrote:
>
> Hi,
> Judging from
> https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html
> it should work.
> What are you seeing on the console log ?
> /d
>
>
> Hi Dave,
>
> Thanks for getting back to me. I had seen that page.  I'm adding the
> mailing list back
> to the cc.
>
> I'm not sure if I have a bug or just subtly broken hardware.
>
> I didn't find anything obvious in the kernel logs.
> I have been slowly adding debug to the agilent_82357a driver.  The failure
> mode is a timeout
> in agilent_82357a_take_control().  It is going through the process of
> writing AUX_TCS  to the
> AUXCR register to set ATN and then looping the 10 times calling
> agilent_82357a_update_status()
> and not finding ATN set.  It returns the -ETIMEDOUT which becomes EBUS by
> the time it reaches
> the ibterm.  This is the state after I send the "W4" command with ibterm.
> It looks like the
> "W4" command works it responds with a "F" but all subsequent commands get
> the EBUS
> failure.
>
> It isn't obvious why the command being sent "W1" vs. "W4"
> would cause this failure.
>
> I have been looking for similar reports in the archives and notice the
> thread:
> *[Linux-gpib-general] Agilent 82350b can't recover from read timeout?
> <https://sourceforge.net/p/linux-gpib/mailman/message/36727912/>*
>
> https://sourceforge.net/p/linux-gpib/mailman/linux-gpib-general/thread/CAKrfojgY%2BEfzqo4e3vOEoC1vU0dEPnV_BrdDVuG1PJ%2BCHge_tw%40mail.gmail.com/#msg36730587
> I see that there are workarounds in tms9914_take_control and related
> drivers.
> I'm not sure if this problem would apply to the 82357B but I may try the
> workaround.
>
> I'm also thinking about getting out my logic analyzer.  I found a gpib
> cable with
> flying leads already hooked.
>
> Jim Houston
>
>
>
>
>
>

Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

On 7/26/23 09:01, dave penkler wrote:
> Hi,
> Judging from 
> https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html 
> it should work.
> What are you seeing on the console log ?
> /d

Hi Dave,

Thanks for getting back to me. I had seen that page.  I'm adding the 
mailing list back
to the cc.

I'm not sure if I have a bug or just subtly broken hardware.

I didn't find anything obvious in the kernel logs.
I have been slowly adding debug to the agilent_82357a driver.  The 
failure mode is a timeout
in agilent_82357a_take_control().  It is going through the process of 
writing AUX_TCS  to the
AUXCR register to set ATN and then looping the 10 times calling 
agilent_82357a_update_status()
and not finding ATN set.  It returns the -ETIMEDOUT which becomes EBUS 
by the time it reaches
the ibterm.  This is the state after I send the "W4" command with 
ibterm.  It looks like the
"W4" command works it responds with a "F" but all subsequent commands 
get the EBUS
failure.

It isn't obvious why the command being sent "W1" vs. "W4"
would cause this failure.

I have been looking for similar reports in the archives and notice the 
thread:
*[Linux-gpib-general] Agilent 82350b can't recover from read timeout? 
<https://sourceforge.net/p/linux-gpib/mailman/message/36727912/>*
https://sourceforge.net/p/linux-gpib/mailman/linux-gpib-general/thread/CAKrfojgY%2BEfzqo4e3vOEoC1vU0dEPnV_BrdDVuG1PJ%2BCHge_tw%40mail.gmail.com/#msg36730587
I see that there are workarounds in tms9914_take_control and related 
drivers.
I'm not sure if this problem would apply to the 82357B but I may try the
workaround.

I'm also thinking about getting out my logic analyzer.  I found a gpib 
cable with
flying leads already hooked.

Jim Houston

[Linux-gpib-general] Agilent 82357B repeatable hard failure

[Jim H. <ji...@ov...>]

Hi Everyone,

I have had mixed results using an Agilent 82357B with Ubuntu 22.04. I 
have had
success using it to capture screen prints from a Tektronix DSA602A scope.

When I tried to use it to backup the calibration data on an HP 3478A 
multi-meter
I got  a repeatable hard failure.  The process of reading the 
configuration data
sends commands like "W1" to the meter where the digit 1 in the example 
is a binary
byte value selecting which location in a 256 nibble ram to return. There 
are some
offset values which cause an immediate failure.  I can reproduce the 
failure using
ibterm.  I can send "W1" commands without problem but if I send a "W4" 
subsequent
commands will all receive EBUS errors.  I can recover from the failure 
by unplugging
and replugging the Agilent 82357B USB cable.

I have also tested with a Measurement Computing PCI GPIB interface and can
read the HP 3478A calibration correctly.

I'm posting here in the hope someone else has already solved this problem or
has suggestions on how to debug.

I would also be interested in hearing from anyone with the same setup
if they can reproduce the problem.

Jim Houston

Re: [Linux-gpib-general] Unsure why Agilent 82357B isn't working

[Michael K <vk...@ya...>]

I'm using Fedora, so this may be useful for Centos....

I packaged up linux-gpib into RPMs https://copr.fedorainfracloud.org/coprs/vk2bea/GPIB/ (based on the work of "vddvss" who stopped updating several years ago)

One of the RPMs is for the firmware load. (https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB/fedora-38-x86_64/05643738-linux-gpib-firmware/)
You can probably rebuild the srpm for your Centos version if the Fedora rpm doesn't work. (it should though)
It uses udev to load the firmware when the USB device is plugged in (through systemd)

$ cat /usr/lib/udev/rules.d/61-linux-gpib-firmware.rules
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GOTO="gpib_firmware_start"
GOTO="gpib_firmware_end"
LABEL="gpib_firmware_start"

# Agilent 82357A
ATTR{idVendor}=="0957", ATTR{idProduct}=="0007", ENV{SYSTEMD_WANTS}="linux-gpib-firmware-loader-agilent82357a@%N.service"
# Agilent 82357B
ATTR{idVendor}=="0957", ATTR{idProduct}=="0518", ENV{SYSTEMD_WANTS}="linux-gpib-firmware-loader-agilent82357b@%N.service"
# NI-USB-B and Keithley KUSB-488
ATTR{idVendor}=="3923", ATTR{idProduct}=="702b|713b", ENV{SYSTEMD_WANTS}="linux-gpib-firmware-loader-ni@%N.service"

LABEL="gpib_firmware_end"

cheers,

Michael





On Thursday, June 8, 2023 at 06:37:20 PM EDT, Brandon Gunn <bgu...@gm...> wrote: 





Hello,

I have been going crazy trying to get an Agilent 82357B GPIB adapter (probably a clone) working on our CentOS system. I have not done this before and am not a Linux pro, so please do not hesitate to ELI5.  

System:
CentOS 7.9.2009, Linux kernel 3.10


sudo fxload -t fx2 -D /dev/bus/usb/001/005 -I /usr/share/usb/agilent_82357a/measat_releaseX1.8.hex

produces the error: can't modify CPUCS: Connection timed out

***************************************

I tried adding a hotplug script but it does not seem to have any effect (there was no /etc/hotplug directory, I had to create it). 

**********************************
ibtest obviously fails, producing this error:

gpib status is:
ibsta = 0xc100  < ERR TIMO CMPL >
iberr= 14
EBUS 14: Bus error

ibcntl = 0

**************************

I am not sure what to try next -- any help would be greatly appreciated!

Thank you,
Brandon


_______________________________________________
Linux-gpib-general mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Unsure why Agilent 82357B isn't working

[Brandon G. <bgu...@gm...>]

Hello,

I have been going crazy trying to get an Agilent 82357B GPIB adapter
(probably a clone) working on our CentOS system. I have not done this
before and am not a Linux pro, so please do not hesitate to ELI5.

System:
CentOS 7.9.2009, Linux kernel 3.10

I have installed linux-gpib from this website, which seems to be specific
to RHEL and this adapter:
https://github.com/vddvss/linux-gpib-firmware-packaging

(Should I have installed linux-gpib differently?)

**************************************************************************

Here is the output of *lsusb*

Unknown line at line 24
Bus 002 Device 003: ID 05e3:0620 Genesys Logic, Inc.
Bus 002 Device 002: ID 05e3:0620 Genesys Logic, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0957:0718 Agilent Technologies, Inc.
Bus 001 Device 003: ID 09db:0127 Measurement Computing Corp.
Bus 001 Device 009: ID 03f0:1198 HP, Inc HID-compliant mouse
Bus 001 Device 008: ID 03f0:0024 HP, Inc KU-0316 Keyboard
Bus 001 Device 007: ID 8564:1000 Transcend Information, Inc. JetFlash
Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

**********************************************************

I do not have to load any modules, they are already loaded when I reboot.
Here is the output of *lsmod | grep agi*

agilent_82357a         24212  0
gpib_common            46771  1 agilent_82357a

************************************************************

Here is the output of *sudo dmesg | grep -i -e gpib -e agilent*

[    1.885507] usb 1-3: Manufacturer: Agilent Technologies, Inc.
[   11.728168] gpib_common: loading out-of-tree module taints kernel.
[   11.728257] gpib_common: module verification failed: signature and/or
required key missing - tainting kernel
[   11.728719] Linux-GPIB 4.2.0 Driver
[   11.730832] agilent_82357a_gpib driver loadingprobe succeeded for path:
usb-0000:00:14.0-3
[   11.730873] usbcore: registered new interface driver agilent_82357a_gpib
[   11.730875] gpib: registered agilent_82357a interface
[   19.176698] agilent_82357a_attach: attached
[  541.714436] gpib0: exiting autospoll thread
[  541.714542] agilent_82357a_detach: detached
[  541.717520] agilent_82357a_attach: attached


**************************************************************

Here are the uncommented portions of my *gpib.conf*

interface {
        minor = 0       /* board index, minor = 0 uses /dev/gpib0, minor =
1 uses /dev/gpib1, etc. */
        board_type = "agilent_82357a"   /* type of interface board being
used */
        name = "agi"    /* optional name, allows you to get a board
descriptor using ibfind() */
        pad = 0 /* primary address of interface             */
        sad = 0 /* secondary address of interface           */
        timeout = T3s   /* timeout for commands */

        eos = 0x0a      /* EOS Byte, 0xa is newline and 0xd is carriage
return */
        set-reos = yes  /* Terminate read if EOS */
        set-bin = no    /* Compare EOS 8-bit */
        set-xeos = no   /* Assert EOI whenever EOS byte is sent */
        set-eot = yes   /* Assert EOI with last byte on writes */

/* settings for boards that lack plug-n-play capability */
        base = 0        /* Base io ADDRESS                  */
        irq  = 0        /* Interrupt request level */
        dma  = 0        /* DMA channel (zero disables)      */

/* pci_bus and pci_slot can be used to distinguish two pci boards supported
by the same driver */
/*      pci_bus = 0 */
/*      pci_slot = 7 */

        master = yes    /* interface board is system controller */
}


device {
        minor = 0
        name = "hp3456a"
        pad = 22
        sad = 0
}

****************************************

Running *sudo gpib_config* executes without errors.

***************************************

I cannot load the firmware. Trying to execute:

*sudo fxload -t fx2 -D /dev/bus/usb/001/005 -I
/usr/share/usb/agilent_82357a/measat_releaseX1.8.hex*

produces the error: *can't modify CPUCS: Connection timed out*

***************************************

I tried adding a hotplug script but it does not seem to have any effect
(there was no /etc/hotplug directory, I had to create it).

**********************************
*ibtest *obviously fails, producing this error:

gpib status is:
ibsta = 0xc100  < ERR TIMO CMPL >
iberr= 14
EBUS 14: Bus error

ibcntl = 0

**************************

I am not sure what to try next -- any help would be greatly appreciated!

Thank you,
Brandon

Re: [Linux-gpib-general] Problem working with Python 3.10

[Wilhelm K. <ku...@t-...>]

Hi Chris,

I’m also using linux-gpib with Python3. To make that happen I did the 
following:
Open a terminal and go to the folder linux-gpib-4.3.5/linux-gpib-user-4.3.5
Input: /PYTHON=/usr/bin/python3 ./configure/
The messages that will then come should include the following lines:
/checking for headers required to compile python extensions... found/
and some later also:
/Python binding: yes/

If this is the case then you must compile linux-gpib again.

One remark: I also use Python-ivi from Alex Forencich to control 
gpib-devices with python, which I can highly recommend.

Good success

Wilhelm

Am 01.06.23 um 02:56 schrieb quips_roofing.0t--- via Linux-gpib-general:
> Hi Michael,
>
> Thanks for your response.
>
> Pip thinks the module is installed -
> pip list |grep gpib
> gpib              1.0
>
> However your test code gives me an import error -
>
> File "testing.py", line 6, in <module>
>     import gpib
> ModuleNotFoundError: No module named ‘gpib'
>
> Pip confirms the package is installed in by venv environment
>
> "Requirement already satisfied: gpib in 
> ./.venv/lib/python3.10/site-packages/gpib-1.0-py3.10-linux-x86_64.egg 
> (1.0)"
>
> Does the python import path have to be set someway to access the GPIB 
> install?
>
> Lin
> Regards,
> Chris
>
>> On 31 May 2023, at 9:31 am, Michael K via Linux-gpib-general 
>> <lin...@li...> wrote:
>>
>> What do you get when you run 'pip list'  ....
>> [michael@dirac ~]$ pip list |grep gpib
>> gpib                   1.0
>> [michael@dirac ~]$
>>
>> This is an test program that works for me (without any error messages)
>>
>> [michael@dirac ~]$ cat GPIBtest.py
>> #! /usr/bin/python3
>> ##
>> # Include the GPIB extension
>> ##
>> import gpib
>> ##
>> # find & initialize the device
>> ## (as defined in /etc/gpib.conf)
>> device = gpib.find("hp8753c")
>> ##
>> # write a string to the device
>> ##
>> gpib.write(device,"IDN?;")
>> ##
>> # read a 25 byte string
>> ##
>> result = gpib.read(device,30)
>> print ( 'Identifier is: ' + result.decode("ascii") )
>> [michael@dirac ~]$
>>
>> Where hp9753c is defined in /etc/gpib.conf as ..
>> device {
>>     minor    = 0            /* minor number for interface board this 
>> device is connected to */
>>     name     = "hp8753c"    /* device mnemonic */
>>     pad      = 16           /* The Primary Address */
>>     sad      = 0            /* Secondary Address */
>>
>>     eos      = 0xa          /* EOS Byte */
>>     set-reos = no           /* Terminate read if EOS */
>>     set-bin  = no           /* Compare EOS 8-bit */
>>     timeout  = T30s         /* timeout for commands */
>> }
>>
>>
>>
>> On Sunday, May 28, 2023 at 01:01:40 AM EDT, quips_roofing.0t--- via 
>> Linux-gpib-general <lin...@li...> wrote:
>>
>>
>> Hi all, attempting to use python3 with linux-ppib after successfully 
>> using C++.
>>
>>
>>
>> _______________________________________________
>> Linux-gpib-general mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] Problem working with Python 3.10

[<qui...@ic...>]

Hi Michael,

Thanks for your response. 

Pip thinks the module is installed -
pip list |grep gpib
gpib              1.0

However your test code gives me an import error -

File "testing.py", line 6, in <module>
    import gpib
ModuleNotFoundError: No module named ‘gpib'

Pip confirms the package is installed in by venv environment 

"Requirement already satisfied: gpib in ./.venv/lib/python3.10/site-packages/gpib-1.0-py3.10-linux-x86_64.egg (1.0)"

Does the python import path have to be set someway to access the GPIB install?

Lin
Regards,
Chris

> On 31 May 2023, at 9:31 am, Michael K via Linux-gpib-general <lin...@li...> wrote:
> 
> What do you get when you run 'pip list'  ....
> [michael@dirac ~]$ pip list |grep gpib
> gpib                   1.0
> [michael@dirac ~]$
> 
> This is an test program that works for me (without any error messages)
> 
> [michael@dirac ~]$ cat GPIBtest.py 
> #! /usr/bin/python3
> ##
> # Include the GPIB extension
> ##
> import gpib
> ##
> # find & initialize the device
> ## (as defined in /etc/gpib.conf)
> device = gpib.find("hp8753c")
> ##
> # write a string to the device
> ##
> gpib.write(device,"IDN?;")
> ##
> # read a 25 byte string
> ##
> result = gpib.read(device,30)
> print ( 'Identifier is: ' + result.decode("ascii") )
> [michael@dirac ~]$
> 
> Where hp9753c is defined in /etc/gpib.conf as ..
> device {
>     minor    = 0            /* minor number for interface board this device is connected to */
>     name     = "hp8753c"    /* device mnemonic */
>     pad      = 16           /* The Primary Address */
>     sad      = 0            /* Secondary Address */
> 
>     eos      = 0xa          /* EOS Byte */
>     set-reos = no           /* Terminate read if EOS */
>     set-bin  = no           /* Compare EOS 8-bit */
>     timeout  = T30s         /* timeout for commands */
> }
> 
> 
> 
> On Sunday, May 28, 2023 at 01:01:40 AM EDT, quips_roofing.0t--- via Linux-gpib-general <lin...@li...> wrote:
> 
> 
> Hi all, attempting to use python3 with linux-ppib after successfully using C++.
> 
> 
> 
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

Re: [Linux-gpib-general] Problem working with Python 3.10

[Michael K <vk...@ya...>]

 What do you get when you run 'pip list'  ....[michael@dirac ~]$ pip list |grep gpibgpib                   1.0[michael@dirac ~]$
This is an test program that works for me (without any error messages)
[michael@dirac ~]$ cat GPIBtest.py #! /usr/bin/python3### Include the GPIB extension##import gpib### find & initialize the device## (as defined in /etc/gpib.conf)device = gpib.find("hp8753c")### write a string to the device##gpib.write(device,"IDN?;")### read a 25 byte string##result = gpib.read(device,30)print ( 'Identifier is: ' + result.decode("ascii") )[michael@dirac ~]$
Where hp9753c is defined in /etc/gpib.conf as ..device {    minor    = 0            /* minor number for interface board this device is connected to */    name     = "hp8753c"    /* device mnemonic */    pad      = 16           /* The Primary Address */    sad      = 0            /* Secondary Address */
    eos      = 0xa          /* EOS Byte */    set-reos = no           /* Terminate read if EOS */    set-bin  = no           /* Compare EOS 8-bit */    timeout  = T30s         /* timeout for commands */}


    On Sunday, May 28, 2023 at 01:01:40 AM EDT, quips_roofing.0t--- via Linux-gpib-general <lin...@li...> wrote:  
 
 Hi all, attempting to use python3 with linux-ppib after successfully using C++.



  

[Linux-gpib-general] Problem working with Python 3.10

[<qui...@ic...>]

Hi all, attempting to use python3 with linux-ppib after successfully using C++.

Ran "python3 ./setup.py install” to install python egg in my virtual environment, then the running code that includes the linux-glib python code I get the error "ImportError: dynamic module does not define module export function (PyInit_Gpib)”.

Any ideas what I am doing wrong?




(.venv) user@ubuntu:/media/psf/Home/linux-gpib-4.3.5/linux-gpib-user-4.3.5/language/python$ "/media/psf/Home/.venv/bin/python" "/media/psf/Home/reform-v2.py"
Traceback (most recent call last):
File "/media/psf/Home/reform-v2.py", line 22, in <module>
  from dmm import DMM34401A
File "/media/psf/Home/dmm.py", line 3, in <module>
  import Gpib
File "/media/psf/Home/.venv/lib/python3.10/site-packages/gpib-1.0-py3.10-linux-x86_64.egg/Gpib.py", line 9, in <module>
File "/media/psf/Home/.venv/lib/python3.10/site-packages/gpib-1.0-py3.10-linux-x86_64.egg/Gpib.py", line 7, in __bootstrap__
ImportError: dynamic module does not define module export function (PyInit_Gpib)

Re: [Linux-gpib-general] [EXTERNAL] Re: GPIB as a pure slave

[Vladimir V. <vla...@li...>]

Hi Marcello,

On 08.05.2023 16:06, marcello.carla wrote:
> Dear Vladimir,
>
> my previous mail was not completely correct from a technical point
> of view. Written somewhat in a hurry, it contains some non linear
> mix about asserting/releasing signals that on the GPIB bus follow
> a negative logic and go easily confused. I apologize. Ignore that
> part.


Its a good start.


>
> Your new ice4pi board,a cheap FPGA front-end to the RPi, is very
> very interesting for many applications.


I think so too.  Slave interface for Raspberry Pi based instruments was 
our initial goal but we decided to split the board in a FPGA only 
Raspberry Pi Zero shield and  bitbang pin compatible gpib4pi keeping an 
empty space on the gpib4pi so that merging the 2 boards later would be 
trivial.


>
> An external FPGA certainly can fulfil the requirement that a device
> must be ready to receive commands within 200 ns from ATN, the kind
> of thing impossible to the software.
>
> Yet, I have not clear what are the performances you want from a gpib
> "device". Maybe, a simple "listener" or "talker" is more easily
> implemented fully in the FPGA, rather than being split FPGA/RPi.
>
> To this purpose, Frank's code might be used as a guideline, for the
> pertinent part.


Definitely. He has implemented a classic UPD7210C chip. I wonder if a 
serialization of the register interface including the DMA FIFOs is 
possible using SPI. With one gateware you could get bitbang adapter and 
with another one UPD7210C type adapter over SPI.


>
> Unfortunately, my experience with programmable logic is rather scarce.
> What support is available to program your board

Not sure I got your question. But I am using yosys to synthesize 
gateware for the board and you could reload the flash over SP (all tools 
part of Debian). One application we already use is a GPIB 
analyzer/sniffer where we replace the  SN75160BN/SN75161BN drivers with 
resistor arrays and read all 16 bits of the GPIB interface streaming it 
over SPI back to the Raspberry Pi.

/Vladimir

>
> Ciao
>
> Marcello
>
>
>
>
>
>
> On 5/8/23 12:28 PM, Vladimir Vassilev wrote:
>> Hi,
>>
>> On 20.02.2023 19:00, marcello.carla wrote:
>>> Dear Dave and Vladimir,
>>>
>>> the use of the bitbang as a slave has been considered already,
>>> several times.
>>>
>>> The 200 ns limit:
>>>
>>> Not to respect the standard in the hope that the master might
>>> be tolerant, in my opinion, is not a good idea. A possible
>>> scenario is: a third device on the bus, while not having part
>>> in the transaction between the master and the bitbang, shall
>>> anyway handle the NRFD and NDAC in response to ATN, hiding the
>>> bitbang delay. Everything will work fine. You switch off the
>>> third device that was not in use and nothing works anymore.
>>> Really a nightmare I want avoid. Absolutely.
>>>
>>> The 200 ns is not an insurmountable limit. It is compatible with
>>> the protocol for the bitbang to assert NRFD and NDAC **before**
>>> ATN is asserted. But this requires the bitbang to remain always
>>> listener for any transaction, waiting for the unlisten/untalk
>>> command. This would slow down every device on the bus to the
>>> bitbang speed. And I am not sure 100% it will work. Should a
>>> transaction terminate without an unlisten/untalk command, the
>>> bitbang would be late to respond to next ATN request.
>>>
>>> This procedure might be worth a (not easy) try if there is some
>>> really **good** and **convincing** reason to have the bitbang
>>> to behave as a device instead of a controller. Frankly speaking,
>>> I do not see a lot of possible use for that.
>>>
>>> In any case, if such a driver is viable, It should be considered
>>> implementing it on a microprocessor, e.g. an rp2040 as a pure
>>> slave, instead of adding that function to the bitbang on RPi.
>>> If you want to add the gpib interface to an instrument you are
>>> designing, it is a more convenient solution.
>>>
>>> Clearly, adding some hardware to the RPi can solve every problem.
>>> But the nice of the bitbang driver is that its use is very tidy:
>>> only code and wires, or, at most, the SN75* board.
>>>
>>> An FPGA is an excellent solution. If I am not wrong, Frank
>>> Mori-Hess has already written the "code" for that.
>>>
>>> Your opinion?
>>
>>
>> This is a heavy DMA based implementation that requires a proper AXI
>> bus and I do not see how we can use this with Raspberry Pi and the
>> bitbang driver. I was thinking of adding a transparent FPGA and keep
>> the simplicity of the bitbang solution except for handling the 200 ns
>> limit. We are working on combining this 2 boards
>> https://certification.oshwa.org/no000002.html and
>> https://certification.oshwa.org/no000003.html
>>
>>
>> Sorry for the late reply,
>>
>> /Vladimir
>>
>>
>>>
>>> Marcello
>>>
>>>
>>>
>>> On 2/19/23 3:44 PM, Vladimir Vassilev wrote:
>>>> On 19.02.2023 14:38, dave penkler wrote:
>>>>> It depends, (as usual). At all times when ATN is asserted the slave
>>>>> needs to listen to the command sequence and handle TACS/LACS state
>>>>> machine. But the slave needs to respond in  < 200ns to ATN from the
>>>>> controller which is not possible to guarantee with standard linux
>>>>> on RPI.
>>>>> I only have a elektronomikon board with  SN75161B which cannot be
>>>>> non CIC. But we can give it a try if perhaps Marcello is willing
>>>>> and  can test with his board without SN7516x drivers.
>>>>
>>>>
>>>> On a sidenote we have started shipping the gpib4pi-2.x boards with
>>>> 2x 8 100 ohm resistor arrays
>>>> https://no.mouser.com/ProductDetail/Bourns/4108R-1-101 which enables
>>>> one to replace the drivers and get "board_id=barewire" from every
>>>> board with drivers. And yes in the 2.0 version we switched back to
>>>> the elektronomikon pinout - Fixed the blunder. Now gpio27 (instead
>>>> of gpio0) is again connected to REN
>>>> https://github.com/lightside-instruments/ice4pi/commit/ccf248850e63b92a82b35db0839ac3962579bffc. 
>>>>
>>>> There are 20 boards with the gpib4pi-1.1 layout using the special
>>>> driver mode patch sold and 12 we use internally.
>>>>
>>>> It would be very useful if the bitbang driver can be used by slaves
>>>> emulating GPIB devices. Count me in for any help I can provide with
>>>> this work.
>>>>
>>>> Even if the standard 200 ns ATN acknowledge timeout is violated my
>>>> hope is a lot of masters will have higher tolerance. If you ignore
>>>> the ATN timeout my understanding is the rest of the communication is
>>>> handshake based that can be implemented with sub-microsecond or even
>>>> sub-millisecond response delays.
>>>>
>>>> Alternatively a programmable logic device (FPGA) connected to all
>>>> pins of the Raspberry Pi can be used together with the GPIB bitbang
>>>> board - but I hope this can be an option and not a requirement for
>>>> the most usecases.
>>>>
>>>> /Vladimir
>>>>
>>>>
>>>>
>>>>> cheers,
>>>>> -Dave
>>>>>
>>>>> On Sun, 19 Feb 2023 at 13:28, Vladimir Vassilev
>>>>> <vla...@li...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     -------- Forwarded Message --------
>>>>>     Subject:        Re: [Linux-gpib-general] [EXTERNAL] Re: GPIB as a
>>>>>     pure slave
>>>>>     Date:   Sun, 19 Feb 2023 13:27:59 +0100
>>>>>     From:   Vladimir Vassilev <vla...@li...>
>>>>>     To:     marcello.carla <mar...@gm...>
>>>>>
>>>>>
>>>>>
>>>>>     How difficult would it be to add support for a slave device
>>>>>     functionality to the driver?
>>>>>
>>>>>     /Vladimir
>>>>>
>>>>>     On 18.02.2023 08:52, marcello.carla wrote:
>>>>>     > I am sorry, the gpib_bitbang was not designed
>>>>>     > to work as a slave device and currently lacks
>>>>>     > most of the functionalities required to that
>>>>>     > purpose.
>>>>>     >
>>>>>     > Marcello
>>>>>     >
>>>>>     >
>>>>>     >
>>>>>     > On 2/18/23 4:13 AM, Vladimir Vassilev wrote:
>>>>>     >> Hi Dave and Marcello,
>>>>>     >>
>>>>>     >> Should this slave_test work with the |gpib_bitbang
>>>>>     board_id=barewire
>>>>>     >> board?|
>>>>>     >>
>>>>>     >> |I just tested with 2 gpib_bitbang boards and did not get
>>>>> response
>>>>>     >> from the slave device.
>>>>>     >> |
>>>>>     >>
>>>>>     >> |/Vladimir|
>>>>>     >>
>>>>>     >> |
>>>>>     >> |
>>>>>     >>
>>>>>     >> On 16.01.2023 14:01, dave penkler wrote:
>>>>>     >>> Hi Stefan,
>>>>>     >>> It looks like in your case the slave board was already
>>>>>     addressed as
>>>>>     >>> a listener before you started slave_test which is why you
>>>>> got the
>>>>>     >>> timeout.
>>>>>     >>> Here is a new version that deals with this case. It loops
>>>>>     until it
>>>>>     >>> reads a string when addressed as a listener and then writes
>>>>> back
>>>>>     >>> that string when addressed as talker. If the read times 
>>>>> out it
>>>>>     >>> prints "read timeout" and goes back to the loop.
>>>>>     >>> On the master side once a string has been written the 
>>>>> response
>>>>>     must
>>>>>     >>> be read before writing another. Are you using ibterm on the
>>>>>     master
>>>>>     >>> or something else ?
>>>>>     >>>
>>>>>     >>> $ ./slave_test2
>>>>>     >>> read timeout
>>>>>     >>> read timeout
>>>>>     >>> Got hello
>>>>>     >>> Got bye
>>>>>     >>> Got quit
>>>>>     >>> slave done
>>>>>     >>> $
>>>>>     >>>
>>>>>     >>> cheers,
>>>>>     >>> -Dave
>>>>>     >>>
>>>>>     >>> On Sun, 15 Jan 2023 at 09:46, Stefan Olejnik
>>>>>     >>> <ste...@jh...> wrote:
>>>>>     >>>
>>>>>     >>>      Hi, Dave
>>>>>     >>>
>>>>>     >>>     Thanks a lot for Your effort.
>>>>>     >>>
>>>>>     >>>     I have tested Your program, but it is almost the same 
>>>>> as I
>>>>>     have
>>>>>     >>>     used. The result are as follows:
>>>>>     >>>
>>>>>     >>> root@imx8mm-var-dart:/home/stefan/bin#
>>>>>     >>> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test
>>>>>     >>>     [  124.896503] tnt4882: minor 0 read timed out
>>>>>     >>>     [  124.900712] tnt4882: read timed out
>>>>>     >>>     Got hello
>>>>>     >>>     [  127.968496] tnt4882: write timed out
>>>>>     >>>     error: ibwrt fail
>>>>>     >>>      - EABO 6: Operation aborted
>>>>>     >>> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test
>>>>>     >>>     [  187.105354] tnt4882: minor 0 read timed out
>>>>>     >>>     [  187.109563] tnt4882: read timed out
>>>>>     >>>     Got *IDN?
>>>>>     >>>
>>>>>     >>>     [  190.177371] tnt4882: write timed out
>>>>>     >>>     error: ibwrt fail
>>>>>     >>>      - EABO 6: Operation aborted
>>>>>     >>> root@imx8mm-var-dart:/home/stefan/bin#
>>>>>     >>>
>>>>>     >>>     READING:
>>>>>     >>>
>>>>>     >>>     Interesting is that during "ibrd" even read timeout is
>>>>>     coming from
>>>>>     >>>     TNT4882, the data are read OK. I am using reading per
>>>>>     char, till
>>>>>     >>>     END or END-OF-STRING => "\n" and I am getting no time-out
>>>>>     during
>>>>>     >>>     reading.
>>>>>     >>>
>>>>>     >>>     WRITTING:
>>>>>     >>>
>>>>>     >>>     First "ibwrt" is always time-outed, the second also, but
>>>>>     data are
>>>>>     >>>     delivered, as I am already described. Therefore I am 
>>>>> using
>>>>>     short
>>>>>     >>>     TIMO ( e.g. 10ms ) for ibwrt, and on the receiver device
>>>>>     is TIMO
>>>>>     >>>     set to 3s, and I am getting the data. Of course from
>>>>>     second "ibwrt".
>>>>>     >>>
>>>>>     >>>     Stefan.
>>>>>     >>>
>>>>>     >>>
>>>>>     >>>
>>>>>     >>>
>>>>>     >>> _______________________________________________
>>>>>     >>> Linux-gpib-general mailing list
>>>>>     >>> Lin...@li...
>>>>>     >>>
>>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>>     >
>>>>>
>>>
>

Re: [Linux-gpib-general] [EXTERNAL] Re: GPIB as a pure slave

[marcello.carla <mar...@gm...>]

Dear Vladimir,

my previous mail was not completely correct from a technical point
of view. Written somewhat in a hurry, it contains some non linear
mix about asserting/releasing signals that on the GPIB bus follow
a negative logic and go easily confused. I apologize. Ignore that
part.

Your new ice4pi board,a cheap FPGA front-end to the RPi, is very
very interesting for many applications.

An external FPGA certainly can fulfil the requirement that a device
must be ready to receive commands within 200 ns from ATN, the kind
of thing impossible to the software.

Yet, I have not clear what are the performances you want from a gpib
"device". Maybe, a simple "listener" or "talker" is more easily
implemented fully in the FPGA, rather than being split FPGA/RPi.

To this purpose, Frank's code might be used as a guideline, for the
pertinent part.

Unfortunately, my experience with programmable logic is rather scarce.
What support is available to program your board?

Ciao

Marcello






On 5/8/23 12:28 PM, Vladimir Vassilev wrote:
> Hi,
>
> On 20.02.2023 19:00, marcello.carla wrote:
>> Dear Dave and Vladimir,
>>
>> the use of the bitbang as a slave has been considered already,
>> several times.
>>
>> The 200 ns limit:
>>
>> Not to respect the standard in the hope that the master might
>> be tolerant, in my opinion, is not a good idea. A possible
>> scenario is: a third device on the bus, while not having part
>> in the transaction between the master and the bitbang, shall
>> anyway handle the NRFD and NDAC in response to ATN, hiding the
>> bitbang delay. Everything will work fine. You switch off the
>> third device that was not in use and nothing works anymore.
>> Really a nightmare I want avoid. Absolutely.
>>
>> The 200 ns is not an insurmountable limit. It is compatible with
>> the protocol for the bitbang to assert NRFD and NDAC **before**
>> ATN is asserted. But this requires the bitbang to remain always
>> listener for any transaction, waiting for the unlisten/untalk
>> command. This would slow down every device on the bus to the
>> bitbang speed. And I am not sure 100% it will work. Should a
>> transaction terminate without an unlisten/untalk command, the
>> bitbang would be late to respond to next ATN request.
>>
>> This procedure might be worth a (not easy) try if there is some
>> really **good** and **convincing** reason to have the bitbang
>> to behave as a device instead of a controller. Frankly speaking,
>> I do not see a lot of possible use for that.
>>
>> In any case, if such a driver is viable, It should be considered
>> implementing it on a microprocessor, e.g. an rp2040 as a pure
>> slave, instead of adding that function to the bitbang on RPi.
>> If you want to add the gpib interface to an instrument you are
>> designing, it is a more convenient solution.
>>
>> Clearly, adding some hardware to the RPi can solve every problem.
>> But the nice of the bitbang driver is that its use is very tidy:
>> only code and wires, or, at most, the SN75* board.
>>
>> An FPGA is an excellent solution. If I am not wrong, Frank
>> Mori-Hess has already written the "code" for that.
>>
>> Your opinion?
>
>
> This is a heavy DMA based implementation that requires a proper AXI
> bus and I do not see how we can use this with Raspberry Pi and the
> bitbang driver. I was thinking of adding a transparent FPGA and keep
> the simplicity of the bitbang solution except for handling the 200 ns
> limit. We are working on combining this 2 boards
> https://certification.oshwa.org/no000002.html and
> https://certification.oshwa.org/no000003.html
>
>
> Sorry for the late reply,
>
> /Vladimir
>
>
>>
>> Marcello
>>
>>
>>
>> On 2/19/23 3:44 PM, Vladimir Vassilev wrote:
>>> On 19.02.2023 14:38, dave penkler wrote:
>>>> It depends, (as usual). At all times when ATN is asserted the slave
>>>> needs to listen to the command sequence and handle TACS/LACS state
>>>> machine. But the slave needs to respond in  < 200ns to ATN from the
>>>> controller which is not possible to guarantee with standard linux
>>>> on RPI.
>>>> I only have a elektronomikon board with  SN75161B which cannot be
>>>> non CIC. But we can give it a try if perhaps Marcello is willing
>>>> and  can test with his board without SN7516x drivers.
>>>
>>>
>>> On a sidenote we have started shipping the gpib4pi-2.x boards with
>>> 2x 8 100 ohm resistor arrays
>>> https://no.mouser.com/ProductDetail/Bourns/4108R-1-101 which enables
>>> one to replace the drivers and get "board_id=barewire" from every
>>> board with drivers. And yes in the 2.0 version we switched back to
>>> the elektronomikon pinout - Fixed the blunder. Now gpio27 (instead
>>> of gpio0) is again connected to REN
>>> https://github.com/lightside-instruments/ice4pi/commit/ccf248850e63b92a82b35db0839ac3962579bffc.
>>> There are 20 boards with the gpib4pi-1.1 layout using the special
>>> driver mode patch sold and 12 we use internally.
>>>
>>> It would be very useful if the bitbang driver can be used by slaves
>>> emulating GPIB devices. Count me in for any help I can provide with
>>> this work.
>>>
>>> Even if the standard 200 ns ATN acknowledge timeout is violated my
>>> hope is a lot of masters will have higher tolerance. If you ignore
>>> the ATN timeout my understanding is the rest of the communication is
>>> handshake based that can be implemented with sub-microsecond or even
>>> sub-millisecond response delays.
>>>
>>> Alternatively a programmable logic device (FPGA) connected to all
>>> pins of the Raspberry Pi can be used together with the GPIB bitbang
>>> board - but I hope this can be an option and not a requirement for
>>> the most usecases.
>>>
>>> /Vladimir
>>>
>>>
>>>
>>>> cheers,
>>>> -Dave
>>>>
>>>> On Sun, 19 Feb 2023 at 13:28, Vladimir Vassilev
>>>> <vla...@li...> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>     -------- Forwarded Message --------
>>>>     Subject:        Re: [Linux-gpib-general] [EXTERNAL] Re: GPIB as a
>>>>     pure slave
>>>>     Date:   Sun, 19 Feb 2023 13:27:59 +0100
>>>>     From:   Vladimir Vassilev <vla...@li...>
>>>>     To:     marcello.carla <mar...@gm...>
>>>>
>>>>
>>>>
>>>>     How difficult would it be to add support for a slave device
>>>>     functionality to the driver?
>>>>
>>>>     /Vladimir
>>>>
>>>>     On 18.02.2023 08:52, marcello.carla wrote:
>>>>     > I am sorry, the gpib_bitbang was not designed
>>>>     > to work as a slave device and currently lacks
>>>>     > most of the functionalities required to that
>>>>     > purpose.
>>>>     >
>>>>     > Marcello
>>>>     >
>>>>     >
>>>>     >
>>>>     > On 2/18/23 4:13 AM, Vladimir Vassilev wrote:
>>>>     >> Hi Dave and Marcello,
>>>>     >>
>>>>     >> Should this slave_test work with the |gpib_bitbang
>>>>     board_id=barewire
>>>>     >> board?|
>>>>     >>
>>>>     >> |I just tested with 2 gpib_bitbang boards and did not get
>>>> response
>>>>     >> from the slave device.
>>>>     >> |
>>>>     >>
>>>>     >> |/Vladimir|
>>>>     >>
>>>>     >> |
>>>>     >> |
>>>>     >>
>>>>     >> On 16.01.2023 14:01, dave penkler wrote:
>>>>     >>> Hi Stefan,
>>>>     >>> It looks like in your case the slave board was already
>>>>     addressed as
>>>>     >>> a listener before you started slave_test which is why you
>>>> got the
>>>>     >>> timeout.
>>>>     >>> Here is a new version that deals with this case. It loops
>>>>     until it
>>>>     >>> reads a string when addressed as a listener and then writes
>>>> back
>>>>     >>> that string when addressed as talker. If the read times out it
>>>>     >>> prints "read timeout" and goes back to the loop.
>>>>     >>> On the master side once a string has been written the response
>>>>     must
>>>>     >>> be read before writing another. Are you using ibterm on the
>>>>     master
>>>>     >>> or something else ?
>>>>     >>>
>>>>     >>> $ ./slave_test2
>>>>     >>> read timeout
>>>>     >>> read timeout
>>>>     >>> Got hello
>>>>     >>> Got bye
>>>>     >>> Got quit
>>>>     >>> slave done
>>>>     >>> $
>>>>     >>>
>>>>     >>> cheers,
>>>>     >>> -Dave
>>>>     >>>
>>>>     >>> On Sun, 15 Jan 2023 at 09:46, Stefan Olejnik
>>>>     >>> <ste...@jh...> wrote:
>>>>     >>>
>>>>     >>>      Hi, Dave
>>>>     >>>
>>>>     >>>     Thanks a lot for Your effort.
>>>>     >>>
>>>>     >>>     I have tested Your program, but it is almost the same as I
>>>>     have
>>>>     >>>     used. The result are as follows:
>>>>     >>>
>>>>     >>>     root@imx8mm-var-dart:/home/stefan/bin#
>>>>     >>>     root@imx8mm-var-dart:/home/stefan/bin# ./slave_test
>>>>     >>>     [  124.896503] tnt4882: minor 0 read timed out
>>>>     >>>     [  124.900712] tnt4882: read timed out
>>>>     >>>     Got hello
>>>>     >>>     [  127.968496] tnt4882: write timed out
>>>>     >>>     error: ibwrt fail
>>>>     >>>      - EABO 6: Operation aborted
>>>>     >>>     root@imx8mm-var-dart:/home/stefan/bin# ./slave_test
>>>>     >>>     [  187.105354] tnt4882: minor 0 read timed out
>>>>     >>>     [  187.109563] tnt4882: read timed out
>>>>     >>>     Got *IDN?
>>>>     >>>
>>>>     >>>     [  190.177371] tnt4882: write timed out
>>>>     >>>     error: ibwrt fail
>>>>     >>>      - EABO 6: Operation aborted
>>>>     >>>     root@imx8mm-var-dart:/home/stefan/bin#
>>>>     >>>
>>>>     >>>     READING:
>>>>     >>>
>>>>     >>>     Interesting is that during "ibrd" even read timeout is
>>>>     coming from
>>>>     >>>     TNT4882, the data are read OK. I am using reading per
>>>>     char, till
>>>>     >>>     END or END-OF-STRING => "\n" and I am getting no time-out
>>>>     during
>>>>     >>>     reading.
>>>>     >>>
>>>>     >>>     WRITTING:
>>>>     >>>
>>>>     >>>     First "ibwrt" is always time-outed, the second also, but
>>>>     data are
>>>>     >>>     delivered, as I am already described. Therefore I am using
>>>>     short
>>>>     >>>     TIMO ( e.g. 10ms ) for ibwrt, and on the receiver device
>>>>     is TIMO
>>>>     >>>     set to 3s, and I am getting the data. Of course from
>>>>     second "ibwrt".
>>>>     >>>
>>>>     >>>     Stefan.
>>>>     >>>
>>>>     >>>
>>>>     >>>
>>>>     >>>
>>>>     >>> _______________________________________________
>>>>     >>> Linux-gpib-general mailing list
>>>>     >>> Lin...@li...
>>>>     >>>
>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>     >
>>>>
>>