Serial.Println()

Using Arduino Programming Questions
1

Is there a way to merge different data in the parameter of Serial.Println() in a smart way?

I have two arrays:
char AltBuff [10];
float PenBuff[10];

That I'd like to send like this Serial.Println(AltBuff + "," + PenBuff);

But it doesnt work, I guess that it only accepts one parameter. (except the format-parameter...)

Some would say, use Serial.Print() for the first two and then Serial.Println for the last one. Our issue really is in the receiving end where a Raspberry is supposed to receive it.

But I think it would be good to have the data gathered in a comma separated string as it leaves the Arduino...

Thanks on beforehand.

2

You not only have two formats, you also have 10 items each aka an array. You can't print an array, you can only print array parts.

If you want to print all items after each other with a comma:

for(byte i = 0; i < 10; i++){
  Serial.print(AltBuff[i]);
  Serial.print(",");
}
for(byte i = 0; i < 10; i++){
  Serial.print(PenBuff[i]);
  if(i != 9){
    Serial.print(",");
  }
}
3

But then there'll be even more prints...

Yea I guess one could somehow type convert the data in the array with a loop like that into a new array that's for sending.

Serial.println(AltBuff); works fine by the way.

My bad, there's been so many questions that we haven't posted, and this first post obviously was sent in a hurry. the PenBuff isn't an array its just a normal float. We do have other variables as well that are planned to be added in here when we found a way.

Struggeling with Python and RPie in the other end where one 'read to end of line'-functions works well. Trying to adapt to our limitations in that end...

4

Yea I guess one could somehow type convert the data in the array with a loop like that into a new array that's for sending.

You could do that. It would be best to have a separate function for each set of data to be joined into one string before printing.

Of course, as soon as you do that, you'll see just how silly the idea is. The receiver has no way of knowing if you called Serial.print() 127 times to print 127 characters, or once to print a 127 character array. So, don't generate the array when you have the data individually.

5

Kalasson:
But then there'll be even more prints...

What's the problem with that?

6

PaulS:
You could do that. It would be best to have a separate function for each set of data to be joined into one string before printing.

Of course, as soon as you do that, you'll see just how silly the idea is. The receiver has no way of knowing if you called Serial.print() 127 times to print 127 characters, or once to print a 127 character array. So, don't generate the array when you have the data individually.

Right! Ok.

So we're going for a few Serial.print():s and then to end with an Serial.println(). That should do the trick.

We have to sort it out on the RPI-side then, just that it wasn't happy with any other function than the read-to-endmarker.

sterretje:
What's the problem with that?

If you say that its not a problem you're probably right.

Just found a piece of code that mimics C:s printf(), shall have a look at it.

7

Don't, it's wasteful for your resources :wink:

Receiving end has no way of knowing the difference between

Serial.println("Hello world!");
//and 
Serial.print("H");
Serial.print("e");
Serial.print("l");
Serial.print("l");
Serial.print("o");
Serial.print(" ");
Serial.print("w");
Serial.print("o");
Serial.print("r");
Serial.print("l");
Serial.print("d");
Serial.print("!");
Serial.println();

It sees the exact same thing, it receive the same 13 bytes of data.

8

septillion:
Don't, it's wasteful for your resources :wink:

Receiving end has no way of knowing the difference between

Serial.println("Hello world!");

//and
Serial.print("H");
Serial.print("e");
Serial.print("l");
Serial.print("l");
Serial.print("o");
Serial.print(" ");
Serial.print("w");
Serial.print("o");
Serial.print("r");
Serial.print("l");
Serial.print("d");
Serial.print("!");
Serial.println();



It sees the exact same thing, it receive the same 13 bytes of data.

I think that one of the issues we had was that the instrument data collected in AltBuff (Altimeter instrument) did include an "\n" itself, so when we were trying to read that together with other stuff the read ended after the AltBuff-data... We now put it last in the string and it seem to work!