The code usage was successful on ESP8266 core platform too, as message originator and sender.
Problems took place on receiption side, relaized on ESP32, but not due to introduced library itself.
Most convenient and short interpretation of receiption job for me was the following code for message sending via UART:
for(uint i = 0; i < sizeof(encoded); i++) { mySerial.print(encoded[i]); } mySerial.print('\n');
and beneath for the receiption:
if (Serial1.available()) encoded = Serial1.readStringUntil('\n');
Byte by byte reading on receiption side was not successful and data integrity has been suffered with unknown reason. In meantime the "readStringUntil" function performed well enough.
Having sent for example, 10 byte (5 as original message content and 5 additional, which generates the encoder library) and termination EOL, I got 12 bytes on the rest. One byte is the NULL, which has every string by definition. On receiving side we are not able to use the string as decoding function argument, due to variable type itself and two additional bytes presence: NULL and EOL.
Neither of Ardunio or C++ string to char array function were able to convert the string to char array.
Even encoded bytes were not possiple to copy and transfer to somewhere by computer's clipboard from serial monitor terminal. An simple task, namely, the string to char convertation became as a BIG trouble.
The solution found accidentally, upon some days long hardwork.
if (Serial1.available()) encodedleft = Serial1.readStringUntil('\n'); for (uint i = 0; i < 10; i++) { rawleft[i] = encodedleft[i]; }
The "rawleft" has been declared globally, as char array and the "encodedleft"-as a string variable accordingly. It is was an eyeopening subject for me that the string can be accessed char by char, by index. So, this method has solved the task, having copied the string to char array, bypassed last two bytes transfer to char array.
Thanks to author for good job.
A question however I have to bring up. What is the optimal relation between original message lenght and additional bytes lenght?
The code usage was successful on ESP8266 core platform too, as message originator and sender. Problems took place on receiption side, relaized on ESP32, but not due to introduced library itself. Most convenient and short interpretation of receiption job for me was the following code for message sending via UART:
for(uint i = 0; i < sizeof(encoded); i++) { mySerial.print(encoded[i]); } mySerial.print('\n');and beneath for the receiption:if (Serial1.available()) encoded = Serial1.readStringUntil('\n');Byte by byte reading on receiption side was not successful and data integrity has been suffered with unknown reason. In meantime the "readStringUntil" function performed well enough. Having sent for example, 10 byte (5 as original message content and 5 additional, which generates the encoder library) and termination EOL, I got 12 bytes on the rest. One byte is the NULL, which has every string by definition. On receiving side we are not able to use the string as decoding function argument, due to variable type itself and two additional bytes presence: NULL and EOL. Neither of Ardunio or C++ string to char array function were able to convert the string to char array._1. Arduino: myString.toCharArray(buf, len)
Even encoded bytes were not possiple to copy and transfer to somewhere by computer's clipboard from serial monitor terminal. An simple task, namely, the string to char convertation became as a BIG trouble. The solution found accidentally, upon some days long hardwork.
if (Serial1.available()) encodedleft = Serial1.readStringUntil('\n'); for (uint i = 0; i < 10; i++) { rawleft[i] = encodedleft[i]; }The "rawleft" has been declared globally, as char array and the "encodedleft"-as a string variable accordingly. It is was an eyeopening subject for me that the string can be accessed char by char, by index. So, this method has solved the task, having copied the string to char array, bypassed last two bytes transfer to char array. Thanks to author for good job. A question however I have to bring up. What is the optimal relation between original message lenght and additional bytes lenght?