Timothy Canham

@sobkulir I agree that in this example, you are doing dynamic allocation in Zephyr, since that is the API Zephyr provides. As a thought exercise, if you weren't using F...

@sobkulir So your objection is not so much the open call, but the `k_malloc` call (which I missed, sorry!).

Perhaps instead of a template or a bunch of `#define` macros, we could define it as a typedef that it overridable. Maybe in https://github.com/nasa/fprime/blob/devel/config/FpConfig.h.

Or that too!

Good idea! I opened this discussion: https://github.com/nasa/fprime/discussions/2306

Let's move the trade about where to define it to that discussion.

@rrieber I think the answer is both. We need a transaction ID along with a sequence ID so we can detect dropouts in the file transmission. The design of the...

@rrieber Belt and suspenders, which I'm a fan of. It makes the receiver a little simpler to just detect a break in the sequence. We could also add offset and...

Proposed requirements: 1) The component shall request buffers of a certain size specified during initialization. (Typically connect to `Svc/BufferManager`) 1) The component shall fill the buffer with `Fw::ComBuffer` copies until...

Added the following lines to `FpConfig.hpp`: ``` #ifndef BUILD_UT #define BUILD_UT 1 #endif ``` Then, these errors occur: ``` In file included from /home/tcanham/source/fprime/Fw/Types/Serializable.cpp:1: /home/tcanham/source/fprime/Fw/Types/Serializable.hpp:35:25: error: ‘ostream’ in namespace ‘std’...