FPP Integer Limitations

[LeStarch]

When setting ids in the FPP model an artificial limitation arises from the FPP modeling language:

fpp-to-xml
fprime/Ref/Top/instances.fpp: 88.39
  instance SG1: Ref.SignalGen base id 0xFFFF2100 \
                                      ^
error: invalid integer value 4294910208

Here the base id is valid according to F´ as the ID type for all types is "U32". However, the FPP tooling flags an error as it is likely using a 32-bit signed integer.

This presents several concerns in practice:

1. Some projects assign ID ranges to designate function/purpose or to help organize complex topologies. An artificial limit from the modeling setup in this case disrupts this style planning

Example	Range
Uplink	0x0000000 - 0x7FFFFFFF
Downlink	0x8000000 - 0xFFFFFFFF

2. Using an ID type smaller than I32 allows the model to express IDs that are invalid in the F´  context. i.e. a project may choose an ID type of U8, but the model allows base ids through the range of I32.

At the very least, the users guide should discuss the limitations to integer and base id types. A cursory look through the user guide revealed no discussion on ranges for integers or base IDs in the FPP model.

[bocchino]

These are good points!

Point 1 is addressed here: #197. We should switch to using BigInt to represent integer values that don't have explicit bounds in the spec. Scala does not natively support unsigned integers. I think it's a JVM issue.

Point 2 is addressed by #102 and #113. #102 will let us check generally that constants assigned to typed variables fit inside the bounds implied by the type. #113 will let us specify the F Prime opcode type in FPP. Right now we can't do that: we specify it in C++, so it's unknown to the model.

[bocchino]

Closing this issue as addressed elsewhere. @LeStarch let me know if you think I've missed anything in documenting the other issues.

[LeStarch]

Agreed, this should be closed. Thanks for linking those issues!