[Dev-next-gen]

Related Issue(s)	#679
Has Unit Tests (y/n)	y
Documentation Included (y/n)	y
Generative AI was used in this contribution (y/n)	y

---

Change Description

When the model defines FW_CMD_ARG_BUFFER_MAX_SIZE, FW_LOG_BUFFER_MAX_SIZE, FW_PARAM_BUFFER_MAX_SIZE, or FW_TLM_BUFFER_MAX_SIZE, fpp-check now checks that the parameters of each command, the parameters of each event, the value of each parameter, and the value of each telemetry channel can fit in the corresponding buffer. The check uses the minimum serialized size, in which every string is empty, so it reports an error only when no value can fit. The constants stay optional: a model that does not define them is not checked.

In an F Prime build each module is analyzed with only its dependencies, so commands, events, parameters, and telemetry channels now depend on the buffer size constants when those have location specifiers. Without this, the check would never run in a real F Prime build.

The new check is CheckFrameworkBufferSizes, called from CheckComponentDefs, with a new SerializedSizeTooLarge error. The spec gains a "Buffer Sizes" section under framework definitions, each of the four specifier pages links to it, and the user's guide has a short example.

Rationale

#679 asks for FPP to fail the build when a definition does not fit in the buffers F Prime uses to carry it. Today such a model passes every check, the C++ compiles, and the generated code asserts at run time. I measured this on F Prime itself (framework plus Ref) with FW_COM_BUFFER_MAX_SIZE = 128: fpp-check accepts the model, and the CfdpManager unit tests stop on Assert: ".../CfdpManagerComponentAc.cpp:12371". With this change, fpp-check rejects that configuration with a single error, value of telemetry channel ChannelTelemetry: at least 232 bytes are required, but FW_TLM_BUFFER_MAX_SIZE is 122 bytes.

I used the minimum size rather than the maximum on purpose. My first version counted strings at their maximum size, and it rejected the default F Prime configuration (for example the OpenChip event of LinuxGpioDriver, which has three strings), even though that configuration works. With the minimum size, F Prime with the default configuration and with FW_COM_BUFFER_MAX_SIZE = 256 passes with no error.

Testing/Review Recommendations

• Nine new fpp-check cases under event, command, param, and tlm_channel: for each kind, one at exactly the limit that passes and one over it that fails, plus an event whose struct argument has a string member.
• A new fpp-depend case, framework_buffer_sizes, checks the new dependencies.
• The fpp-check and fpp-depend suites and sbt test (716 tests) pass, and the existing reference outputs are unchanged.
• I ran the patched fpp-check and the unmodified one on the F Prime framework plus Ref with FW_COM_BUFFER_MAX_SIZE set to 512, 256, and 128: no difference at 512 and 256, and the single error above at 128.
• A point worth a look: the minimum size counts a string as its FwSizeStoreType length only, including strings inside structs and arrays, because F Prime serializes a string with its actual length.

Future Work

A warning, or an option, for definitions whose maximum size exceeds the buffer could follow if missions find it useful. I left it out so that the check never rejects a configuration that works.

AI Usage (see policy)

Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5.5.

• Type of assistance: the design of the check, the code change, the test cases, the spec and user's guide text, and the text of this PR.
• Scope: everything in this PR.
• How it was done: the pipeline picked Add FPP model checking for FPP data types to fit in uplink/downlink buffers #679, implemented the check, and ran it against the F Prime framework and the Ref deployment. That run showed that the first version rejected the default configuration, which led to the minimum-size rule.
• Level of modification: nothing leaves the pipeline without a test that fails before the change and passes after it, run with the project's own tooling.

"Nothing this pipeline produces is submitted without human approval. The entire pull request — the code change, the tests, the documentation updates and this description — was reviewed by a human before the pipeline was allowed to submit it."

(@Dev-next-gen)

[bocchino]

@Dev-next-gen Thank you for submitting this PR. This is a feature we would like to have, but it is not in our plan for the next FPP release. The issues we are currently working on are here:

https://github.com/nasa/fpp/milestone/17

I'll close the PR for now, but we will keep it in mind when we are planning the release after next.