DHB refactor TM handler #669

Closed
muellerr wants to merge 10 commits from mueller/dhb-handle-device-tm into development
Owner
  • TM handler of DHB is a bit more flexible and can now handle raw buffers in addition to a packet implementing SerializeIF
  • Refactor DeviceTmReportingWrapper to be able to use the new util::DataWrapper tagged union
  • DeviceTmReportingWrapper deserialize is never used and is kind of tricky to implement now because one would have to pass the length of the expected data. I think the easier solution for now is to just forbid deserialization
  • I tested this change on the EIVE fork. We have the case that we forward some TM to in raw format directly
- TM handler of DHB is a bit more flexible and can now handle raw buffers in addition to a packet implementing `SerializeIF` - Refactor `DeviceTmReportingWrapper` to be able to use the new `util::DataWrapper` tagged union - `DeviceTmReportingWrapper` deserialize is never used and is kind of tricky to implement now because one would have to pass the length of the expected data. I think the easier solution for now is to just forbid deserialization - I tested this change on the EIVE fork. We have the case that we forward some TM to in raw format directly
muellerr added 3 commits 2022-08-30 13:40:51 +02:00
fsfw/fsfw/pipeline/head Build started... Details
fsfw/fsfw/pipeline/pr-development This commit looks good Details
20d42add03
add new data wrapper helper type
fsfw/fsfw/pipeline/pr-development This commit looks good Details
0f27c7e7e7
extend data wrapper
fsfw/fsfw/pipeline/head Build started... Details
fsfw/fsfw/pipeline/pr-development This commit looks good Details
3a47062f2a
refactored dhb TM handler
gaisser was assigned by muellerr 2022-08-30 13:40:58 +02:00
muellerr added this to the v6.0.0 milestone 2022-08-30 13:41:00 +02:00
gaisser was unassigned by muellerr 2022-08-30 13:41:05 +02:00
muellerr added the
feature
label 2022-08-30 13:41:10 +02:00
muellerr added a new dependency 2022-08-30 13:41:16 +02:00
muellerr requested review from gaisser 2022-08-30 13:44:01 +02:00
muellerr requested review from mohr 2022-08-30 13:44:07 +02:00
muellerr added 4 commits 2022-08-30 14:03:45 +02:00
fsfw/fsfw/pipeline/pr-development This commit looks good Details
c756297e5c
data wrapper update
fsfw/fsfw/pipeline/pr-development This commit looks good Details
bdd79d060d
basic data wrapper unittests
fsfw/fsfw/pipeline/pr-development This commit looks good Details
192255df1c
additional test
muellerr added 1 commit 2022-08-30 14:40:01 +02:00
fsfw/fsfw/pipeline/pr-development This commit looks good Details
6b8c83be29
update changelog
muellerr added 2 commits 2022-08-30 14:42:12 +02:00
fsfw/fsfw/pipeline/pr-development This commit looks good Details
d675a789a2
update changelog
muellerr added the
Breaking API Change
label 2022-08-30 14:43:43 +02:00
muellerr added 2 commits 2022-08-30 16:03:12 +02:00
fsfw/fsfw/pipeline/pr-development This commit looks good Details
8d1777fa0c
additional tests
muellerr added 1 commit 2022-08-30 16:04:20 +02:00
fsfw/fsfw/pipeline/pr-development Build queued... Details
fsfw/fsfw/pipeline/head This commit looks good Details
5ff28ff562
remove newline
Owner

I am not sure if I completely grasp the scope of this PR but following some thoughts:

  • SerializeIF is our generic interface for passing data. Buffer/Size combinations are a subset of it via SerialBufferAdapter.

  • For sending raw, uninterpreted data to ground within a DHB class, one can use DeviceHandlerBase::replyRawReplyIfnotWiretapped(), which has the benefit of sending it via special PUS Subservice, which lets the MCS detect that it is raw data. replyRawReplyIfnotWiretapped() is to be preferred over replyRawData() as it checks if wiretapping is active to avoid duplicate packets.

I am not sure if I completely grasp the scope of this PR but following some thoughts: - `SerializeIF` *is* our generic interface for passing data. Buffer/Size combinations are a subset of it via `SerialBufferAdapter`. - For sending raw, uninterpreted data to ground within a DHB class, one can use `DeviceHandlerBase::replyRawReplyIfnotWiretapped()`, which has the benefit of sending it via special PUS Subservice, which lets the MCS detect that it is raw data. `replyRawReplyIfnotWiretapped()` is to be preferred over `replyRawData()` as it checks if wiretapping is active to avoid duplicate packets.
Author
Owner

I needed this after processing a data reply coming from a service 8 request. This was the most intuitive solution for me after having seen how handleDeviceTm was used at other places inside the EIVE code. It was used to package data replies for service 8 request. The only addition I really needed was to be able to supply raw buffers, so I would not have to create a dummy class just to wrap the raw pointer.

I needed this after processing a data reply coming from a service 8 request. This was the most intuitive solution for me after having seen how `handleDeviceTm` was used at other places inside the EIVE code. It was used to package data replies for service 8 request. The only addition I really needed was to be able to supply raw buffers, so I would not have to create a dummy class just to wrap the raw pointer.
Author
Owner

One other way: Supply a second variant of handleDeviceTm which takes a raw pointer and a size and converts them to SerializeIF using the SerialBufferAdapter. See #671

One other way: Supply a second variant of `handleDeviceTm` which takes a raw pointer and a size and converts them to SerializeIF using the `SerialBufferAdapter`. See https://egit.irs.uni-stuttgart.de/fsfw/fsfw/pulls/671
Owner

Superseded by #671

Superseded by #671
mohr removed a dependency 2022-09-01 14:14:16 +02:00
mohr closed this pull request 2022-09-01 14:14:26 +02:00
mohr removed this from the v6.0.0 milestone 2023-02-09 16:07:33 +01:00
Some checks are pending
fsfw/fsfw/pipeline/pr-development Build queued...
fsfw/fsfw/pipeline/head This commit looks good

Pull request closed

Sign in to join this conversation.
No description provided.