EDR Port Timings

From EMIT Controls

The EDR has several settings related to port timings for communication. This page describes how those settings work.

Edr port timing.png

The general sequence is:

  • Master sees that a batch request is due, aka a set of requests covering all the registers. This happens every "Batch Request (s)" duration, by default this is 60 seconds.
  • The master will switch the bus to WRITE and wait 1 ms
  • The master will write out the request
  • The master will wait a reasonable delay for the message (see note 1)
  • The master will wait an additional "Read delay us" setting before switching bus to read
    • Note that if the master doesn't wait long enough, the message may not be done sending at the time the bus is switched to READ. If the master waits too long, then the bus may not be clear when the slave device wants to respond.
  • The master switches the bus to READ / releases the bus and listens for response
  • The slave device has presumably been listening and at some point determines it should respond (see note 2)
  • The slave device switches to WRITE
  • The slave device writes out response
  • At some point the slave device releases the bus (see note 4)
  • If a slave never responds to a message in the read timeout, the master will consider the message failed (see note 3)
  • If the slave does respond, the master will read and process the response
  • The master will wait for "Write delay us" after receiving the response before switching back to WRITE
  • The master switches to WRITE and continues with the next message in the batch

Note 1: The built-in delay is intended to be enough to cover all the bytes in the master request. Sometimes this estimate is not good enough though, so the extra delay "read delay" needs to be added

Note 2: The time between the master request going out and the slave device responding will vary depending on the slave device. If it responds very quickly then the read delay needs to be short enough that the master is ready to read. If the slave device is slow to respond then the read delay is not very particular.

Note 3: The read timeout is by default 1 second (1000 ms). If the master doesn't see any response in this time period it will consider the message failed and continue with the next request. If the slave device does respond then the master will go immediately to the write delay, it won't have to wait for the full read timeout in normal successful cases.

Note 4: The time it takes for the slave device to release the bus will vary based on the slave device. Some devices will take a while to release the bus, so the write delay on the master needs to be longer to make sure the slave is ready to read when the next request goes out. Often it has to be increased from 1000 to 4000 us.