DHB refactor TM handler #669
- TM handler of DHB is a bit more flexible and can now handle raw buffers in addition to a packet implementing
DeviceTmReportingWrapperto be able to use the new
DeviceTmReportingWrapperdeserialize 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
I am not sure if I completely grasp the scope of this PR but following some thoughts:
SerializeIFis our generic interface for passing data. Buffer/Size combinations are a subset of it via
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 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.
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
No due date set.
No dependencies set.
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?