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