Issues with CommandMessage / MessageQeueueMessage #102

New Issue

muellerr · 2020-06-09T18:01:02+02:00

muellerr commented

2020-06-09 18:01:02 +02:00

I am trying to implement the message forwarding for Housekeeping message. Unfortunately, I have issues with the current handling of messages.

I can't cast the command message to another message type.
I basically want to have a third uint32_t parameter for the HK messages. The command message only offers two uint32_t parameters.

There are 3 possible solutions.

Add getParameter3() to the command message interface or inherit from command message and add getParameter3 there. I'm not happy with that. The command message should not change just because I need one more parameter, especially because most queues will just use these regular command messages (and can have the smaller size therefore). Dynamic casting does not work in for simply casting to another message type.
The second solution is to instantiate my new message (which is almost identical to CommandMessage) and copy the content of the command message into the new message. Not ideal. Unnecessary copying, the data is already there, I just cant access it.
The clean solution requires a little bit more work. To increase the flexibility, CommandMessage should operate on the buffer instead of owning it. This can be achieved
by only owning a pointer to the MessageQueueMessage instead of inheriting from it. That way, I can simply pass that pointer to another message type (like HK message with 3 parameters) to access the third parameter. Or a fourth. Or do some other magic.

Unfortunately, this means a little bit more writing work and a lot of changes in existing code. For example, the command message instantiations would change (for every command message instantiation):

	MessageQueueMessage message;
	CommandMessage command(&message);
	ReturnValue_t result = commandQueue->receiveMessage(&command);
	if (result != RETURN_OK) {
		return;
	}

The MQM owns the internalBuffer. The command message then operates on that buffer. And now the only thing I have to do is to pass the message address to another message type which operates on the internal buffer.

I also encountered another issue: The message queue IF is coupled to the MAX_MESSAGE_SIZ (24 bytes). MQM pointers are used. This would be a perfect place for an interface. All functions the message queue implementations use can mostly be specified in an interface.
This new MQM IF would have most of the interface of MQM as abstract functions. But now I could pass messages with different sizes, and access their size with the abstract function.

UPDATE: I had another look at MQM: An additional getMaximumMessageSize() function and getMessageSize() would propably be necessary in the interface.

All messages would implement this interface, for example the CommandMessage implements the interface too, but just calls the MQM functions by using the pointer to the MQM to implement all abstract functions.

I implemented these changes and tested them, and everything worked as before. Unfortunately, I can not test all parts of the FSFW right now, and this changed a lot of files, because command mesages are used in many places. But DHB/CSB/PSB were tested and worked as before.

I am trying to implement the message forwarding for Housekeeping message. Unfortunately, I have issues with the current handling of messages. I can't cast the command message to another message type. I basically want to have a third uint32_t parameter for the HK messages. The command message only offers two uint32_t parameters. There are 3 possible solutions. 1. Add `getParameter3()` to the command message interface or inherit from command message and add getParameter3 there. I'm not happy with that. The command message should not change just because I need one more parameter, especially because most queues will just use these regular command messages (and can have the smaller size therefore). Dynamic casting does not work in for simply casting to another message type. 2. The second solution is to instantiate my new message (which is almost identical to CommandMessage) and copy the content of the command message into the new message. Not ideal. Unnecessary copying, the data is already there, I just cant access it. 3. The clean solution requires a little bit more work. To increase the flexibility, CommandMessage should operate on the buffer instead of owning it. This can be achieved by only owning a pointer to the MessageQueueMessage instead of inheriting from it. That way, I can simply pass that pointer to another message type (like HK message with 3 parameters) to access the third parameter. Or a fourth. Or do some other magic. Unfortunately, this means a little bit more writing work and a lot of changes in existing code. For example, the command message instantiations would change (for every command message instantiation): ```cpp MessageQueueMessage message; CommandMessage command(&message); ReturnValue_t result = commandQueue->receiveMessage(&command); if (result != RETURN_OK) { return; } ``` The MQM owns the internalBuffer. The command message then operates on that buffer. And now the only thing I have to do is to pass the message address to another message type which operates on the internal buffer. I also encountered another issue: The message queue IF is coupled to the MAX_MESSAGE_SIZ (24 bytes). MQM pointers are used. This would be a perfect place for an interface. All functions the message queue implementations use can mostly be specified in an interface. This new MQM IF would have most of the interface of MQM as abstract functions. But now I could pass messages with different sizes, and access their size with the abstract function. UPDATE: I had another look at MQM: An additional `getMaximumMessageSize()` function and `getMessageSize()` would propably be necessary in the interface. All messages would implement this interface, for example the CommandMessage implements the interface too, but just calls the MQM functions by using the pointer to the MQM to implement all abstract functions. I implemented these changes and tested them, and everything worked as before. Unfortunately, I can not test all parts of the FSFW right now, and this changed a lot of files, because command mesages are used in many places. But DHB/CSB/PSB were tested and worked as before.

muellerr added the

feature

label 2020-06-09 18:02:03 +02:00

muellerr added the

API Change

label 2020-06-09 18:09:56 +02:00

muellerr commented

2020-07-06 12:56:48 +02:00

UPDATE: First solution was now chosen: getParameter3 is used now.

UPDATE: First solution was now chosen: `getParameter3` is used now.

muellerr closed this issue

2020-07-06 12:56:51 +02:00