Message buffers split write?

I’ve built an event bus, so when it fires the event looks like:

typedef struct {
  uint32_t event;
  union {
    void *ptr;
    uint32_t value;
  uint32_t flags;
  uint32_t params;
  uint16_t len;
  uint16_t publisherId;
} event_params_t;

// Message I want to pass into the stream buffer from the event
typedef struct {
  uint32_t event;
  uint32_t params;
  uint8_t data[256];
} event_msg_t;

and I know the data at the pointer is valid when inside the event callback. The issue I have is that I’d like to use message buffers to write a variable length message to the consuming task. However, in this case the only way to do so would be to memcpy to an event_msg_t first. Ideally I’d be able to send event and params, then followed by the data.

I’m not using dynamic allocation for this code, so it does complicate things.

Any other ideas how this could be accomplished? Basically the event has to be pretty lean because the bus calls a bunch of callbacks from within a high priority task.

You can not “post” data from two different sources with one call to a message buffer.

I would probably define the event_msg_t to contain all the data it needs so you can just post it (or as much of it as actually has usable data).

Well, the double copy was what I was trying to avoid. If event_msg_t contains all the data, I have to copy from the event pointer into event_msg_t , then the message buffer copies event_msg_t into the internal buffer.

I suppose its an architecture problem… I wonder how the overhead would compare vs a queue.

My thought is that the event_parms_t structure doesn’t hold much data, so copying that would be quick vs, needing to copy the data array.

OF course, if you have enough copies of the event_msg_t that you don’t need to actually send its contents, just its address, that also works.

Yes, this is an architecture problem, non-copy generally requires multiple buffers, and you just send buffer addresses. Having each piece use their own buffer requires copying.