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

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

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

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] Problems with Electronomikon gpib_bitbang

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

Dear Chris,

the debug can be activated with:

sudo modprobe gpib_bitbang debug=1

or, if the module is already running:

sudo su
echo 1 > /sys/module/gpib_bitbang/parameters/debug
Ctrl-D

Use 2 or 3 instead of 1 for a higher debug level;
0 to disable.

Let me know and good luck

Marcello




On 2/21/23 12:42 PM, quips_roofing.0t--- via Linux-gpib-general wrote:
> Hi all,
> I’m having trouble getting any results using a electronomikon GPIB hat on a Pi. I have tried two different interface boards, two different Pis (a Pi3 and Pi4), different devices and different cables. I figure the problem is therefore with my driver setup or commands.
>
> I’m running the r2048 branch, locally compiled.
>
> My /usr/local/etc/gpib.conf  config file is -
>
> <code>
>
> interface {
> 	minor = 0			/* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
> 	board_type = "gpib_bitbang"	/* name of the driver */
> 	name = "raspi_gpio_interface"	/* optional name, allows you to get a board descriptor using ibfind() */
> 	pad = 0				/* primary address of interface             */
> 	sad = 0				/* secondary address of interface           */
> 	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 */
> 	timeout = T30s
> /* 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)      */
>
> 	master = yes	/* interface board is system controller */
> }
>
>
> device {
> 	minor = 0
>       name = "SolartronDMM"
>       pad = 7
>       eos = 0x0a
>       set-reos = yes
>       set-bin = no
> 	timeout = T30s
> }
>
> </code>
>
> Syslog shows driver loading -
> <code>
> Feb 21 21:40:22 GPIB01 kernel: [   64.307958] gpib_common: loading out-of-tree module taints kernel.
> Feb 21 21:40:22 GPIB01 kernel: [   64.310725] Linux-GPIB 4.3.5 Driver
> Feb 21 21:40:22 GPIB01 kernel: [   64.336055] gpib: registered gpib_bitbang interface
> Feb 21 21:40:22 GPIB01 kernel: [   64.336083] gpib_bitbang:bb_init_module - module loaded with pin map "elektronomikon" and SN7516x driver support
> Feb 21 21:40:36 GPIB01 kernel: [   78.563879] gpib_bitbang:bb_attach - Using pin map "elektronomikon"  with SN7516x driver support
> Feb 21 21:40:36 GPIB01 kernel: [   78.564627] gpib_bitbang:bb_attach - attached board: 0
> </code>
>
> Using the glib utility -
> <code>
>
> sudo modprobe gpib_bitbang sn7516x_used=1
>
> pi@GPIB01:~ $ sudo ibterm -d 7 -e 10 -r 1 -N -i -x
>
> Attempting to open /dev/gpib0
> pad = 7, sad = 0, timeout = 10, send_eoi = 0, eos_mode = 0x040a
> ibterm>*IDN?
> ibterm error: Unable to write to device at pad 7
>
> - ENOL 2: No listeners
> ibterm>
> InternalReceiveSetup: command failed
> ibterm error: Failed during read from device at pad 7
>
> - ENOL 2: No listeners
>
> </code>
>
> Device is currently a solartron 7150 multimeter but have used other miscellaneous HP equipment as well. Device confirms its address is 7 on startup.
>
> I’ve also attempted a basic
>
> interm -d 7
>
> Both LEDs on the board are illuminated but neither change during commanding.
>
> Any advice as to how to debug? Am I using the correct EOS mode?
>
> Thanks,
> Chris
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Problems with Electronomikon gpib_bitbang

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

Hi all,
I’m having trouble getting any results using a electronomikon GPIB hat on a Pi. I have tried two different interface boards, two different Pis (a Pi3 and Pi4), different devices and different cables. I figure the problem is therefore with my driver setup or commands.

I’m running the r2048 branch, locally compiled.

My /usr/local/etc/gpib.conf  config file is -

<code>

interface {
	minor = 0			/* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
	board_type = "gpib_bitbang"	/* name of the driver */
	name = "raspi_gpio_interface"	/* optional name, allows you to get a board descriptor using ibfind() */
	pad = 0				/* primary address of interface             */
	sad = 0				/* secondary address of interface           */
	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 */
	timeout = T30s
/* 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)      */

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


device {
	minor = 0
     name = "SolartronDMM"
     pad = 7
     eos = 0x0a
     set-reos = yes
     set-bin = no
	timeout = T30s
}

</code>

Syslog shows driver loading -
<code>
Feb 21 21:40:22 GPIB01 kernel: [   64.307958] gpib_common: loading out-of-tree module taints kernel.
Feb 21 21:40:22 GPIB01 kernel: [   64.310725] Linux-GPIB 4.3.5 Driver
Feb 21 21:40:22 GPIB01 kernel: [   64.336055] gpib: registered gpib_bitbang interface
Feb 21 21:40:22 GPIB01 kernel: [   64.336083] gpib_bitbang:bb_init_module - module loaded with pin map "elektronomikon" and SN7516x driver support
Feb 21 21:40:36 GPIB01 kernel: [   78.563879] gpib_bitbang:bb_attach - Using pin map "elektronomikon"  with SN7516x driver support
Feb 21 21:40:36 GPIB01 kernel: [   78.564627] gpib_bitbang:bb_attach - attached board: 0
</code>

Using the glib utility -
<code>

sudo modprobe gpib_bitbang sn7516x_used=1

pi@GPIB01:~ $ sudo ibterm -d 7 -e 10 -r 1 -N -i -x

Attempting to open /dev/gpib0
pad = 7, sad = 0, timeout = 10, send_eoi = 0, eos_mode = 0x040a
ibterm>*IDN?
ibterm error: Unable to write to device at pad 7

- ENOL 2: No listeners
ibterm>
InternalReceiveSetup: command failed
ibterm error: Failed during read from device at pad 7

- ENOL 2: No listeners

</code>

Device is currently a solartron 7150 multimeter but have used other miscellaneous HP equipment as well. Device confirms its address is 7 on startup.

I’ve also attempted a basic 

interm -d 7

Both LEDs on the board are illuminated but neither change during commanding.

Any advice as to how to debug? Am I using the correct EOS mode? 

Thanks,
Chris

Re: [Linux-gpib-general] Making the linux-gpib pc a server

[Jakub L. <la...@vo...>]

Hi Dale,

As you mentioned VXI-11, i have returned to previously found link 
https://git.loetlabor-jena.de/thasti/tcpip2instr

(I was not aware of existence of VXI-11 protocol, so you gave me a good 
keyword to match)

Unfortunately it does not work due to bug in python code which I can't 
fix by myself.

Maybe you'd like to have a look.

Best regards

Jakub Ladman

Re: [Linux-gpib-general] Making the linux-gpib pc a server

[Dale S. <dal...@gm...>]

I’ve been (slowly) working on a VXI-11 implementation that uses linux-gpib.
Nothing released yet. 

I’ll see if I can finish it up in the next week.

Anything that can use visa should be able to talk to it.  

Sent from my iPhone...
Beware of typos!

> On Feb 12, 2023, at 5:05 AM, Jakub Ladman <la...@vo...> wrote:
> 
> Hello
> 
> After I stopped messing around GPIB-USB-HS incompatible clone, I've got Agilent PCI device (82530A) and it works perfectly.
> 
> Because it's plugged into other computer and i want to access it from my notebook, I am searching for the right way (or the most optimal) to make the computer with the actual device a server.
> 
> I would like to make it accessible it from octave, matlab, python, julia, if possible.
> 
> The only way I know for now is to connect via ssh to the "server" console and run the code there, which is not the preferred way for me.
> 
> How are you doing such thing?
> 
> Thank you
> 
> Jakub Ladman
> 
> 
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Making the linux-gpib pc a server

[Jakub L. <la...@vo...>]

Hello

After I stopped messing around GPIB-USB-HS incompatible clone, I've got 
Agilent PCI device (82530A) and it works perfectly.

Because it's plugged into other computer and i want to access it from my 
notebook, I am searching for the right way (or the most optimal) to make 
the computer with the actual device a server.

I would like to make it accessible it from octave, matlab, python, 
julia, if possible.

The only way I know for now is to connect via ssh to the "server" 
console and run the code there, which is not the preferred way for me.

How are you doing such thing?

Thank you

Jakub Ladman

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

[Stefan O. <ste...@jh...>]

Hello Frank,

I went through the setups and digging in the config. I have disabled MSI 
via quirk.c module. But still the troubles.

I have no idea where to look now.

    2.180894] pcieport 0000:00:00.0: assign IRQ: got 232
[    2.181046] pcieport 0000:00:00.0: PME: Signaling with IRQ 233
[    2.182215] pcieport 0000:00:00.0: AER: enabled with IRQ 233
[    2.182282] pcieport 0000:00:00.0: saving config space at offset 0x0 
(reading 0xabcd16c3)
[    2.182286] pcieport 0000:00:00.0: saving config space at offset 0x4 
(reading 0x100507)
[    2.182291] pcieport 0000:00:00.0: saving config space at offset 0x8 
(reading 0x6040001)
[    2.182295] pcieport 0000:00:00.0: saving config space at offset 0xc 
(reading 0x10000)
[    2.182299] pcieport 0000:00:00.0: saving config space at offset 0x10 
(reading 0x18000000)
[    2.182303] pcieport 0000:00:00.0: saving config space at offset 0x14 
(reading 0x0)
[    2.182307] pcieport 0000:00:00.0: saving config space at offset 0x18 
(reading 0xff0100)
[    2.182311] pcieport 0000:00:00.0: saving config space at offset 0x1c 
(reading 0x200000f0)
[    2.182316] pcieport 0000:00:00.0: saving config space at offset 0x20 
(reading 0x18101810)
[    2.182320] pcieport 0000:00:00.0: saving config space at offset 0x24 
(reading 0xfff0)
[    2.182324] pcieport 0000:00:00.0: saving config space at offset 0x28 
(reading 0x0)
[    2.182328] pcieport 0000:00:00.0: saving config space at offset 0x2c 
(reading 0x0)
[    2.182332] pcieport 0000:00:00.0: saving config space at offset 0x30 
(reading 0x0)
[    2.182336] pcieport 0000:00:00.0: saving config space at offset 0x34 
(reading 0x40)
[    2.182340] pcieport 0000:00:00.0: saving config space at offset 0x38 
(reading 0x0)
[    2.182344] pcieport 0000:00:00.0: saving config space at offset 0x3c 
(reading 0x201e8)
[    2.182381] pci 0000:01:00.0: TI XIO2000a quirk detected; secondary 
bus fast back-to-back transfers disabled
*[    2.182394] pci 0000:01:00.0: MSI quirk detected; MSI disabled*
[    2.182449] pcieport 0000:01:00.0: assign IRQ: got 0
[    5.765586] gpib: registered ni_pci interface
[    5.771144] gpib: registered ni_pci_accel interface
[    6.394826] pci 0000:01:00.0: enabling device (0000 -> 0002)
[    6.436520] pci 0000:01:00.0: enabling bus mastering


Stefan

On 1/18/23 22:06, Stefan Olejnik wrote:
>
> *CAUTION:*This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender 
> and know the content is safe.
>
> Hello Frank
>
> You are right, I have checked generated interrupts, and there in no 
> 232 interrupt in the list after communication is done:
>
>  69:        117          0 0          0     GICv3  35 Level     galcore:0
>  70:          2          0          0          0     GICv3 57 
> Level     galcore:2d
>  74:          2          0          0          0  gpio-mxc 3 Edge      
> ads7846
>  78:          0          0          0          0  gpio-mxc 7 Edge      
> 1-0020
>  81:          0          0          0          0  gpio-mxc 10 
> Edge      30b50000.mmc cd
>  82:          0          0          0          0  gpio-mxc 11 
> Edge      extcon_usb1
> 111:          0          0          0          0  gpio-mxc 8 Level     
> bd718xx-irq
> 203:          0          0          0          0  gpio-mxc 4 Edge      
> edt-ft5206
> 231:          0          0          0          0 bd718xx-irq   5 
> Edge      gpio_keys
> *232:          0          0          0          0 GICv3 157 Level     
> ni-pci-gpib*
> 233:          0          0          0          0   PCI-MSI 0 Edge      
> PCIe PME, aerdrv
> 234:          0          0          0          0    1-0020 1 Edge      
> Back
> 235:          0          0          0          0    1-0020 2 Edge      
> Home
> 236:          0          0          0          0    1-0020 3 Edge      
> Menu
> 237:        329          0          0          0     GICv3 138 
> Level     30902000.jr
> 238:          0          0          0          0     GICv3 146 
> Level     30903000.jr
>
> I am right trying to set "pci=nomsi" in Yocto image, but I am beginner 
> in kernel commandline set. I will try to do It. Thanks for advise.
>
> Stefan
>
> On 1/17/23 19:20, Frank Mori Hess wrote:
>> You might want to check that your board is generating interrupts.  I
>> had to set the "pci=nomsi" kernel command line option in order to get
>> interrupts working with an ARM SOC system.
>>
>> On Mon, Jan 16, 2023 at 12:38 PM Stefan Olejnik
>> <ste...@jh...>  wrote:
>>> Hi Dave,
>>>
>>> I have the same results with slave_test2 :
>>>
>>> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test2
>>> [  135.918117] tnt4882: minor 0 read timed out
>>> [  135.922325] tnt4882: read timed out
>>> Got *IDN?
>>>
>>> [  138.990013] tnt4882: write timed out
>>> error: ibwrt fail
>>>   - EABO 6: Operation aborted
>>> root@imx8mm-var-dart:/home/stefan/bin#
>>>
>>>
>>> I am using computer with Win10 and National Instruments GPIB packages -> NI-VISA interactive control program for GPIB. As a commands I am using "query", send the request and waiting for the answer. This Win10 computer is connected to HW (Variscite board with NI PCIe-GPIB (rev 02)) with Yocto linux 5.10 image via NI GPIB-USB-HS+ connector.
>>>
>>> I am handling scenarios as follows:
>>>
>>> No TACS or LACS is set => use poll timer to check if It is any change - 1second.
>>>
>>> LACS is set => use poll timer 200ms to check if read ( ibrd ) returns any data. If yes, read till end-of-the data and save them. Set flag to answer. When CIC do not address slave as a TACS ( use e.g. only write command ) I am getting, of course, read time out. But this is  OK, no data on the GPIB bus.
>>>
>>> TACS is set => try send the data back to the master - CIC. Clear flag to send data.
>>>
>>> I am not getting any notifier from the kernel to activate communication. Therefore I am using polling mechanism. It is OK for me now.
>>>
>>> As I have mentioned already. Reading seems to me OK. When data are on the GPIB bus, I am reading them. When no data, I am getting read time out. But I have somehow to check, if any data are ready to be read => poll mechanism.
>>>
>>> Write seems to me bigger problem, as I have already described.
>>>
>>> Stefan
>>>
>>>
>>> On 1/16/23 14:01, dave penkler wrote:
>>>
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>>
>>>
>>>
>>> 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://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!dStM8yAfuh3c-g2DADHbI16c9tjl3JGNosqI3Iot8J8ca4a2dFSpRfVPrlbgFg5WJ_2JeC33Gjy440iMy6p_$
>>>
>>> _______________________________________________
>>> Linux-gpib-general mailing list
>>> Lin...@li...
>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!dL-ipEp1pt_XUmuO6ksxUAyCAbK3Xy5EHGSA1xgni4Kv2Xj_ib-kNilY-ezJtoZel4f58xAoNvz-A9JR4s4vHIrtRfdtithG1Q$  

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

[Stefan O. <ste...@jh...>]

Hello Frank

You are right, I have checked generated interrupts, and there in no 232 
interrupt in the list after communication is done:

  69:        117          0 0          0     GICv3  35 Level     galcore:0
  70:          2          0          0          0     GICv3  57 
Level     galcore:2d
  74:          2          0          0          0  gpio-mxc   3 
Edge      ads7846
  78:          0          0          0          0  gpio-mxc   7 
Edge      1-0020
  81:          0          0          0          0  gpio-mxc  10 
Edge      30b50000.mmc cd
  82:          0          0          0          0  gpio-mxc  11 
Edge      extcon_usb1
111:          0          0          0          0  gpio-mxc   8 Level     
bd718xx-irq
203:          0          0          0          0  gpio-mxc   4 Edge      
edt-ft5206
231:          0          0          0          0  bd718xx-irq 5 
Edge      gpio_keys
*232:          0          0          0          0     GICv3 157 
Level     ni-pci-gpib*
233:          0          0          0          0   PCI-MSI   0 Edge      
PCIe PME, aerdrv
234:          0          0          0          0    1-0020   1 Edge      
Back
235:          0          0          0          0    1-0020   2 Edge      
Home
236:          0          0          0          0    1-0020   3 Edge      
Menu
237:        329          0          0          0     GICv3 138 Level     
30902000.jr
238:          0          0          0          0     GICv3 146 Level     
30903000.jr

I am right trying to set "pci=nomsi" in Yocto image, but I am beginner 
in kernel commandline set. I will try to do It. Thanks for advise.

Stefan

On 1/17/23 19:20, Frank Mori Hess wrote:
> You might want to check that your board is generating interrupts.  I
> had to set the "pci=nomsi" kernel command line option in order to get
> interrupts working with an ARM SOC system.
>
> On Mon, Jan 16, 2023 at 12:38 PM Stefan Olejnik
> <ste...@jh...>  wrote:
>> Hi Dave,
>>
>> I have the same results with slave_test2 :
>>
>> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test2
>> [  135.918117] tnt4882: minor 0 read timed out
>> [  135.922325] tnt4882: read timed out
>> Got *IDN?
>>
>> [  138.990013] tnt4882: write timed out
>> error: ibwrt fail
>>   - EABO 6: Operation aborted
>> root@imx8mm-var-dart:/home/stefan/bin#
>>
>>
>> I am using computer with Win10 and National Instruments GPIB packages -> NI-VISA interactive control program for GPIB. As a commands I am using "query", send the request and waiting for the answer. This Win10 computer is connected to HW (Variscite board with NI PCIe-GPIB (rev 02)) with Yocto linux 5.10 image via NI GPIB-USB-HS+ connector.
>>
>> I am handling scenarios as follows:
>>
>> No TACS or LACS is set => use poll timer to check if It is any change - 1second.
>>
>> LACS is set => use poll timer 200ms to check if read ( ibrd ) returns any data. If yes, read till end-of-the data and save them. Set flag to answer. When CIC do not address slave as a TACS ( use e.g. only write command ) I am getting, of course, read time out. But this is  OK, no data on the GPIB bus.
>>
>> TACS is set => try send the data back to the master - CIC. Clear flag to send data.
>>
>> I am not getting any notifier from the kernel to activate communication. Therefore I am using polling mechanism. It is OK for me now.
>>
>> As I have mentioned already. Reading seems to me OK. When data are on the GPIB bus, I am reading them. When no data, I am getting read time out. But I have somehow to check, if any data are ready to be read => poll mechanism.
>>
>> Write seems to me bigger problem, as I have already described.
>>
>> Stefan
>>
>>
>> On 1/16/23 14:01, dave penkler wrote:
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>
>>
>>
>> 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://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!dStM8yAfuh3c-g2DADHbI16c9tjl3JGNosqI3Iot8J8ca4a2dFSpRfVPrlbgFg5WJ_2JeC33Gjy440iMy6p_$
>>
>> _______________________________________________
>> 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

[Frank M. H. <fm...@gm...>]

You might want to check that your board is generating interrupts.  I
had to set the "pci=nomsi" kernel command line option in order to get
interrupts working with an ARM SOC system.

On Mon, Jan 16, 2023 at 12:38 PM Stefan Olejnik
<ste...@jh...> wrote:
>
> Hi Dave,
>
> I have the same results with slave_test2 :
>
> root@imx8mm-var-dart:/home/stefan/bin# ./slave_test2
> [  135.918117] tnt4882: minor 0 read timed out
> [  135.922325] tnt4882: read timed out
> Got *IDN?
>
> [  138.990013] tnt4882: write timed out
> error: ibwrt fail
>  - EABO 6: Operation aborted
> root@imx8mm-var-dart:/home/stefan/bin#
>
>
> I am using computer with Win10 and National Instruments GPIB packages -> NI-VISA interactive control program for GPIB. As a commands I am using "query", send the request and waiting for the answer. This Win10 computer is connected to HW (Variscite board with NI PCIe-GPIB (rev 02)) with Yocto linux 5.10 image via NI GPIB-USB-HS+ connector.
>
> I am handling scenarios as follows:
>
> No TACS or LACS is set => use poll timer to check if It is any change - 1second.
>
> LACS is set => use poll timer 200ms to check if read ( ibrd ) returns any data. If yes, read till end-of-the data and save them. Set flag to answer. When CIC do not address slave as a TACS ( use e.g. only write command ) I am getting, of course, read time out. But this is  OK, no data on the GPIB bus.
>
> TACS is set => try send the data back to the master - CIC. Clear flag to send data.
>
> I am not getting any notifier from the kernel to activate communication. Therefore I am using polling mechanism. It is OK for me now.
>
> As I have mentioned already. Reading seems to me OK. When data are on the GPIB bus, I am reading them. When no data, I am getting read time out. But I have somehow to check, if any data are ready to be read => poll mechanism.
>
> Write seems to me bigger problem, as I have already described.
>
> Stefan
>
>
> On 1/16/23 14:01, dave penkler wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
>
> 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://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!dStM8yAfuh3c-g2DADHbI16c9tjl3JGNosqI3Iot8J8ca4a2dFSpRfVPrlbgFg5WJ_2JeC33Gjy440iMy6p_$
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general



-- 
Frank

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

[Stefan O. <ste...@jh...>]

Hi Dave,

I have the same results with slave_test2 :

root@imx8mm-var-dart:/home/stefan/bin# ./slave_test2
[  135.918117] tnt4882: minor 0 read timed out
[  135.922325] tnt4882: read timed out
Got *IDN?

[  138.990013] tnt4882: write timed out
error: ibwrt fail
  - EABO 6: Operation aborted
root@imx8mm-var-dart:/home/stefan/bin#


I am using computer with Win10 and National Instruments GPIB packages -> 
NI-VISA interactive control program for GPIB. As a commands I am using 
"query", send the request and waiting for the answer. This Win10 
computer is connected to HW (Variscite board with NI PCIe-GPIB (rev 02)) 
with Yocto linux 5.10 image via NI GPIB-USB-HS+ connector.

I am handling scenarios as follows:

No TACS or LACS is set => use poll timer to check if It is any change - 
1second.

LACS is set => use poll timer 200ms to check if read ( ibrd ) returns 
any data. If yes, read till end-of-the data and save them. Set flag to 
answer. When CIC do not address slave as a TACS ( use e.g. only write 
command ) I am getting, of course, read time out. But this is  OK, no 
data on the GPIB bus.

TACS is set => try send the data back to the master - CIC. Clear flag to 
send data.

I am not getting any notifier from the kernel to activate communication. 
Therefore I am using polling mechanism. It is OK for me now.

As I have mentioned already. Reading seems to me OK. When data are on 
the GPIB bus, I am reading them. When no data, I am getting read time 
out. But I have somehow to check, if any data are ready to be read => 
poll mechanism.

Write seems to me bigger problem, as I have already described.

Stefan


On 1/16/23 14:01, dave penkler wrote:
>
> *CAUTION:*This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender 
> and know the content is safe.
>
> 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://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!dStM8yAfuh3c-g2DADHbI16c9tjl3JGNosqI3Iot8J8ca4a2dFSpRfVPrlbgFg5WJ_2JeC33Gjy440iMy6p_$  

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

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

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.
>
>
>

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

[Stefan O. <ste...@jh...>]

  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.


On 1/13/23 13:50, dave penkler wrote:
>
> *CAUTION:*This email originated from outside of the organization. Do 
> not click links or open attachments unless you recognize the sender 
> and know the content is safe.
>
> Hi Stefan,
> Attached is a little programme slave_test to demonstrate pure slave 
> aka device mode.
> It uses minor 0 in board mode.
> On the slave side run slave_test and on the master ibterm.
>
> On the slave side:
>
> *$ cc -o slave_test slave_test.c -lgpib
> $ ./slave_test
> Got hello
> Got bye
> Got quit
> slave done
> $ *
> *
> *
> On the master side:
>
> *$ibterm -d 1
> Attempting to open /dev/gpib0
> pad = 1, sad = 0, timeout = 10, send_eoi = 1, eos_mode = 0x0000
> ibterm>hello
> Reply: hello
> ibterm>bye
> Reply: bye
> ibterm>quit
> ibterm><CTRL-D>
>
> ibterm: Done.
> $ *
>
> On Tue, 10 Jan 2023 at 17:11, Olejnik, Stefan 
> <ste...@fl...> wrote:
>
>     I have the troubles with GPIB interface - National Instruments
>     PCIe-GPIB. Kernel driver TNT4882. Configuration is as a pure slave
>     - just listen and answer:
>     interface {
>             minor = 0       /* board index, minor = 0 uses /dev/gpib0,
>     minor = 1 uses /dev/gpib1, etc. */
>             board_type = "ni_pci"
>             name = "violet" /* optional name, allows you to get a
>     board descriptor using ibfind() */
>             pad = 1 /* primary address of interface             */
>             sad = 0 /* secondary address of interface           */
>             timeout = T10s  /* timeout for commands */
>
>             eos = 0x0a      /* EOS Byte, 0xa is newline and 0xd is
>     carriage return */
>             set-reos = no   /* 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 */
>
>             master = no     /* interface board is system controller */
>     }
>
>     When I am using "ibtest" then write command returns TIMO:
>     : w
>     enter a string to send to your device: testString
>     sending string: testString
>
>     [  200.928468] tnt4882: write timed out
>     gpib status is:
>     ibsta = 0xc100  < ERR TIMO CMPL >
>     iberr= 6
>     EABO 6: Operation aborted
>
>     I have created test SW and find out, that if I am using
>     "ibwrta/ibwait" command twice, second try is always successful.
>     First returns TIMO.
>     Reading is OK.
>
>     On the other side is NI PC as a CIC.
>
>     Thanks for any help....
>
>     ------------------------------------------------------------------------
>
>     Please be advised that this email may contain confidential
>     information. If you are not the intended recipient, please notify
>     us by email by replying to the sender and delete this message.
>
>     _______________________________________________
>     Linux-gpib-general mailing list
>     Lin...@li...
>     https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>     <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/linux-gpib-general__;!!KPww_GFiJXw!akxknQHeZpcW-ROH7zJVOrfvFfYJzQx-gz4MHy1qpJ_OSA5dbLhsWj7sRrZLWLcNkYWlvEdwJaknUJMZKAiJ$>
>

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

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

Hi Stefan,
Attached is a little programme slave_test to demonstrate pure slave aka
device mode.
It uses minor 0 in board mode.
On the slave side run slave_test and on the master ibterm.

On the slave side:







*$ cc -o slave_test slave_test.c -lgpib$ ./slave_test Got helloGot byeGot
quitslave done$ *

On the master side:












*$ ibterm -d 1Attempting to open /dev/gpib0pad = 1, sad = 0, timeout = 10,
send_eoi = 1, eos_mode = 0x0000ibterm>helloReply: helloibterm>byeReply:
byeibterm>quitibterm><CTRL-D>ibterm: Done.$ *

On Tue, 10 Jan 2023 at 17:11, Olejnik, Stefan <ste...@fl...>
wrote:

> I have the troubles with GPIB interface - National Instruments PCIe-GPIB.
> Kernel driver TNT4882. Configuration is as a pure slave - just listen and
> answer:
> interface {
>         minor = 0       /* board index, minor = 0 uses /dev/gpib0, minor =
> 1 uses /dev/gpib1, etc. */
>         board_type = "ni_pci"
>         name = "violet" /* optional name, allows you to get a board
> descriptor using ibfind() */
>         pad = 1 /* primary address of interface             */
>         sad = 0 /* secondary address of interface           */
>         timeout = T10s  /* timeout for commands */
>
>         eos = 0x0a      /* EOS Byte, 0xa is newline and 0xd is carriage
> return */
>         set-reos = no   /* 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 */
>
>         master = no     /* interface board is system controller */
> }
>
> When I am using "ibtest" then write command returns TIMO:
> : w
> enter a string to send to your device: testString
> sending string: testString
>
> [  200.928468] tnt4882: write timed out
> gpib status is:
> ibsta = 0xc100  < ERR TIMO CMPL >
> iberr= 6
> EABO 6: Operation aborted
>
> I have created test SW and find out, that if I am using "ibwrta/ibwait"
> command twice, second try is always successful. First returns TIMO.
> Reading is OK.
>
> On the other side is NI PC as a CIC.
>
> Thanks for any help....
>
> ------------------------------
>
> Please be advised that this email may contain confidential information. If
> you are not the intended recipient, please notify us by email by replying
> to the sender and delete this message.
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

Re: [Linux-gpib-general] Problem compiling driver after Ubuntu update

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

Hi,
I guess this is an ubuntu/debian thing.
Apparently you can set the environment variable IGNORE_CC_MISMATCH before
building.

export IGNORE_CC_MISMATCH=1 ; make

cheers,
-Dave


On Fri, 13 Jan 2023 at 09:28, Søren Koch via Linux-gpib-general <
lin...@li...> wrote:

> Dear all.
>
>
> I have run into a quite strange problem after updating one of our Ubuntu
> systems.
>
>
> When I run make in the kernel driver directory I get the following error:
>
>
> root@celletest-36:~/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5# make
> make -C /lib/modules/`uname -r`/build V=0 modules \
>     M="/root/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5/drivers/gpib" \
>     GPIB_TOP_DIR=/root/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5 \
>     CONFIG_GPIB_ISA="" \
>     GPIB_CONFIG_PCMCIA="0" \
>     HAVE_DEV_OF_NODE= \
>     GPIB_CONFIG_KERNEL_DEBUG=0
> make[1]: Entering directory '/usr/src/linux-headers-5.15.0-48-generic'
> warning: the compiler differs from the one used to build the kernel
>   The kernel was built by: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
>   You are using:           gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
> make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-48-generic'
> root@celletest-36:~/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5#
>
>
> I have never seen that kind of error before and I have no idea how to
> 'downgrade' gcc.
>
> (and I have not explicitly upgraded gcc either, I just ran apt-get
> update...
>
>
> Anyone got any ideas?
>
> Søren Koch
> Senior Development Engineer
> Mob: +45 21325247
> sq...@dt...
> Fysikvej
> Building 310
> 2800 Kgs. Lyngby
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>

[Linux-gpib-general] Problem compiling driver after Ubuntu update

[Søren K. <sq...@dt...>]

Dear all.


I have run into a quite strange problem after updating one of our Ubuntu systems.


When I run make in the kernel driver directory I get the following error:


root@celletest-36:~/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5# make
make -C /lib/modules/`uname -r`/build V=0 modules \
    M="/root/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5/drivers/gpib" \
    GPIB_TOP_DIR=/root/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5 \
    CONFIG_GPIB_ISA="" \
    GPIB_CONFIG_PCMCIA="0" \
    HAVE_DEV_OF_NODE= \
    GPIB_CONFIG_KERNEL_DEBUG=0
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-48-generic'
warning: the compiler differs from the one used to build the kernel
  The kernel was built by: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
  You are using:           gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-48-generic'
root@celletest-36:~/linux-gpib-4.3.5/linux-gpib-kernel-4.3.5#


I have never seen that kind of error before and I have no idea how to 'downgrade' gcc.

(and I have not explicitly upgraded gcc either, I just ran apt-get update...


Anyone got any ideas?

Søren Koch
Senior Development Engineer
Mob: +45 21325247
sq...@dt...
Fysikvej
Building 310
2800 Kgs. Lyngby

[Linux-gpib-general] GPIB as a pure slave

[Olejnik, S. <ste...@fl...>]

I have the troubles with GPIB interface - National Instruments PCIe-GPIB. Kernel driver TNT4882. Configuration is as a pure slave - just listen and answer:
interface {
        minor = 0       /* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
        board_type = "ni_pci"
        name = "violet" /* optional name, allows you to get a board descriptor using ibfind() */
        pad = 1 /* primary address of interface             */
        sad = 0 /* secondary address of interface           */
        timeout = T10s  /* timeout for commands */

        eos = 0x0a      /* EOS Byte, 0xa is newline and 0xd is carriage return */
        set-reos = no   /* 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 */

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

When I am using "ibtest" then write command returns TIMO:
: w
enter a string to send to your device: testString
sending string: testString

[  200.928468] tnt4882: write timed out
gpib status is:
ibsta = 0xc100  < ERR TIMO CMPL >
iberr= 6
EABO 6: Operation aborted

I have created test SW and find out, that if I am using "ibwrta/ibwait" command twice, second try is always successful. First returns TIMO.
Reading is OK.

On the other side is NI PC as a CIC.

Thanks for any help....

________________________________

Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message.

Re: [Linux-gpib-general] Clone NI GPIB-USB-HS

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

We have had a number of reports of clones not working with linux-gpib
even though they work under Windows. The main issue that we found is
that they do not work in board mode which *is* required for
linux-gpib.

On Sun, 11 Dec 2022 at 16:36, Michael K via Linux-gpib-general
<lin...@li...> wrote:
>
> I'm looking into buying a NI interface (because the Agilent USB device I have can only act as a controller).
> There are many available on eBay that claim to be NI but I suspect are clones.
> Will all clones fail to work on the Linux GPIB driver or is there a chance that it will work?
> thanks,
>   Michael
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] Clone NI GPIB-USB-HS

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

I'm looking into buying a NI interface (because the Agilent USB device I have can only act as a controller).
There are many available on eBay that claim to be NI but I suspect are clones. 
Will all clones fail to work on the Linux GPIB driver or is there a chance that it will work?
thanks,
  Michael

Re: [Linux-gpib-general] gpib_bitbang kernel exceptions and deadlocks in 4.3.5 releases now fixed in r2046

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

Yes, in the 4.3.5 release the gpib_bitbang driver (version r2030)
contained some bugs. They have been fixed in last r2046 version,
that appears to be by far more stable.

Marcello Carla'





On 12/1/22 12:38 PM, Vladimir Vassilev wrote:
> Hi,
>
> With the 4.3.5 release using the gpib_bitbang.ko driver caused crashes 
> in kernel space which are now seemingly resolved with the modified 
> spinlock handling in the latest trunk r2046.
>
> We have updated our hackster guide to use the debian package we 
> generate from that svn trunk revision.
>
> * Debian package repository: 
> https://github.com/lightside-instruments/gpib-debian/tree/debian/4.3.5-lsi4
>
> * Hackster guide: 
> https://www.hackster.io/lightside-instruments/the-gpib4pi-gpib-for-raspberry-pi-hat-4b3e9a
>
> /Vladimir
>
> On 11/8/22 00:35, Vladimir Vassilev wrote:
>> Dave,
>>
>> Yes that was the issue .. gpio27 was swapped with pin27!
>>
>> One needs the following patch to workaround the issue. (`modprobe 
>> gpib_bitbang board_id=gpib4pi-1.1`):
>>
>> --- a/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
>> +++ b/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
>> @@ -91,6 +91,10 @@
>>  static int sn7516x_used=1;
>>  module_param(sn7516x_used,int,0660);
>>
>> +static char *board_id = "default";
>> +module_param(board_id, charp, 0660);
>> +MODULE_PARM_DESC(board_id, "Valid values: default, gpib4pi-1.1");
>> +
>>  /**********************************************
>>   *  Signal pairing and pin wiring between the *
>>   *  Raspberry-Pi connector and the GPIB bus   *
>> @@ -914,6 +918,12 @@ int bb_attach(gpib_board_t *board, const 
>> gpib_board_config_t *config)
>>          priv->direction = -1;
>>          priv->t1_delay = 2000;
>>
>> +        if(0==strcmp("gpib4pi-1.1", board_id)) {
>> +            dbg_printk(3,"Using pin mapping for %s\n", board_id);
>> +
>> +            gpios_vector[12] = 0; /* 27 -> 0 */
>> +        }
>> +
>>          if (allocate_gpios()) return -EBUSY;
>>
>>          if (sn7516x_used) {
>>
>>
>> /Vladimir
>>
>> On 11/5/22 11:48, dave penkler wrote:
>>> Hi Vladimir,
>>> GPIO0 corresponds to pin 27 on the Pi header usually reserved for 
>>> i2c EERROM. What is it connected to, if anything, on the 
>>> lsi-gpib4pi-1.1 shield ?
>>> cheers,
>>> -Dave
>>>
>>>

[Linux-gpib-general] gpib_bitbang kernel exceptions and deadlocks in 4.3.5 releases now fixed in r2046

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

Hi,

With the 4.3.5 release using the gpib_bitbang.ko driver caused crashes 
in kernel space which are now seemingly resolved with the modified 
spinlock handling in the latest trunk r2046.

We have updated our hackster guide to use the debian package we generate 
from that svn trunk revision.

* Debian package repository: 
https://github.com/lightside-instruments/gpib-debian/tree/debian/4.3.5-lsi4

* Hackster guide: 
https://www.hackster.io/lightside-instruments/the-gpib4pi-gpib-for-raspberry-pi-hat-4b3e9a

/Vladimir

On 11/8/22 00:35, Vladimir Vassilev wrote:
> Dave,
>
> Yes that was the issue .. gpio27 was swapped with pin27!
>
> One needs the following patch to workaround the issue. (`modprobe 
> gpib_bitbang board_id=gpib4pi-1.1`):
>
> --- a/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
> +++ b/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
> @@ -91,6 +91,10 @@
>  static int sn7516x_used=1;
>  module_param(sn7516x_used,int,0660);
>
> +static char *board_id = "default";
> +module_param(board_id, charp, 0660);
> +MODULE_PARM_DESC(board_id, "Valid values: default, gpib4pi-1.1");
> +
>  /**********************************************
>   *  Signal pairing and pin wiring between the *
>   *  Raspberry-Pi connector and the GPIB bus   *
> @@ -914,6 +918,12 @@ int bb_attach(gpib_board_t *board, const 
> gpib_board_config_t *config)
>          priv->direction = -1;
>          priv->t1_delay = 2000;
>
> +        if(0==strcmp("gpib4pi-1.1", board_id)) {
> +            dbg_printk(3,"Using pin mapping for %s\n", board_id);
> +
> +            gpios_vector[12] = 0; /* 27 -> 0 */
> +        }
> +
>          if (allocate_gpios()) return -EBUSY;
>
>          if (sn7516x_used) {
>
>
> /Vladimir
>
> On 11/5/22 11:48, dave penkler wrote:
>> Hi Vladimir,
>> GPIO0 corresponds to pin 27 on the Pi header usually reserved for i2c 
>> EERROM. What is it connected to, if anything, on the lsi-gpib4pi-1.1 
>> shield ?
>> cheers,
>> -Dave
>>
>>

Re: [Linux-gpib-general] ibwt() / ibrd() immediatly following ibclr()

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

When reproducing the problem with an HP34401A using an NI-PCI board
the error message was intermittent . Adding a delay of ~1ms between
the ibclr() and ibwrt() fixed it.
There is no problem with the driver, it just takes a certain time for
different instruments to complete the device clear operation.
cheers,
-Dave


On Wed, 16 Nov 2022 at 20:21, Michael K via Linux-gpib-general
<lin...@li...> wrote:
>
> I have some code that writes an "IDN?" and reads the requested string from a device.
> I issue an ibclr() immediately before the ibwt(). It seems that if I do this, I receive an error (2 - 'You have attempted to write data or command bytes, but there are no listeners currently addressed.').
> If I add a ~20ms delay after the ibclr(), before the ibwt(), then it works as expected.
>
> Is this a problem with the device ? (HP8753b) or in the driver (or my approach).
>
> Michael
>
>
> _______________________________________________
> Linux-gpib-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general

[Linux-gpib-general] ibwt() / ibrd() immediatly following ibclr()

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

I have some code that writes an "IDN?" and reads the requested string from a device.
I issue an ibclr() immediately before the ibwt(). It seems that if I do this, I receive an error (2 - 'You have attempted to write data or command bytes, but there are no listeners currently addressed.').
If I add a ~20ms delay after the ibclr(), before the ibwt(), then it works as expected.

Is this a problem with the device ? (HP8753b) or in the driver (or my approach).

Michael

Re: [Linux-gpib-general] HP 59306A problem with the gpib_bitbang driver in the 4.3.4 and 4.3.5 releases

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

Dave,

Yes that was the issue .. gpio27 was swapped with pin27!

One needs the following patch to workaround the issue. (`modprobe 
gpib_bitbang board_id=gpib4pi-1.1`):

--- a/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
+++ b/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
@@ -91,6 +91,10 @@
  static int sn7516x_used=1;
  module_param(sn7516x_used,int,0660);

+static char *board_id = "default";
+module_param(board_id, charp, 0660);
+MODULE_PARM_DESC(board_id, "Valid values: default, gpib4pi-1.1");
+
  /**********************************************
   *  Signal pairing and pin wiring between the *
   *  Raspberry-Pi connector and the GPIB bus   *
@@ -914,6 +918,12 @@ int bb_attach(gpib_board_t *board, const 
gpib_board_config_t *config)
          priv->direction = -1;
          priv->t1_delay = 2000;

+        if(0==strcmp("gpib4pi-1.1", board_id)) {
+            dbg_printk(3,"Using pin mapping for %s\n", board_id);
+
+            gpios_vector[12] = 0; /* 27 -> 0 */
+        }
+
          if (allocate_gpios()) return -EBUSY;

          if (sn7516x_used) {


/Vladimir

On 11/5/22 11:48, dave penkler wrote:
> Hi Vladimir,
> GPIO0 corresponds to pin 27 on the Pi header usually reserved for i2c 
> EERROM. What is it connected to, if anything, on the lsi-gpib4pi-1.1 
> shield ?
> cheers,
> -Dave
>
>

[Linux-gpib-general] HP 59306A problem with the gpib_bitbang driver in the 4.3.4 and 4.3.5 releases

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

Hi,

I created a Debian package and tested the latest 4.3.5 release on a 
Raspberry Pi with the gpib_bitbang driver and a lsi-gpib4pi-1.1 shield 
(with sn7516x drivers).

I noticed that my testcases for one particular device (HP 59306A) were 
failing while the rest (Agilent E3647A, etc.) were completing OK.


The write operations to that ancient relay actuator (probably the first 
standard IEEE 488 device) were completing OK but no effect was taking place.


I managed to reproduce the issue for the previous release 4.3.4 too so 
this is not an issue introduced in 4.3.5.


In the end after comparing with older driver versions I found that one 
needs to apply this patch and the problem is gone.


--- a/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
+++ b/linux-gpib-kernel/drivers/gpib/gpio/gpib_bitbang.c
@@ -1026,7 +1026,7 @@ gpib_interface_t bb_interface =
  static int __init bb_init_module(void)
  {
          gpib_register_driver(&bb_interface, THIS_MODULE);
-
+        gpio_direction_output(0, 0); // workaround without this line 
accessing HP 59306A device does not work
          dbg_printk(1,"module loaded%s",(sn7516x_used)?" with SN7516x 
driver support":"");
          return 0;
  }


That said it seems like this workaround without proper gpio request just 
providing 0 as gpio argument is a bug ... or probably a feature that I 
was not able to find anything in the documentation is used. So for now I 
will not push a patch proposal.


/V

Re: [Linux-gpib-general] Problem with device communication

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

Dirk,

I am picking up a thread last updated 2021-10-11 21:33:44 ... I also 
tried to build and install the linux-gpib driver and ran into problems 
with the latest code in trunk.

I finally got it to work but I had to use the code for 4.3.4 release and 
the debian source package repository. I updated only the gpib_bitbang.c 
to the latest trunk version and published a new debian revision tag 
gpib-4.3.4-1lsi1 
<https://github.com/vlvassilev/gpib/commit/5fed6f014e18a9a53f346e0ccfe1c936d13d4f40> 
with the patch.

I have also added a hackster walkthrough with 3 different devices in a 
GPIB network testing all 3 of them with the updated driver and all 
installation steps.

https://www.hackster.io/lightside-instruments/the-gpib4pi-gpib-for-raspberry-pi-hat-4b3e9a

/Vladimir