GPIB device handshake problem - Page 1
Forum section: electronics / projects

author: davorin
author_rank: Unknown
timestamp: June 18, 2020, 07:59:44 am
content: Good morningStarted on a project where a STM32F2 series MCU plays the role of a GPIB device...According to the GPIB protocol pictures I've found the start of a communication from a GPIB controller looks like:- Wait for NRFD is 1- Set DIO on the bus- Set DAV to 0- Wait for NDAC for 1- Set DAV to 1So in my init code I have:Code:// Drive SN75160HAL_GPIO_WritePin(GPIOE, TE, GPIO_PIN_RESET);HAL_GPIO_WritePin(GPIOE, PE, GPIO_PIN_SET);// Drive SN75161HAL_GPIO_WritePin(GPIOE, DC, GPIO_PIN_SET);HAL_GPIO_WritePin(GPIOD, NDAC, GPIO_PIN_RESET);HAL_GPIO_WritePin(GPIOD, NRFD, GPIO_PIN_SET);HAL_GPIO_WritePin(GPIOD, SRQ, GPIO_PIN_SET);But I don't see anything happening with the DAV signal being set to 0 when sending a command...As soon I attach another device on the GPIB bus I see the DAV signal being driven low.So I assume I missed some other signal which is not set correctly besides NRFD, NDAC and SRQ?thanks in advancedavorin

author: davorin
author_rank: Unknown
timestamp: June 18, 2020, 08:31:29 am
content: Stupid me...wrong wiring (o;But seems I have to insert a delay so that ATN is recognized as data or command correctly....At least I get now on the USB terminal output:Code:CMD: 40CMD: 3FCMD: 25DAT: *DAT: IDAT: DDAT: NDAT: ?CMD: 3FCMD: 20CMD: 45when I send *IDN?...Interestingly I don't get any error message with ibterm....as no message is sent back....

author: rcjoy
author_rank: Regular Contributor
timestamp: June 19, 2020, 04:32:41 am
content: Ideally you would also pull the EOI line down with the last byte sent in the message.

author: davorin
author_rank: Unknown
timestamp: June 19, 2020, 07:06:48 am
content: Ah..in the above example I don't send any data...just receiving for testing...Today comes now the talking part and state machine (o;Hard to find any communication example...only stuff like how handshaking is done when sending a single byte..but not what commands to actually send to establish a channel between a controller and device...Seems the controller always have to send:Code:MTA0 - It is me talking nowUNLISTEN - Forget any previous Listen AddressMLA5 - Hey device 5, it is for you*IDN? - The actual payload with EOI set on last byteUNLISTEN - Forget any previous Listen AddressMLA0 - It is me who is listening nowMTA5 - Hey device 5, it is up to you now who has to talkSo it is unclear if the device responding has to send the MLA/MTA/UNLISTEN stuff as well or if the controller is ready to receive just the payload and finishes then when receiving EOI.

author: rcjoy
author_rank: Regular Contributor
timestamp: June 19, 2020, 09:37:42 am
content: Generally only the controller sends bus commands (those associated with the ATN line pulled low).The device does not send bus commands as far as I know. It only listens to them (with the appropriate NRFD, DAV, NDAC handshaking).Here's a sequence where the controller sends *IDN? to a device and its response, where the controller is address 21 and the device is address 2.Code:Ctrl BusHex Ascii Line Cmd--- ----- ---- ------55 U ATN MTA 213f ? ATN UNL22 " ATN MLA 22a *49 I44 D4e N3f ?a EOI3f ? ATN UNL35 5 ATN MLA 2142 B ATN MTA 22041 A4d M52 R45 E4c L2050 P58 X2033 330 02d -31 144 D41 A200 EOI

author: davorin
author_rank: Unknown
timestamp: June 19, 2020, 09:45:06 am
content: Yes...seems so....works now with my Nucleo-F207ZG board....have to test though now with several devices on the bus now...Probably will do a GPIB PCB with the transceivers and control LEDs onboard for better testing...ANother project will be a ethernet2gpib converter...that's where the STM32F207/F102 will go...BTW: With what software did you capture the GPIB trace?

author: rcjoy
author_rank: Regular Contributor
timestamp: June 19, 2020, 07:37:41 pm
content: It was captured with an Arduino acting as a GPIB bus analyzer.It just sniffs the bus and prints what it sees whenever DAV goes low.

author: davorin
author_rank: Unknown
timestamp: June 19, 2020, 07:50:59 pm
content: Interesting :-)Is that code somewhere available?Tried as well on my Nucleo board and send it out via USB directly..but seems the USB code blocked too long so it didn't capture anything....but then again..I could have fooled the controller with applying NRFD/NDAC accordingly on the bus to slow it down (o;

author: rcjoy
author_rank: Regular Contributor
timestamp: June 21, 2020, 01:31:53 am
content: The capture can be done in an interrupt routine that is tied to DAV going low, and with the DAV signal connected to the external interrupt pin of the processor.The interrupt routine puts the captured data into a global circular buffer.In the main loop you check if anything is in the circular buffer, and if, so send it out to the USB. You need to make sure interrupts are not turned off when sending data out the USB port to prevent excessive blocking.It might also help to have an external latch of the data to improve reliability.