Explicitly state message type req-rply convention

[bruno-f-cruz]

We assume that for each message to request from the device, at least one message will always be returned from that register and with the same message type. This symmetry should be explicitly stated in the protocol.

[Poofjunior]

Possible solution:

In datasheets for digital MEMs sensors, I've seen these types of transactions disambiguated to request and reply. We could probably adopt that terminology here where:

• Harp Request Message
  • pc-to-device
  • does not include timestamp
• Harp Reply Message
  • device-to-pc
  • includes timestamp
  • reply message type field will be the same as the Request message type (i.e: write request issues a write reply.)

The documentation currently just refers to these two types as just Harp Messages, which is missing key info about what makes these subtypes different.

[bruno-f-cruz]

I can see how this simplifies things. My question is whether we want to move into a scenario where we assume that the protocol is indeed not symmetrical. For instance, nothing prevents two harp-devices from communicating with each other at this point, using the harp protocol. That being said, I can already see how this might naively break if we move in a direction where we use timestamps of write messages to schedule operations. Under such a scenario, two devices communicating with each other would essentially end up in an infinite message loop of write messages (as the RPLY from device 1 might schedule an event in device 2, and so on...).