Invalid autocode for `.init` of components with `async`+`serial` port

[Kronos3]

F´ Version
Affected Component

---

Problem Description

For an active/queued component that declares an async, serial-kind port, fpp-to-cpp generates a component init() with an extra, non-defaulted msgSize parameter ahead of the (defaulted) instance parameter:

// Generated in WasmSequencerComponentAc.hpp
void init(
    FwSizeType queueDepth, //!< The queue depth
    FwSizeType msgSize,    //!< The message size
    FwEnumStoreType instance = 0 //!< The instance number
);

fpp-to-cpp is generating the wrong .init invocation in the topology autocode

// Generated in RefTopologyAc.cpp
Ref::wasmSeq.init(QueueSizes::Ref_wasmSeq, InstanceIds::Ref_wasmSeq);
Ref::wasmSeq2.init(QueueSizes::Ref_wasmSeq2, InstanceIds::Ref_wasmSeq2);

We are calling init with the instance id in the msgSize spot instead. The instance defaults to 0 so all components get the same ID

Context / Environment

Latest devel

Execute fprime-util version-check and share the output.

Operating System: Darwin
CPU Architecture: arm64
Platform: macOS-26.5.2-arm64-arm-64bit-Mach-O
Python version: 3.13.11
CMake version: 3.26.0
Pip version: 25.1.1
Pip packages:
    fprime-tools==4.3.0
    fprime-gds==4.3.0
    fprime-fpp==3.3.0
Project submodules:

How to Reproduce

1. Create a component with a an async input port portNameIn: serial
2. Instantiate it into the topology

Expected Behavior

We should be calling .init with three arguments in the autocode

[Kronos3]

This also points to a need for FPP to specify which message size to use here... We may need an additional msg size 10 clause in the instance specifier:

instance c: C base id 0x200 queue size 10 stack size 10000 msg size 512

@bocchino Thoughts?

[bocchino]

Good catch!

The framework design may need some work here. Async serial input ports are apparently a feature of F Prime that no one has tried to use until now. If we need a message size for a serial port, I think it would be better to specify it as a global configuration and/or specify it in the port instance, like this:

async input port serialIn: serial size 100

Otherwise, as you suggest, we would have to have a message size attribute for the instance that would be required if and only if the component has async serial input ports, otherwise invalid. This seems awkward to implement (extra checks, new keywords, new kinds of errors) and awkward for the developer who has to specify this extra attribute in the instance because of a feature of the component. It couples the instance definition to the component ports in an unexpected way. It seems better to specify the attribute when the feature is introduced into the component.

Also, as part of this issue, we should address the following:

• The generated code for the message size doesn't look right. In particular, it uses FwEnumStoreType in a way that looks wrong.
• We should strongly consider taking the default value out of the instance ID. I think that is a relic of the time when users would write init calls by hand. Default values need to be used with caution, for precisely this reason -- they can silently tolerate incorrect or missing arguments.

[bocchino]

It seems better to specify the attribute when the feature is introduced into the component.

Maybe the counterargument is that one might want to tune the message size per instance. But is this kind of tuning any more required, than say, a string size?

[bocchino]

Also, this is a feature that apparently no one uses, so it doesn't seem like we should go to heroic efforts to make it tunable.

[bocchino]

Maybe the counterargument is that one might want to tune the message size per instance.

Also, my proposal above is not tunable per instance, but it is tunable per port, and the value can be a configurable constant -- again like strings.

[bocchino]

If we do add the attribute to the instance, we could say serial size instead of message size, to be consistent and to avoid a new keyword.