nasa/fprime-tools

Update serialization and deserialization of enum types

bocchino opened this issue · 3 comments

The enum type is always serialized and deserialized to a single type (the Python ‘i’ type):

https://github.com/fprime-community/fprime-tools/blob/a65f0140e0e1f0ba40522767839059a78eaa3067/src/fprime/common/models/serialize/enum_type.py#L72-L100

We need to revise this code as follows:

  1. Store the integer width in the Python enum (fprime-tools).
  2. Represent the integer width in the AppDictionary.xml (nasa/fprime).
  3. Get the integer width from the AppDictionary.xml when creating the Python enum (fprime-gds).
  4. Use the stored integer width to serialize and deserialize the enum (fprime-tools).

Logging the issue here, but three repos are involved (fprime-tools, fprime-gds, and fprime).

@bocchino Why do we need to store the width of an enum type? Are we trying to support more than 255 members in an enum? It seems like 1 byte should be sufficient for most cases.

It's the bit width used to store a value of the type. For example, in FPP:

enum E1: U8 { A = 1, B = 2, C = 3 }
enum E2: U16 { A = 100, B = 200, C = 300 }

We need to get the U8 and U16 types all the way through the Python system.