Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify Connected behavior #34

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
+6 −2
Open

Clarify Connected behavior #34

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
c0e6764
Clarify `Connected` behavior between host and device
bruno-f-cruz Jan 28, 2024
b4cee22
Bump version
bruno-f-cruz Jan 28, 2024
169bd3d
Update Device.md
bruno-f-cruz Apr 10, 2024
3b78341
Clarify host behavior
bruno-f-cruz Apr 18, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions Device.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,9 @@ A Harp Device is expected to implement the following `Operation Modes`:
- *`Speed Mode:`* Allows the implementation of a different and specific communication protocol. On this mode, the Harp Binary Protocol is no longer used. The specific protocol designed must implement the possibility to exit this mode.

The mandatory Operation Modes are the **`Standby Mode`** and **`Active Mode`**. The **`Speed Mode`** is optional and, in many of the applications, not needed.
It’s strongly recommended that a Harp Device acting as peripheral should continuously check if the communication with the host is active and healthy. If this doesn’t happen over the last 3 seconds, the Harp Device should go to Standby Mode and flush/destroy its TX buffer.
Harp Devices should continuously check if the communication with the host is active and healthy. This status check will be largely dependent on the transport layer implementing the harp protocol between host and device. Each implementation should clearly distinguish between `Connected` and `Not Connected` states, and it is up to the developer to decide how to implement this status check. When the device transitions to the `Not Connected` state, it should immediately enter `Standy Mode` and stop transmission of further event messages.

As an application example, devices using USB as the transport layer can poll for an active USB connection by checking that the state of the DTR pin is set to `HIGH`. Once this pin is set `LOW` it may be assumed that the host closed the connection and the device should enter `Standby Mode`. In this case, the host is responsible for setting the state of the DTR line when opening or closing a new connection.


### **Table - List of available Common Registers**
Expand Down Expand Up @@ -452,4 +454,6 @@ When the value of this register is above 0 (zero), the device’s timestamp will

- v1.9.1
* Remove table of contents to avoid redundancy with doc generators.
* Minor improvements to clarity of introduction.
* Minor improvements to clarity of introduction.
- v1.9.2
* Clarify `Connected` behavior between host and device and add application examples.