How does Arduino differentiate between data types on the Serial Buffer?

Hi,

I'm trying to send data between two microcontrollers: LPC1768 (ARM-Cortex M3, 32 bit) and the Arduino Uno (ATMega328P-Pu, 8 bit) using their serial ports.

The trouble is, the serial library for the LPC1768 is somewhat limited in what it can do (here's its API). In particular, I'm using printf() to send a float to the Arduino but I need to know what's sent. In the process of verifying what is sent, I need to know how the Arduino differentiates floats and bytes stored in the Serial buffer.

I need to know how the Arduino differentiates floats and bytes stored in the Serial buffer.

It doesn't. It receives a series of bytes, that's all.

What do you see if you implement a simple print of what is received ?

By using printf the arriving data is highly likely to be text (arrays of characters).

To verify what was sent just echo what was sent to Serial Monitor. (You do have an Arduino with more than one serial port, right?)

Have you level-shifted?

Maybe you can use an 'edi' approach, i.e. every data type (either conceptual or literal) is tagged with a simple indicator; e.g. floats are tagged with a byte 'F', ints with a byte 'I' etc. The sender knows what type it is sending so it can always send those tag values and the receiver uses those tag values to determine how to decode the incoming bytes.

Tag values can indicate a conceptual type; e.g. a temperature value can be tagged with an 'T' instead of an 'F" (see above); it's up to you ...

kind regards,

Jos

UKHeliBob: It doesn't. It receives a series of bytes, that's all.

What do you see if you implement a simple print of what is received ?

Hi,

The last I checked, issuing a statement such as: lpcSerial.printf("%.3f", 3.145) from the LPC1768 will send the ASCII encoding of "3.145" through its serial port. That is, the arduino will receive 5 bytes whose decimal representation is 51 46 49 52 53 (someone helped me figure it out here). If I remember correctly, I created an array of characters and stored the result of serial.read() to an element of that array. I then Serial.print() each element which returned the printed decimal representation of each byte, each of which corresponded to the ASCII representation of the float I sent using printf().

As a separate matter, my question was prompted by there being two functions - parseFloat() and parseInt() - provided by the Serial library. If the arduino doesn't differentiate between floats and ints, then how do these functions work?

If the arduino doesn't differentiate between floats and ints, then how do these functions work?

If the data stream contains a decimal point, and you have called parseInt(), the decimal point will cause the function to stop reading, and you'll get an int (well, actually a long).

If you call parseFloat(), any non-digit except the decimal point will cause the function to stop reading and convert the string read to a float.

The Arduino can not tell what the stream contains. You have to know, or deal with any possible data coming in.

JosAH:
Maybe you can use an ‘edi’ approach, i.e. every data type (either conceptual or literal) is tagged with a simple indicator; e.g. floats are tagged with a byte ‘F’, ints with a byte ‘I’ etc. The sender knows what type it is sending so it can always send those tag values and the receiver uses those tag values to determine how to decode the incoming bytes.

Tag values can indicate a conceptual type; e.g. a temperature value can be tagged with an ‘T’ instead of an 'F" (see above); it’s up to you …

kind regards,

Jos

Does serial communication via RX/TX always involves strictly sending bytes and, furthermore, how those bytes are interpreted depends on what the programmer wants to send?

That is, does the RX/TX channel strictly allow the programmer to send only sequences of byte-packets, which could potentially represent different data types, and it is up to the programmer to write code to interpret those byte sequences?

Does serial communication via RX/TX always involves strictly sending bytes

Yes.

and, furthermore, how those bytes are interpreted depends on what the programmer wants to send?

How those bytes should be interpreted depends on what the programmer sent. Clearly, there is often a big difference between should be and is.

That is, does the RX/TX channel strictly allow the programmer to send only sequences of byte-packets, which could potentially represent different data types, and it is up to the programmer to write code to interpret those byte sequences?

Yes.

Thanks, I'll play around some more with parseInt(), parseFloat() to get a better understanding.