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

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