Possible bugfix in DHB #469
No reviewers
Labels
No Label
API Change
Breaking API Change
bug
build
cosmetics
Documentation
duplicate
feature
help wanted
hotfix
invalid
question
Refactor
Tests
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: fsfw/fsfw#469
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "eive/fsfw:mueller/dhb-periodoc-reply-fix"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The delayCycles variables needs to be initialized differently
for periodic replies. It is initialized to the
maxDelayCycles
value now.enableReplyInReplyMap
was not called in my specific use case because no commands were being sent. delayCycles needs to be initiaited to a non-zero value in the case of a periodic reply because otherwise,the wrong branch inenableReply
will be taken (see line ~800).The intended design was that periodic replies could be enabled and disabled.
insertInReplyMap()
is only the definition of the reply and should not enable it directly.Enabling is performed by calling
updateReplyMapEntry()
and thus settingdelayCycles
.If you would like to make this a bit clearer, there could be an
[en|dis]ablePeriodicReply
which has less parameters thanupdateReplyMapEntry()
. Prbably none. It only verifies that the reply is indeed periodic and then sets thedelayCycles
.Sounds good. So far, I have only needed periodic replies for devices like GPS which just start talking. There should be some form of decoumentation specifying what to do for that use case as well.
I updated the PR
Looks good