Arduino base64 and print/write to serial, doubts

Projects Programming
1

Hello all,

I would like to send data which will have to be encoded on base64 format from my arduino, I have looked into arduino libs and I see that there is an availble one in the repostitory, so I will make use of it. However, I was wondering what would happen if I use functions like Serial.print() or Serial.println() to write my base64 encoded data into the serial bus, I am afraid that it will be "mapped" to ASCII what I don't want since then the receiver won't be able to understand.

What kind of function could I use to write into serial my raw data? Is Serial.write() the best candidate to do so?

Thanks in adnvace,

REgards

2

However, I was wondering what would happen if I use functions like Serial.print() or Serial.println() to write my base64 encoded data into the serial bus

Why would you use print() or println()? Use write() as was intended for byte arrays.

3

PaulS:
Why would you use print() or println()? Use write() as was intended for byte arrays.

That was precisely my doubt, I am not sure which one I should use, depending on what I have to send I do use one or another; I use mainly print with strings becuase I usually work with them, so in this case I should break down the string and convert each character and write it to the serial, right?

String message = "hi";
unsigned char base64[9];

unsigned int base64_length = 0;

 for (int i = 0; i < messageLength; i++)
 {
   encode_base64(message.charAt(i), 1, base64);
   Serial1.write(base64);

 }
4

so in this case I should break down the string and convert each character and write it to the serial, right?

No, but that's OK, because that is not what that code is doing. It is writing the whole array.

5

isn't base64 ascii?

6

ndarkness:
I am afraid that it will be "mapped" to ASCII what I don't want since then the receiver won't be able to understand.

Base64 is, I seem to remember, was deliberately designed to use only nice ASCII characters, so it should not be a problem. Encode one end, send via ASCII channel, decode the other end.

At least, that was my understanding.

7

doughboy:
isn't base64 ascii?

Yes, it is. But you need to add a terminating nul if you want to send it as a character array using the print family.

8

sterretje:
Yes, it is. But you need to add a terminating nul if you want to send it as a character array using the print family.

I don't see why a base64 encoder library will not add a null terminator.

The issue is op thought the result is still in binary.

9

PaulS:
No, but that's OK, because that is not what that code is doing. It is writing the whole array.

I don't get what you say, my code is getting each character of the string, coding in base64 and sending it to ther serial isn't?

10

Your code is potentially sending more than you think.
Have a careful read of the Serial.write documentation on the reference

11

AWOL:
Your code is potentially sending more than you think.
Have a careful read of the Serial.write documentation on the reference

Thanks AWOL, so you suggest me to check the size of what Serial.write() is actually writting?

12

You could check, or you could simply tell the compiler how much you want to write.

13

AWOL:
You could check, or you could simply tell the compiler how much you want to write.

I understand, something like this then

String message = "hi";
unsigned char base64[9];

unsigned int base64_length = 0;

for (int i = 0; i < messageLength; i++)
{
  base64_length = encode_base64(message.charAt(i), 1, base64);
  Serial1.write(base64,base64_length);

}
14

ndarkness:
I don't get what you say, my code is getting each character of the string, coding in base64 and sending it to ther serial isn't?

If it is, it shouldn't.

Base 64 does not convert one character to another character. It converts what is considered some binary memory or a binary file or a binary photo (like JPG) into a series of nice ASCII characters. As a far as I can remember every 3 ('binary') bytes results in 4 ASCII characters.

15

As a far as I can remember every 3 ('binary') bytes results in 4 ASCII characters.

"safe, printable, ascii characters"!
The point is that a transmission channel is likely to have characters that it doesn't like. Flow control. Line endings. Nulls. So if you try to transmit some arbitrary binary content (like a .JPG), some of the bytes are likely to get dropped or mangled. You could send them as HEX, of course, but that would at least DOUBLE the transmission time. So a number of schemes were developed to convert big streams of binary data into safe-for-transmission characters.
0-9A-Za-z is pretty safe, and that's 62 possible values - if we can agree on two more (usually '+' and '/') then we'll have 6 bits worth and can send 6 bits of binary data in 7 bits of ascii, which is much better than sending 8 bits in 14bits (for hex.) Wikipedia has a fine article on the subject.
(in modern times, communications channels have so much bandwidth that it's not as big a deal as it was back in the days of 300bps dialup modems.)