public_regulated_data_types
public_regulated_data_types copied to clipboard
Regulated DSDL definitions for Cyphal (standard and third-party)
I found it to be often useful to have small fixed-size arrays for representation of arbitrary arrays and matrices without the array prefix: - `uavcan.primitive.array.Real16x2` ... `Real16x9` - `uavcan.primitive.array.Real32x2` ......
The `uavcan.can.iface` standard register specifies a key where you can change can interface to be used. ``` # REGISTER NAME PATTERN TYPE FLAGS RECOMMENDED DEFAULT # uavcan.can.iface string mutable, persistent...
Is there a reason that every `si/sample` type re-implements the corresponding `si/unit` type, instead of combining the timestamp with the corresponding `si/unit/` type? _Originally posted by @JacobCrabill in https://github.com/UAVCAN/public_regulated_data_types/pull/81#discussion_r501822164_
We need to have this script transformed into a standalone reusable DSDL linter: https://github.com/UAVCAN/public_regulated_data_types/blob/master/verify Business requirements: - Implemented as a standalone Python script dependent only on PyDSDL. - Ensure that...
I do concur with @thirtytwobits about having a sample point option as well. Or at least thinking about minimal sample point or something like that. MCU's can indeed calculate timings...
We need help with supporting DSDL in: - https://github.com/github/linguist - https://github.com/pygments/pygments
E.g., `uavcan.udp.dscp`. This is related to https://github.com/OpenCyphal-Garage/libudpard/issues/16
The new versions should take advantage of the new string support in DSDL: https://github.com/OpenCyphal/pydsdl/pull/97.
See https://github.com/DS-015/ds015
https://github.com/OpenCyphal/public_regulated_data_types/blob/70573cb98a346f5a9aee54ce421a8a79700df2b4/uavcan/register/384.Access.1.0.dsdl#L109 `uavcan.pub.*.prio` with 0 for the highest priority and 7 for the lowest.