Constantly changing value thru Serial

Hi.

I have a problem with a variable..

Let's say in the code I have a variable x+y=z.. And I have another variable which uses that "z" to calculate servo speed..

Is it possible to send those "x" and "y" thru Serial monitor so that the "x" and "y" values are sent with in one line and can be any float number I like?

Sorry if I am reposting this question again.

Sure, it's possible.

Good to know. But how I have to define the x and y?

Check out this thread:

http://forum.arduino.cc/index.php?topic=288234.0

It has more than you ever wanted to know about how to send values to Arduino over serial. You'll have to either send the numbers as raw bytes or as ascii characters and put them back together into floats or ints or whatever you need on the receiver side.

The floats will arrive at the Arduino one character at a time so a float such as 123.45 will consist of 7 separate characters 1 2 3 4 . 5 6 You can only read once character at a time so you read until you know that the float is complete*** and put each character into an array of chars terminated with a zero. At that time you have a C style string and can use the atof() function to convert it into a float.

**How do you know that the float is complete ? The easiest way is to send a special character after the float, perhaps a carriage return or linefeed to signal that the float is complete. In practice you should send a special character before the float so that the sending and receiving systems remain in step.

Have a look at Serial input basics for examples of how to do this.

The floats will arrive at the Arduino one character at a time so a float such as 123.45 will consist of 7 separate characters

Really?

Well, nearly.

As you will gather I changed the example between 123.45 in the text and 1234.56 in the example of the characters arriving but I have, of course, resisted the temptation to correct my original post.

Funny, I have just been responding on a thread that asked how to break up data into bytes that can be sent over a serial interface:

This can of course be applied to any datatype, including floats. You know when the entire float has arrived because you know how many bytes constitutes a float. Sending plain ascii might be more intuitive to beginners, but it requires pre- and post-processing on either side of the line. This overhead might not be acceptible. Also, sending as raw data requires a constant number of bytes independent of the precision…

For example:

float value = 3.14159;
Serial.write(reinterpret_cast<byte*>(&value), sizeof(value)); // or sizeof(float)

Sending plain ascii might be more intuitive to beginners, but it requires pre- and post-processing on either side of the line. This overhead might not be acceptible. Also, sending as raw data requires a constant number of bytes independent of the precision...

On the other hand, binary data provide no way of dealing with serial data loss, or even of knowing that loss has occurred.

This can of course be applied to any datatype, including floats. You know when the entire float has arrived because you know how many bytes constitutes a float.

The tradeoff is that you have to KNOW the order of the data being sent, and the sender must always send the data in the same order.

If you are sending temperature and humidity data, for instance, and the humidity hasn't changed, it is not necessary to send it again. But, somehow, the receiver needs to know that you are not going to send a new value. Hard to communicate that in a binary stream.

PaulS: If you are sending temperature and humidity data, for instance, and the humidity hasn't changed, it is not necessary to send it again.

Personally, I like the simplicity of sending the same data even if it has not changed. It seems simpler to me than the overhead needed to identify the data when you only send part of it.

I don't understand your point about "binary data provide no way of dealing with serial data loss". Why would binary data be any different from ascii data? In both cases you can have start and end markers and in both cases it would be a good idea to add an integrity check byte.

...R

In both cases you can have start and end markers

How can you have a start marker that is not the same as some legal value? Or an end marker?

I agree with Robin2 that most times it's more transparent and consistent to just send data in a fixed format if possible. However, PaulS does have a point when it comes to start- and end-markers.

Luckily, it's often the case that you know what kind of data to expect. If the receiver knows that the data in the buffer represents floats, it can simply collect bunches of 4 bytes and interpret them correctly. When dealing with larger amounts, say arrays of floats, the first few bytes could represent an integer that tells you how many bytes will follow. The receiver can then allocate resources and wait for this amount to arrive (with some time-out built-in).

I really think ASCII representation should be used for what it was meant to be used: text. Do you really want to waste precious cycles converting floats to text and vice versa, and pay the bandwith-overhead on top of that?

So what happens if you miss one byte for some reason, a problem on the line or something, and then carry on blindly accepting that each set of four bytes go together to make a float. For the rest of the program you'll be blindly combining three bytes from one transmission with the first byte of the next transmission.

So what happens if you miss one byte for some reason

You would hit the timeout because you wouldn’t get a multiple of 4 anymore :wink:

Now you’ll ask: “What if you missed 4 bytes?”
To which I’ll answer: “Then you’re f****d.” :smiley:

This was assuming you know the number of bytes in advance. If not, and it is a continous stream, it’s more complicated…

It’s all a matter of circumstances and requirements of course, so it’s impossible to make general statements. If a byte goes missing for some reason, you’ll at least know it and hit the timeout. Maybe the implementation allows requesting the data again, in which case you’ll get a second chance. Maybe not. You could insert a signature byte in between every bunch of 4 (e.g. 0xff), which would allow you to make an educated guess as to what went wrong if something strange is happening.

Many many options, and I still think converting to text is not the best :wink:

That all presupposes that you know the timing of the bytes being sent. What if 3 floats are being sent back to back, when you hit the timeout how do you know which one was the failure? It also presupposes that you know the endianess of the sender, which isn't necessarily always the case.

jorenheit: Many many options, and I still think converting to text is not the best ;-)

I think the point is that which is best depends on the particular application in question. You can't really say that one or the other is always best in every case.

PaulS: How can you have a start marker that is not the same as some legal value? Or an end marker?

See the Python demo here. It does require a bit of manipulation but that is transparent in use.

It converts a data byte of 253 or higher into a pair of bytes preceded by 253 and uses 254 and 255 as the markers.

...R