Author Topic: GPIB device handshake problem  (Read 1006 times)

0 Members and 1 Guest are viewing this topic.

Offline davorinTopic starter

  • Supporter
  • ****
  • Posts: 939
  • Country: ch
GPIB device handshake problem
« on: June 18, 2020, 07:59:44 am »
Good morning

Started 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 1

So in my init code I have:

Code: [Select]
  // Drive SN75160
  HAL_GPIO_WritePin(GPIOE, TE, GPIO_PIN_RESET);
  HAL_GPIO_WritePin(GPIOE, PE, GPIO_PIN_SET);

  // Drive SN75161
  HAL_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 advance
davorin
 

Offline davorinTopic starter

  • Supporter
  • ****
  • Posts: 939
  • Country: ch
Re: GPIB device handshake problem
« Reply #1 on: June 18, 2020, 08:31:29 am »
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: [Select]
CMD: 40 
CMD: 3F
CMD: 25
DAT: *
DAT: I
DAT: D
DAT: N
DAT: ?
CMD: 3F
CMD: 20
CMD: 45

when I send *IDN?...

Interestingly I don't get any error message with ibterm....as no message is sent back....

 

Offline rcjoy

  • Regular Contributor
  • *
  • Posts: 58
  • Country: us
Re: GPIB device handshake problem
« Reply #2 on: June 19, 2020, 04:32:41 am »

Ideally you would also pull the EOI line down with the last byte sent in the message.

 

Offline davorinTopic starter

  • Supporter
  • ****
  • Posts: 939
  • Country: ch
Re: GPIB device handshake problem
« Reply #3 on: June 19, 2020, 07:06:48 am »
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: [Select]
MTA0     - It is me talking now
UNLISTEN - Forget any previous Listen Address
MLA5     - Hey device 5, it is for you

*IDN?    - The actual payload with EOI set on last byte

UNLISTEN - Forget any previous Listen Address
MLA0     - It is me who is listening now
MTA5     - Hey device 5, it is up to you now who has to talk

So 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.

 

Offline rcjoy

  • Regular Contributor
  • *
  • Posts: 58
  • Country: us
Re: GPIB device handshake problem
« Reply #4 on: June 19, 2020, 09:37:42 am »

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: [Select]
          Ctrl  Bus
Hex Ascii Line  Cmd
--- ----- ----  ------
55      U ATN    MTA 21
3f      ? ATN    UNL
22      " ATN    MLA 2
2a      *
49      I
44      D
4e      N
3f      ?
 a        EOI
3f      ? ATN    UNL
35      5 ATN    MLA 21
42      B ATN    MTA 2
20       
41      A
4d      M
52      R
45      E
4c      L
20       
50      P
58      X
20       
33      3
30      0
2d      -
31      1
44      D
41      A
20       
 0        EOI
 

Offline davorinTopic starter

  • Supporter
  • ****
  • Posts: 939
  • Country: ch
Re: GPIB device handshake problem
« Reply #5 on: June 19, 2020, 09:45:06 am »
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?

 

Offline rcjoy

  • Regular Contributor
  • *
  • Posts: 58
  • Country: us
Re: GPIB device handshake problem
« Reply #6 on: June 19, 2020, 07:37:41 pm »
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.
 

Offline davorinTopic starter

  • Supporter
  • ****
  • Posts: 939
  • Country: ch
Re: GPIB device handshake problem
« Reply #7 on: June 19, 2020, 07:50:59 pm »
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;

 

Offline rcjoy

  • Regular Contributor
  • *
  • Posts: 58
  • Country: us
Re: GPIB device handshake problem
« Reply #8 on: June 21, 2020, 01:31:53 am »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf