for some devices it might be convenient to timeout replies by using the time instead of the number of polling cycles
this extension allows to link a reply to a Countdown object instead of specifying delay cycles
added unit test to verify the detection of missed replies both for periodic and action replies
adaption in helper script to optionally specify the cmake generator
adaptions required for unit tests in destructor of HealthHelper and FailureIsolationBase
HealthHelper:
remove object from health table when device handler is deleted which happens after each test case
FailureIsolationBase:
unsubscribe from event range when device handler is deleted
* for some devices it might be convenient to timeout replies by using the time instead of the number of polling cycles
* this extension allows to link a reply to a Countdown object instead of specifying delay cycles
* added unit test to verify the detection of missed replies both for periodic and action replies
* adaption in helper script to optionally specify the cmake generator
* adaptions required for unit tests in destructor of HealthHelper and FailureIsolationBase
* HealthHelper:
* remove object from health table when device handler is deleted which happens after each test case
* FailureIsolationBase:
* unsubscribe from event range when device handler is deleted
As I think it is faster than writing about it, I took the liberty to add my remaining comments directly as code.
@meierj if you agree with my changes, feel free to add a positive review and merge this PR.
As I think it is faster than writing about it, I took the liberty to add my remaining comments directly as code.
@meierj if you agree with my changes, feel free to add a positive review and merge this PR.
Also, I think we should remove the delay based solution completely some time in the future. The countdown based one is nicer and having both gives not exactly beautiful code.
Also, I think we should remove the delay based solution completely some time in the future. The countdown based one is nicer and having both gives not exactly beautiful code.
mohr
removed review request for gaisser 2022-07-13 22:01:23 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
@@ -431,1 +447,4 @@info.command = deviceCommandMap.end();info.countdown = countdown;if (info.periodic) {info.active = true;So far, convention is that periodic packets are disabled by default and need to be exlpicitely enabled. See
info.delayCycles = 0;above.@@ -962,6 +1002,10 @@ ReturnValue_t DeviceHandlerBase::enableReplyInReplyMap(DeviceCommandMap::iteratoinfo->delayCycles = info->maxDelayCycles;please add a comment, that both delay Cycles as well as the countdown are set if a countdown is preset, but the countdown will take precedence.
@@ -448,6 +448,9 @@ class DeviceHandlerBase : public DeviceHandlerIF,* by the device repeatedly without request) or not. Default is aperiodic (0).* Please note that periodic replies are disabled by default. You can enable them with* #updatePeriodicReplyupdatePeriodicReplyneeds to be adapted, too.Also, dude, you wrote a DHB unit test (add exploding head emoji, it seems gitea can not handle unicode..)
As I think it is faster than writing about it, I took the liberty to add my remaining comments directly as code.
@meierj if you agree with my changes, feel free to add a positive review and merge this PR.
Also, I think we should remove the delay based solution completely some time in the future. The countdown based one is nicer and having both gives not exactly beautiful code.
I am working on refactoring the command/reply API anyway, it has become bloated up a bit.