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.

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

Generated Swift code won't compile #878

Open
JetForMe opened this issue Nov 28, 2023 · 1 comment
Open

Generated Swift code won't compile #878

JetForMe opened this issue Nov 28, 2023 · 1 comment

Comments

@JetForMe
Copy link

JetForMe commented Nov 28, 2023

When generating code for the minimal dialect:

$python3 -m pymavlink.tools.mavgen --lang=Swift --wire-protocol=2.0 --output=generated/swift/mavlink/v2.0 message_definitions/v1.0/minimal.xml

The generated code has some deprecation warnings, but also has a handful of errors like this:

…/MAVLink/swift-test/Sources/MAVLinkGenerated/ProtocolVersionMinimalMsg.swift:31:34: error: integer literal '300' overflows when stored into 'UInt8'
    public static let id = UInt8(300)
                                 ^

I'd be willing to do some work on the generator to get it brought up to modern Swift, although I’m much more a Swift developer than a Python dev. I’d also like to add support for MAVLink version 2 (the docs say it doesn’t, but the invocations I see show --wire-protocol=2.0, so I’m not sure what’s happening there).

Update: Doing a little more investigating, I see this is due to an experimental message defined in minimal.xml:

    <message id="300" name="PROTOCOL_VERSION">
      <wip/>
      <!~~ This message is work-in-progress and it can therefore change. It should NOT be used in stable production environments. ~~>
      <description>Version and capability of protocol version. This message can be requested with MAV_CMD_REQUEST_MESSAGE and is used as part of the handshaking to establish which MAVLink version should be used on the network. Every node should respond to a request for PROTOCOL_VERSION to enable the handshaking. Library implementers should consider adding this into the default decoding state machine to allow the protocol core to respond directly.</description>
      <field type="uint16_t" name="version">Currently active MAVLink version number * 100: v1.0 is 100, v2.0 is 200, etc.</field>
      <field type="uint16_t" name="min_version">Minimum MAVLink version supported</field>
      <field type="uint16_t" name="max_version">Maximum MAVLink version supported (set to the same value as version by default)</field>
      <field type="uint8_t[8]" name="spec_version_hash">The first 8 bytes (not characters printed in hex!) of the git hash.</field>
      <field type="uint8_t[8]" name="library_version_hash">The first 8 bytes (not characters printed in hex!) of the git hash.</field>
    </message>

Commenting that out allowed me to helloworld the Swift code.

@shancock884
Copy link
Contributor

It looks like if you specify --wire-protocol 1.0 on the command line, it will generate only messages which have ids up to 255 - which makes sense as id field is only 1 byte in Mavlink 1.
But when you specify --wire-protocol 2.0 on the command line, it has a crack at including all messages, but other aspects of the code don't really support this, such as id not being big enough for 3 byte integer and other Mavlink2 header fields not being created in the payload.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants