GPIB Data bus invertion

[DiBosco]

Folks,

I've got an STM32 set up to sit on a GPIB bus using 75160 and 75161 standard ICs to act as the interface between the bus and the STM32.

I'm using a GPIB-USB-HS to talk to the bus and sending out

*IDN?

From the PC to my node.

After a great deal of head scratching, and getting the same bytes into the STM32 all the time I realised that if I inverted the bits on the STM32 data bus side, in the STM32 in firmware, I would get right message. I am missing the \n but get three command bytes and *IDN?\r into my node.

So what is going on here? If I use my picoscope in logic analyser mode, the GPIB data bus values are identical to what is read into the STM32. ie the bits on the bus side are the same as what is on the STM32 side of the 75160, so that device clearly isn't inverting the bits. Could the NI GPIB-USB-HS be inverting the bits? Might I have somehow put that into inverting mode? Or is this just how it works and I have to invert all the bits in the processor as a matter of course. The latter seems rather unlikely.

[Andy Watson]

The entire bus is inverted with respect to voltage levels. See page 24 - Logic levels.

http://www.bitsavers.org/pdf/hp/hpib/TutorialDescrOfHPIB.pdf

I've not used the 75160/1 but as far as I can tell from the datasheet the inversion is not un-done.

I am missing the \n

\n, \r and the hardware/wire EOI are used to signal the end of a message. The driver program can usually be configured to accept any, or all as indicating the end of a string and optionally strip the terminating character.

[DiBosco]

T'riffic, many thanks, Andy, appreciate the help.

In theory our script to send out the IDN message was supposed to be \r\n, but maybe that script wasn't set up correctly.

[Andy Watson]

In theory our script to send out the IDN message was supposed to be \r\n, but maybe that script wasn't set up correctly.

I think there is a possibility that if you've not allowed for the correct inversion of the NRFD and NDAC signals, you could be operating on the wrong edge - effectively pushing your data out by one byte.

[DiBosco]

Finally getting a chance to look at this again after being dragged on to another project.

I'm not totally sure as the way this works with high being false and low being true, plus the nomenclature of assert and deassert, especially with NOT ready for data suggesting to me that is saying you're not ready for data, but, I think is meaning when you're ready for data, the signal is low, which is actually a high voltage - arrrgghhhh ...

...I think, this waveform which is snipped form my picoscope trace, which is D0-7 being data, D8 being DAV, D9 ATN, D10 NRFD and NDAC D11 shows the signals are not quite correct and the last databyte sent is 0x0D which is CR, so I'm never getting line feed. This is data only, the commands have already been read.

Edit, the D0-D12 have been snipped off my screenshot somehow, but top to bottom, first eight signals are data D1-D8. DAV is blue, NRFD is green and NDAC browny beige. ATN is red.

I realise there's a lengthy delay between DAV going low and NRFD going low for the first byte (720us), I think that's because FreeRTOS is in another task and it's only when it switches to the GPIB task that there's a flurry of activity as the program has GPIB control for that timer tick.

If you look at figure 2.3 in the manual link you sent me, that looks not quite the same as what I have here. Although DAV goes low then NRFD goes low after 720us, then NDAC high just after for the first transaction, DAV is going high at exactly the same time as NDAC.

[DiBosco]

FWIW, have sussed this part of it. It was the GPIB interface and how it was set up. So other than inverting the bits, all was well with my firmware.