Skip to content

Commit e5e55b7

Browse files
committed
Discourage polymorphic behavior (Discourage register polymorphic behavior #26)
1 parent f95a5be commit e5e55b7

File tree

1 file changed

+36
-4
lines changed

1 file changed

+36
-4
lines changed

BinaryProtocol-8bit.md

Lines changed: 36 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -107,7 +107,7 @@ If the bit is set, indicates that the [`Payload`] contains integers with signal.
107107

108108
### Commands
109109

110-
The device that implements this Harp Protocol receives `Write` and `Read` commands from the controller, and replies with a copy of the message, timestamped with the hardware time at which the command was applied. This behavior is core to the protocol and is expected to be implemented by all devices that use it. As a rule of thumb, for each `Write` or `Read` command, a single reply message should be returned from the device. The message should be emitted from the same register that the command was issued to.
110+
The device that implements this Harp Protocol receives `Write` and `Read` commands from the controller, and replies with a copy of the message, timestamped with the hardware time at which the command was applied. This behavior is core to the protocol and is expected to be implemented by all devices that use it. As a rule of thumb, for each `Write` or `Read` command, a single reply message should be returned from the device. The message should be emitted from the same register that the command was issued to. It should be noted that the payload of the returned value might be different from the one issued by the command, as the device can operate/transform the issued `Write` command. ([see "Register Polymorphism" section below](#register-polymorphism)).
111111

112112
> **Note**
113113
>
@@ -129,20 +129,51 @@ We will use the following abbreviations:
129129

130130
The timestamp information in the [RPL] represents the time when the register with [Address] was updated.
131131

132-
### Read Message
132+
#### Read Message
133133

134134
- [CMD] **Controller**: `1` `4` `Address` `Port` `PayloadType` `Checksum`
135135
- [RPL] **Device**: `1` `Length` `Address` `Port` `PayloadType` `Timestamp<T>` `Checksum` OK
136136
- [RPL] **Device**: `9` `10` `Address` `Port` `PayloadType` `Timestamp<T>` `Checksum` ERROR
137137

138138
The timestamp information in the [RPL] represents the time when the register with [Address] was read.
139139

140-
### Event message
140+
#### Event message
141141

142142
- [EVT] **Device**: `3` `Length` `Address` `Port` `PayloadType` `Timestamp<T>` `Checksum` OK
143143

144144
The timestamp information in [EVT] represents the time when the register with [Address] was read.
145145

146+
### Intended Usage
147+
148+
#### Register polymorphism
149+
150+
151+
While it is possible to have different types of data in the same register, we **STRONGLY** discourage this practice. The protocol was designed to be as simple as possible, and having different types of data in the same register would make the parsing of the messages unnecessary more complex. As a rule, each register should: (1) have a single data type (e.g. `U8`) for all message types (`Read`, `Write`, `Event`), (2) the payload should have the same "function"/"meaning" regardless of the message type (see examples below), and (3) the payload data should be of the same size for all message types.
152+
It should be noted that this guide doesnt necessarly mean that the payload issued by a `Write` message should be the same as the one issued by a `Read` message, as the device can operate/transform the issued `Write`
153+
154+
155+
> **Examples**
156+
>
157+
> Consider the following register:
158+
>
159+
>```
160+
> CameraFrequency:
161+
> - Address: 32
162+
> - Type: U8
163+
> - Access: Raad, Write
164+
> - Description: Sets the frequency of the camera in Hz.
165+
>```
166+
>
167+
> DO NOT ❌
168+
>
169+
> - Return the frequency in U16 for a `Read` command and the frequency in U8 for a `Write` command. (i.e. Share the same data type.)
170+
> - Return the frequency in Hz for a `Read` command and the period in seconds for a `Write` command. (i.e. share the same function/meaning.)
171+
>
172+
> DO ✅
173+
>
174+
> - Return the frequency in U8 for both a `Read` and `Write` command.
175+
> - Return the frequency in Hz for both a `Read` and a `Write` command.
176+
> - `Write` a value of `101` to set the frequency, but both `Read` and `Write` return the frequency of 100Hz. This behavior is perfectly acceptable as the device might not be able to set the frequency to the exact value requested by the controller, and instead returns the value that was set.
146177
---
147178
148179
## Release notes:
@@ -182,4 +213,5 @@ The timestamp information in [EVT] represents the time when the register with [A
182213
* Change device naming to Controller and Device.
183214
184215
- v1.4.2
185-
* Clarify request-reply contract.
216+
* Clarify request-reply contract.
217+
* Discourage the use of polymorphic register behavior.

0 commit comments

Comments
 (0)