Use correct enum size when generating tlm packet structures

[nathancheek]

Related Issue(s)	#4261
Has Unit Tests (y/n)	no new unit tests
Documentation Included (y/n)	no new documentation
Generative AI was used in this contribution (y/n)	no

---

Change Description

This PR modifies the tlm_packet_gen.py autocoder to pull in the correct size of each enum type when generating PacketsAc.cpp.

Rationale

Prior to this change, the autocoder assumes a hardcoded 4-byte length for each enum channel, even though TopologyAppDictionary.xml and TopologyDictionary.json files are generated with the proper enum length. This leads to a discrepancy, where a GDS using the above Dictionary files will have a different packet definition than the fprime deployment is using to generate telemetry packets.

This change brings the fprime telemetry packet generation process into consistency with the Dictionary files, at least where enum lengths are concerned.

Notes

The primary fix is to the process_enum_files() function, which is modified to grab the serialize_type from the parsed XML via enum_model, then evaluate that string (likely 'U8', 'U16', etc) using get_type_size(), rather than assuming a hardcoded 4-byte length.

A secondary fix is to remove what I believe to be dead code in other parts of the file. It looks like a past version of the autocoder stored enum types in a tuple rather than a string, so there are 3 instances (processing typical channels, processing structs/serializables, and processing arrays) where the type was being checked against type(tuple()) and in True cases, the type was assumed to be an enum with size of 4 bytes. Since enum types are currently stored as strings, these 3 hardcoded if statements never resolve True, so their hardcoded values don't really matter. But I've removed them for clarity.

Testing/Review Recommendations

I've confirmed the following:

• Tested successfully on internal deployment:
  • The enum length disparity is resolved. fprime-gds now happily displays packetized 1-byte, 2-byte, and 4-byte enum channels
  • Other tlm channel types work properly:
    • Numeric values (U8, U16, U32, etc)
    • Integer arrays (U8, U16, U32)
    • Enum arrays (U8, U16, U32)
    • Structs/serializables packed with integers, enums (U8, U16, U32), and strings
    • Strings
• Ref deployment compiles, seems to work correctly via fprime-gds, and passes unit tests

Future Work

There are some other hardcoded and possible out-of-date assumptions in this autocoder script that could be looked at, but it seems the autocoder was rewritten for F Prime 4.0, so there may be no need to improve this script further.

AI Usage (see policy)

N/A

[LeStarch]

The CI errors are caused by a checkout of F Prime devel, not the current branch.

[nathancheek]

@LeStarch Do you need anything more from me in order to get this PR merged?

[LeStarch]

As you can see, the CI situation is not working. Need to determine what to do about it.

[nathancheek]

I just pushed a commit that should fix the CI issues, by manually specifying v3.6-compatible refs for the relevant repositories. All the actions ran successfully in my test branch, except for the two waiting for a Raspberry Pi to pick up the job.

[nathancheek]

I see 2 CI failures.

The RPI LedBlinker failure I think was due to not specifying sparse-checkout-cone-mode: false within single-file sparse checkouts, which was fixed later in 8ead55a. I have made the same fix and re-pushed.

The macOS-CI failure I'm less sure about. The action seemed to run fine under my repo, but is failing on fprime/Drv/TcpServer/test/ut/TcpServerTester.cpp:209 with client.open(client_fd) returning Drv::SOCK_SUCCESS (0), when it's expected to return Drv::SOCK_FAILED_TO_CONNECT (-4).

[LeStarch]

Might be one of the transient errors that occurred during this era of the cod base.

[SterlingPeet]

@LeStarch those errors both look suspect to me, does poking them to re-run tend to work? We can't try that, I'm curious if theres a race condition that can be overcome by hitting the re-run button a few times.

[LeStarch]

I cannot explain this RPI error, but I am of the belief we should merge over this objection. If it does not pass now, I will do this.