Param getset for string types fails to be read by UAVCAN GUI tool

[kent.martin]

Hi,
I am having trouble using the string type for discover able parameters.
I checked the generated code from dsdl complier and it appears to be correct.
However UAVCAN gui tool either does not recognise the packet or comes up with garbled name and string value. Has anyone had success using String type parameters?
Here is a sample of my code generating the message.

uint8_t buffer[UAVCAN_PROTOCOL_PARAM_GETSET_RESPONSE_MAX_SIZE];
uavcan_protocol_param_GetSetResponse source = { 0 };
source.value.union_tag = UAVCAN_PROTOCOL_PARAM_VALUE_STRING_VALUE;
source.value.string_value.len = 2;
source.value.string_value.data = “Hi”;
source.max_value.union_tag = UAVCAN_PROTOCOL_PARAM_VALUE_EMPTY;
source.max_value.integer_value=0;
source.min_value.union_tag = UAVCAN_PROTOCOL_PARAM_VALUE_EMPTY;
source.min_value.integer_value = 0;
source.default_value.union_tag = UAVCAN_PROTOCOL_PARAM_VALUE_EMPTY;
source.default_value.integer_value = 0;
source.name.data = “Hi”;
source.name.len = 2;
uint16_t len = uavcan_protocol_param_GetSetResponse_encode(&source, buffer);
int result = canardRequestOrRespond(ins, transfer->source_node_id,
UAVCAN_PROTOCOL_PARAM_GETSET_SIGNATURE,
UAVCAN_PROTOCOL_PARAM_GETSET_ID, &transfer->transfer_id, transfer->priority, CanardResponse, &buffer[0], (uint16_t) len);

Thanks

[pavel.kirienko]

This is probably caused by the known bug in PyUAVCAN v0:

GetSet response encoder is broken (UAVCAN v0)

We do not have any resources committed to fixing that because v1 is the focus of the current development. Have you considered migrating to v1? Libcanard v1 is already usable:

Libcanard for UAVCAN/CAN v1 is released

Libcanard v0.100, implementing UAVCAN/CAN v1, is now available: Key features: Full test coverage and static analysis. Partial compliance with automatically enforceable MISRA C rules (compliance report not available). Detailed time complexity and memory requirement models for the benefit of real-time high-integrity applications. Purely reactive API without the need for background servicing. Support for CAN FD. Support for redundant transports. Compatibility with 8/16/32/64-bit platforms. The…

[kent.martin]

Hi,
Thanks, I thought this might be a bug in the gui tool.
We are already using V0 across mutliple platforms and code in a project under way.
I don’t think we can change this late in the development.
Is I use V1 on the gui tool only will it work with v0 ?
Otherwise we might have to fix the tool until we can change everything over.
That decision will be above me as it involves many others.
Thanks

[pavel.kirienko]

Is I use V1 on the gui tool only will it work with v0 ?

No.

Otherwise we might have to fix the tool until we can change everything over.

We would appreciate a pull request.

[David_Buzz]

Hi Pavel, reviewing " https://uavcan.org/ “, it says " Existing deployments will benefit from our commitment to provide long-term support and maintenance of UAVCAN v0-based systems.”, so i’d like to thankyou for taking the time and looking into this support/bug issue with v0 in accordance with your own documented policy. I don’t think saying “PRs welcome” ( or equivalent) and fobbing off a known bug to maybe hopefully be fixed by a 3rd party is really appropriate in this case, especially since it’s been a known bug for nearly 2 years.

[pavel.kirienko]

Of course. Our resources are limited and we distribute them according to our perception of the most immediate needs of the project. If you would like to discuss commercial support options, could you please email me at sales@zubax.com? Thanks!