Make lastSentCommand member of DHB #253

New Issue

muellerr · 2020-11-04T10:57:27+01:00

muellerr commented

2020-11-04 10:57:27 +01:00

I have seen in the LIS3 code that the last command is cached to easily identify the response.

I think it would be nice to have this as a member which is set automatically by the DeviceHandlerBase.

I have seen in the LIS3 code that the last command is cached to easily identify the response. I think it would be nice to have this as a member which is set automatically by the DeviceHandlerBase.

muellerr added the

feature

label 2020-11-04 10:57:27 +01:00

gaisser commented

2020-11-13 15:16:09 +01:00

If you think of remebering only the CommandId: DHB does provide a feature to know which commands are sent. LastCommand is not available for the reason that multiple different commands might be executing at the same time, this makes this feature request special to "one command at a time" Devices. But even in those cases we know which command is still in state "isExecuting" and therefore the last sent command.

If you think of remembering the full command, this might be a little bit more difficult. In the "one command at a time" Device, it might still be in its commandBuffer.

But in any case, a user implementation can have that "last command". This might be the safest way to use this because in the more general way it will not be clear when to clear the last command. Especially, if you can sent another command (with a different CommandId) before the last reply was received.

If you think of remebering only the CommandId: DHB does provide a feature to know which commands are sent. LastCommand is not available for the reason that multiple different commands might be executing at the same time, this makes this feature request special to "one command at a time" Devices. But even in those cases we know which command is still in state "isExecuting" and therefore the last sent command. If you think of remembering the full command, this might be a little bit more difficult. In the "one command at a time" Device, it might still be in its commandBuffer. But in any case, a user implementation can have that "last command". This might be the safest way to use this because in the more general way it will not be clear when to clear the last command. Especially, if you can sent another command (with a different CommandId) before the last reply was received.

muellerr referenced a pull request that will close this issue

2020-12-08 16:03:15 +01:00

device handler uses local pools now #299

gaisser commented

2020-12-10 17:14:51 +01:00

From #299:

DeviceCommandId_t getPendingCommand() const;

returns the last pending command from the cookie info. For DHBs with only one pending command this is equal to the feature you want.

From #299: ``` DeviceCommandId_t getPendingCommand() const; ``` returns the last pending command from the cookie info. For DHBs with only one pending command this is equal to the feature you want.

gaisser closed this issue

2020-12-10 17:22:56 +01:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fsfw/fsfw#253