fsfw/fsfw
fsfw/fsfw
11
3
Fork 6
Code Issues 32 Pull Requests 4 Releases 10 Wiki Activity

Thoughts on DHB PowerSwitchIF #20

New Issue
Closed
opened 2020-03-24 15:29:30 +01:00 by gaisser · 3 comments
gaisser commented 2020-03-24 15:29:30 +01:00
Owner
Copy Link
  • Think about making the PowerSwitchIF setting optional. Devices without switches will call it even though the have no switch. The example is another software on the SOURCE PLOC. In every other aspect it behaves like a physical device but has no switches.
  • Furthermore, DHB uses a static to initialize the powerSwitcher at the moment. This has some advantages in comfort but duplicates information as every device only uses the static information for initializing its internal pointer. So, theoretical you are able to set different PowerSwitchIFs for different DHBs but in reality the init value is always taken from the static objectId.
- Think about making the PowerSwitchIF setting optional. Devices without switches will call it even though the have no switch. The example is another software on the SOURCE PLOC. In every other aspect it behaves like a physical device but has no switches. - Furthermore, DHB uses a static to initialize the powerSwitcher at the moment. This has some advantages in comfort but duplicates information as every device only uses the static information for initializing its internal pointer. So, theoretical you are able to set different PowerSwitchIFs for different DHBs but in reality the init value is always taken from the static objectId.
gaisser added the
feature
 label 2020-03-24 15:29:30 +01:00
taheran commented 2020-03-26 11:21:24 +01:00
Member
Copy Link

This is quite useful for ESBO, we have devices that we do not control their power switch, and interfaces that behave as a device but have no switches.

This is quite useful for ESBO, we have devices that we do not control their power switch, and interfaces that behave as a device but have no switches.
mohr commented 2020-03-31 11:59:46 +02:00
Owner
Copy Link

Proposed Solution as of 31.03.20:

Proposed Solution as of 31.03.20: - in [initialize()](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.cpp#L614): Check if the static Id is [NO_OBJECT](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/objectmanager/frameworkObjects.h#L15). If so, do not initialze [powerSwitcher](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L225) - Change default implementation of [getSwitches()](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.cpp#L794) to return [NO_SWITCH](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L150) - Access to [powerSwitcher](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L225) is protected by a check of [commandSwitch](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L1006), so in default implementation it is not dereferenced - Remove the [setDeviceSwitch](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L74) constructor parameter from DHB, let the child implementation handle it - Make [powerSwitcher](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L225) private to dissuade users from dereferencing it - Make [commandSwitch](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L1006) protected - Keep [powerSwitcher](https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/master/devicehandlers/DeviceHandlerBase.h#L225) a member of DHB, no better solution found
gaisser commented 2020-09-07 14:03:04 +02:00
Author
Owner
Copy Link

This is part of #144

This is part of #144
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
API Change
Changes the API, so Users need to adapted
Breaking API Change
Changes the API in a non backwards compatible way
bug
Something is not working
build
Issues related to the buildsystem, including CI
cosmetics
Small change most users won't notice
Documentation
Improvement of code documentation
duplicate
This issue or pull request already exists
feature
New feature
help wanted
Need some help
hotfix
Quick or important fix that is merged directly into master, causing a new revision
invalid
#worksforme
question
More information is needed
Refactor
Contains a refactoring of some code
Tests
Issues related to testing code
wontfix
This won't be fixed
No Label
feature
Milestone
No items
No Milestone
Assignees
Clear assignees
ahinkel dwoodward gaisser hanke jenkins_buildfix lrajer meierj mohr muellerr taheran tbaumgartl
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fsfw/fsfw#20
No description provided.
Delete Branch "%!s()"

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?