From c65ec90484edfbddf4c5ba824066717e5d39fde3 Mon Sep 17 00:00:00 2001 From: zvecr Date: Thu, 5 May 2022 21:05:10 +0100 Subject: [PATCH] Fix a few mistakes in docs --- data/xap/xap_0.0.1.hjson | 4 ++-- docs/xap_0.0.1.md | 4 ++-- docs/xap_0.1.0.md | 5 +++-- docs/xap_0.2.0.md | 5 +++-- 4 files changed, 10 insertions(+), 8 deletions(-) diff --git a/data/xap/xap_0.0.1.hjson b/data/xap/xap_0.0.1.hjson index 382075b941..48325247bf 100755 --- a/data/xap/xap_0.0.1.hjson +++ b/data/xap/xap_0.0.1.hjson @@ -46,7 +46,7 @@ Communication generally follows a request/response pattern. - Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing repsonse messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. + Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing response messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. This token is followed by a `u8` signifying the length of data in the request. ''' @@ -157,7 +157,7 @@ response_header: { name: Response Header - description: Packet format for inbound data. + description: Packet format for outbound data. type: struct struct_length: 4 struct_members: [ diff --git a/docs/xap_0.0.1.md b/docs/xap_0.0.1.md index afa23c85c3..313ab9e488 100644 --- a/docs/xap_0.0.1.md +++ b/docs/xap_0.0.1.md @@ -27,14 +27,14 @@ This list defines the terms used across the entire set of XAP protocol documenta | _ID_ | A single octet / 8-bit byte, representing Subsystem or Route index. | | _Request Header_ | Packet format for inbound data. Takes the format:
`token` - token
`u8` - length | | _Response Flags_ | An `u8` containing the status of the request. | -| _Response Header_ | Packet format for inbound data. Takes the format:
`token` - token
`response_flags` - flags
`u8` - length | +| _Response Header_ | Packet format for outbound data. Takes the format:
`token` - token
`response_flags` - flags
`u8` - length | | _Token_ | A `u16` associated with a specific request as well as its corresponding response. | ## Requests and Responses Communication generally follows a request/response pattern. -Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing repsonse messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. +Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing response messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. This token is followed by a `u8` signifying the length of data in the request. diff --git a/docs/xap_0.1.0.md b/docs/xap_0.1.0.md index c61ee1df60..73a76680c5 100644 --- a/docs/xap_0.1.0.md +++ b/docs/xap_0.1.0.md @@ -29,17 +29,18 @@ This list defines the terms used across the entire set of XAP protocol documenta | _Secure Route_ | A _route_ which has potentially destructive consequences, necessitating prior approval by the user before executing. | | _Subsystem_ | A high-level area of functionality within XAP. | | _Unlock sequence_ | A physical sequence initiated by the user to enable execution of _secure routes_. | +| _Broadcast Header_ | Packet format for broadcast messages. Takes the format:
`token` - token
`u8` - type
`u8` - length | | _ID_ | A single octet / 8-bit byte, representing Subsystem or Route index. | | _Request Header_ | Packet format for inbound data. Takes the format:
`token` - token
`u8` - length | | _Response Flags_ | An `u8` containing the status of the request. | -| _Response Header_ | Packet format for inbound data. Takes the format:
`token` - token
`response_flags` - flags
`u8` - length | +| _Response Header_ | Packet format for outbound data. Takes the format:
`token` - token
`response_flags` - flags
`u8` - length | | _Token_ | A `u16` associated with a specific request as well as its corresponding response. | ## Requests and Responses Communication generally follows a request/response pattern. -Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing repsonse messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. +Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing response messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. This token is followed by a `u8` signifying the length of data in the request. diff --git a/docs/xap_0.2.0.md b/docs/xap_0.2.0.md index c61ee1df60..73a76680c5 100644 --- a/docs/xap_0.2.0.md +++ b/docs/xap_0.2.0.md @@ -29,17 +29,18 @@ This list defines the terms used across the entire set of XAP protocol documenta | _Secure Route_ | A _route_ which has potentially destructive consequences, necessitating prior approval by the user before executing. | | _Subsystem_ | A high-level area of functionality within XAP. | | _Unlock sequence_ | A physical sequence initiated by the user to enable execution of _secure routes_. | +| _Broadcast Header_ | Packet format for broadcast messages. Takes the format:
`token` - token
`u8` - type
`u8` - length | | _ID_ | A single octet / 8-bit byte, representing Subsystem or Route index. | | _Request Header_ | Packet format for inbound data. Takes the format:
`token` - token
`u8` - length | | _Response Flags_ | An `u8` containing the status of the request. | -| _Response Header_ | Packet format for inbound data. Takes the format:
`token` - token
`response_flags` - flags
`u8` - length | +| _Response Header_ | Packet format for outbound data. Takes the format:
`token` - token
`response_flags` - flags
`u8` - length | | _Token_ | A `u16` associated with a specific request as well as its corresponding response. | ## Requests and Responses Communication generally follows a request/response pattern. -Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing repsonse messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. +Each request needs to include a _token_ -- this `u16` value prefixes each outbound request from the host application and its corresponding response, allowing response messages to be correlated with their request, even if multiple host applications are communicating with the firmware simultaneously. Host applications should randomly generate a token ID for **every** outbound request, unless using a reserved token defined below. This token is followed by a `u8` signifying the length of data in the request.