You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you very much for reporting this issue.
This is a new feature, so it's likely to have bugs, but I doubletriple-checked today, and it works fine as far as I can tell.
Of course, the encoded data looks like random characters; for example, DEFGHIJKL becomes TTT%T6TGT8TITZT+Tl.
However, if you use HammingStream on both sides, which seems to be the case, the encoding/decoding should be transparent.
Also, make sure you don't send any non-encoded byte (for instance, an accidental Serial1.println()) because it could insert an odd number of bytes and ruin the decoding of the following bytes.
In other words, only use eccSerial; don't use Serial1 directly.
I don't own this board, so I cannot verify, but I don't think this is related to the core, especially if it works fine without HammingStream.
Can you try to reproduce the issue with a minimal setup, as in the example?
i tried your example separtely, just with Serial1. I also did the same code but with print() instead of write(), like in the README.md. So i encode with one controller and decode with another. Both times the decoded message is not the same as the original before encoding.
Starting from the example, can you check that DEFGHIJKL is transmitted as TTT%T6TGT8TITZT+Tl, and vice-versa.
This would help me understand if the problem is on the encoding or decoding side.
Could there be some initial (garbage?) data in the serial buffer when the microcontroller boot?
If so, please try to add a flushing loop: while(Serial1.available()) Serial1.read() before using the HammingStream.
I don't understand your last question, but when I say "decorates", I'm referring to the Decorator pattern.
I tested with other hardware and it still works as expected.
However, I did get garbage when the decoder got out of sync after receiving an odd number of bytes.
This problem was solved by the flushing loop I mentioned in my previous message.
To make things clear, I added a new example to show how to use HammingStream with HardwareSerial.
I tested the new example.
With eccSerial.print DEFGHIJKL in the loop, i receive TTT%T6TGT8TITZT+Tl, not decoded, on the other controller.
If i send DEFGHIJKL normal and encoded via .print() and read it with ecc.Serial1.read(), i get ���↑ ����������� � ( "?" should be squares) followed by a new line.
Thank you for taking the time to run this experiment.
With the example, you don't have to call print() explicitly; you just need to send the clear text via the Serial Monitor.
If you run the program on both boards, the receiver should print back the clear text to the Serial Monitor.
It seems that the encoding is working fine, and I cannot see any reason why the decoding would fail.
If only I had the hardware with me...
Do you think to can reproduce the issue with cheaper boards?
Activity
bblanchon commentedon Nov 25, 2020
Hi Stefan,
Is this the core in question?
https://github.com/Infineon/XMC-for-Arduino
It compiles without any error so it should work fine.
Please confirm so I can add it to the list.
Best regards,
Benoit
5tefanP commentedon Nov 25, 2020
Hi Benoit,
Thank you for the quick response.
Yes it is.
It compiles fine, but does not work like expected. I didn't know if the compatibility could be the issue.
I want to use the hammingStream on the Serial1 between two of the same boards.
The Serial1 works without the hammingStream but is quite noisy.
With the hemming. I receive random characters in the buffer. The rest works.
For the stream
-HammingStream<7, 4> eccSerial(Serial1);
-Serial1.begin(115200); also tested (9600, SERIAL_7N1)
-"eccSerial.println(int)"
-"eccSerial.readBytesUntil('\n',buffer, size)" to receive
Is it even possible that this is caused by the core?
Right now i use it in a bigger project. Otherwise i would have provided the full code.
I hope this helps though.
Thank you
Best regards
Stefan
bblanchon commentedon Nov 26, 2020
Hi Stefan,
Thank you very much for reporting this issue.
This is a new feature, so it's likely to have bugs, but I
doubletriple-checked today, and it works fine as far as I can tell.Of course, the encoded data looks like random characters; for example,
DEFGHIJKLbecomesTTT%T6TGT8TITZT+Tl.However, if you use
HammingStreamon both sides, which seems to be the case, the encoding/decoding should be transparent.Also, make sure you don't send any non-encoded byte (for instance, an accidental
Serial1.println()) because it could insert an odd number of bytes and ruin the decoding of the following bytes.In other words, only use
eccSerial; don't useSerial1directly.I don't own this board, so I cannot verify, but I don't think this is related to the core, especially if it works fine without
HammingStream.Can you try to reproduce the issue with a minimal setup, as in the example?
Best regards,
Benoit
5tefanP commentedon Nov 26, 2020
Hi Benoit,
Thank you for helping.
i tried your example separtely, just with Serial1. I also did the same code but with print() instead of write(), like in the README.md. So i encode with one controller and decode with another. Both times the decoded message is not the same as the original before encoding.
I had no Serial1.prints.
Thank you.
Best regards,
Stefan
bblanchon commentedon Nov 26, 2020
Hi Stefan,
Starting from the example, can you check that
DEFGHIJKLis transmitted asTTT%T6TGT8TITZT+Tl, and vice-versa.This would help me understand if the problem is on the encoding or decoding side.
Could there be some initial (garbage?) data in the serial buffer when the microcontroller boot?
If so, please try to add a flushing loop:
while(Serial1.available()) Serial1.read()before using theHammingStream.I don't understand your last question, but when I say "decorates", I'm referring to the Decorator pattern.
Best regards,
Benoit
[-]ARM core?[/-][+]HammingStream not working[/+]bblanchon commentedon Nov 28, 2020
I tested with other hardware and it still works as expected.
However, I did get garbage when the decoder got out of sync after receiving an odd number of bytes.
This problem was solved by the flushing loop I mentioned in my previous message.
To make things clear, I added a new example to show how to use
HammingStreamwithHardwareSerial.5tefanP commentedon Dec 1, 2020
Hi Benoit,
excuse the delay.
I tested the new example.
With eccSerial.print
DEFGHIJKLin the loop, i receiveTTT%T6TGT8TITZT+Tl, not decoded, on the other controller.If i send
DEFGHIJKLnormal and encoded via .print() and read it with ecc.Serial1.read(), i get���↑ ����������� �( "?" should be squares) followed by a new line.Flushing does not help.
Best Regards
Stefan
bblanchon commentedon Dec 1, 2020
Hi Stefan,
Thank you for taking the time to run this experiment.
With the example, you don't have to call
print()explicitly; you just need to send the clear text via the Serial Monitor.If you run the program on both boards, the receiver should print back the clear text to the Serial Monitor.
It seems that the encoding is working fine, and I cannot see any reason why the decoding would fail.
If only I had the hardware with me...
Do you think to can reproduce the issue with cheaper boards?
Best regards,
Benoit
5tefanP commentedon Dec 8, 2020
Hi Benoit,
the cheaper board have no hardware serial that can be used in parallel. I could try it with software serial, but i dont have any experience with it.
Maybe i can manage to send you a board.
If you want to, you could use it to verify the library for the XMC in the fullest.
Best regards
Stefan
bblanchon commentedon Feb 5, 2021
Hi @5tefanP,
I purchased an XMC4700 Relax Kit.
I'll get back to you as soon as I find the time to run the experiment.
Best regards,
Benoit