RFC 0017 - Parameter type include encoding #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hamishwillee
force-pushed
the
rfc_param_type_has_encoding
branch
from
f368d2f
to
61c50ae
Compare
hamishwillee
commented
Mar 3, 2022
| The proposed pattern for the 10 new "cast" and 10 new "bytewise" flags is: `MAV_PARAM_TYPE_[BYTEWISE|CAST]_[UINT8|INT8|UINT16|INT16|UINT32|INT32|UINT64|INT64|REAL32|REAL64]`. | ||
| So for example, to send 32-bit integers you could use `MAV_PARAM_TYPE_INT32`, `MAV_PARAM_TYPE_BYTEWISE_INT32`, or `MAV_PARAM_TYPE_CAST_INT32` (by preference you would send using `MAV_PARAM_TYPE_BYTEWISE_INT32` if this was understood by the GCS. | ||
|
|
||
| Question? |
There was a problem hiding this comment.
@tridge a few questions here inline - e.g. do we need to indicate support for the old bits? Do we need flags for c-style encoding - after all, wouldn't you update in one go to the new type?
hamishwillee
commented
Mar 3, 2022
|
|
||
| ## Deprecation Path | ||
|
|
||
| TBD. |
There was a problem hiding this comment.
Would like advice on this. As stated below, it isn't clear to me what the end point is.
hamishwillee
commented
Mar 3, 2022
| - [ ] Do we need C-style encoding enums? | ||
| - [ ] What does the end point look like? i.e. the end protocol is more complicated. | ||
| - [ ] Are there other alternatives to aid in migration | ||
| - [ ] Is there any reason for PX4 to update to the new types? |
There was a problem hiding this comment.
This is relevant. It might be that the impetus is to have a clean common set of instructions at the end of the process.
hamishwillee
commented
Mar 3, 2022
| The design has two parts: | ||
| - New enum values in [MAV_PARAM_TYPE](https://mavlink.io/en/messages/common.html#MAV_PARAM_TYPE) that include the parameter type and encoding. | ||
| These allow the GCS to decode each param based on its type. | ||
| - [`PARAM_REQUEST_READ`](https://mavlink.io/en/messages/common.html#PARAM_REQUEST_READ) and [`PARAM_REQUEST_LIST`](https://mavlink.io/en/messages/common.html#PARAM_REQUEST_LIST) are extended with an 32 bit bitmask indicating which which `MAV_PARAM_TYPE` flags that the GCS/requester understands. |
There was a problem hiding this comment.
32 bits assumes you need to have a bit for old, cstyle and union flags.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This RFC proposes a modification to the parameter protocol that makes parameter value encoding explicit in the parameter itself, and allows a GCS to signal the encoding so that a flight stack can configure itself to send the right types if supported.
This will allow:
This eases migration from C-style parameter encoding to byte-wise encoding.
The changes can be used in parallel with the protocol bits that indicate support for bytewise/c style encoding (if you don't want to take these changes, a GCS would still be able to work with the flight stack).