From: Vladimir V. <vla...@li...> - 2023-05-08 12:01:57
|
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 >>> > >>> > |