Re: [EXTERNAL] Re: GPIB as a pure slave

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
>>>> <[email protected]> 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 <[email protected]>
>>>>     To:     marcello.carla <[email protected]>
>>>>
>>>>
>>>>
>>>>     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
>>>>     >>> <[email protected]> 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
>>>>     >>> [email protected]
>>>>     >>>
>>>> https://lists.sourceforge.net/lists/listinfo/linux-gpib-general
>>>>     >
>>>>
>>



_______________________________________________
Linux-gpib-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-gpib-general