DLE Encoder #466
There are other DLE implementations out there which do not escape STX and ETX occurences.
I think it would be nice if this implementation is added as well.
Possible function name:
Furthermore, it might be a good idea to make carriage return escaping optional, because that escaping seems to be a custom solution as well
I do not see how not escaping STX and ETX can work the way we are using the DLE encoder (for framing).
Escaping CR indeed seems to be rather useless and something inherited from FLP's PLOC which was the first instance using this specific DLE encoder.
I just looked into https://github.com/Lx/python-dlestxetx from #460, they do not escape STX and ETC whithin the frame but do escape the frame delimiting STX and ETX, which does work for framing purposes and probably saves some encoded space, as only one character (DLE) needs to be escaped.
Still, I am not sure if the proposed changes are worth the effort, as we need to provide backwards compatibility (with devices we can not change) and the encoder is mainly used "within" fsfw code, where we control both sides.
I like the idea of a simple interface and guaranteed compability over many configurations and incompatible bytestreams.
Implementing support for both was not too difficult. I'm preparing a PR, and I am also adding unit tests for both modes
Sorry, did not realize that you already started a PR. I am still a bit critical about the non STX/ETX escaped mode, which feels wrong to me. But I agree that having a flexible implementation to support many usecases outweighs my concern.
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?