DLE Encoder #466

New Issue

muellerr · 2021-08-17T14:36:03+02:00

muellerr commented

2021-08-17 14:36:03 +02:00

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: encode_no_escape and decode_no_escape.

Furthermore, it might be a good idea to make carriage return escaping optional, because that escaping seems to be a custom solution as well

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: `encode_no_escape` and `decode_no_escape`. Furthermore, it might be a good idea to make carriage return escaping optional, because that escaping seems to be a custom solution as well

muellerr added the

help wanted

label 2021-08-17 14:37:15 +02:00

muellerr referenced a pull request that will close this issue

2021-08-17 16:05:37 +02:00

DLE Encoder Improvements #467

mohr commented

2021-08-30 13:00:45 +02:00

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 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.

mohr commented

2021-08-30 13:09:06 +02:00

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.

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.

muellerr commented

2021-09-02 09:34:24 +02:00

Implementing support for both was not too difficult. I'm preparing a PR, and I am also adding unit tests for both modes

mohr commented

2021-09-02 14:21:50 +02:00

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.

muellerr closed this issue

2021-09-13 15:25:02 +02:00

Sign in to join this conversation.