Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HammingStream not working #7

Open
5tefanP opened this issue Nov 25, 2020 · 10 comments
Open

HammingStream not working #7

5tefanP opened this issue Nov 25, 2020 · 10 comments
Labels
bug Something isn't working

Comments

@5tefanP
Copy link

5tefanP commented Nov 25, 2020

Hi,

does the ArduinoStreamUtils-lib work with the ARM® Cortex®-M4 XMC4700 ?

Thank you

King regards

Stefan

@bblanchon
Copy link
Owner

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

@bblanchon bblanchon added the question Further information is requested label Nov 25, 2020
@5tefanP
Copy link
Author

5tefanP commented 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
Copy link
Owner

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, 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?

Best regards,
Benoit

@5tefanP
Copy link
Author

5tefanP commented 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
Copy link
Owner

Hi Stefan,

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.

Best regards,
Benoit

@bblanchon bblanchon added bug Something isn't working and removed question Further information is requested labels Nov 26, 2020
@bblanchon bblanchon changed the title ARM core? HammingStream not working Nov 26, 2020
@bblanchon
Copy link
Owner

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.

@5tefanP
Copy link
Author

5tefanP commented Dec 1, 2020

Hi Benoit,

excuse the delay.

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.

Flushing does not help.

Best Regards

Stefan

@bblanchon
Copy link
Owner

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
Copy link
Author

5tefanP commented 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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants