Menu
▾
▴
Re: [Linux-gpib-general] [EXTERNAL] Re: GPIB as a pure slave
|
From: Vladimir V. <vla...@li...> - 2023-05-08 16:36:40
|
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 >>>>> <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 >>>>> > >>>>> >>> > |
