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

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