I am working on initial steps to send a CSV via file, which contains 6300 floating numbers. Each number is the result of 57344sin(0); 57344sin(0.001);57344*sin(0.002), and so on
I read before and used the post "Serial Input Basics", but with more less characters and it worked perfect.
With this project, I been thinking on converting each individual value to HEX and put everything on a single string. Is that even possible?
I understand UART has a buffer of 64 bytes. If increase the baud rate to 115000, will the transmission rate improve?
My original sketch has a For loop that calculates the sin values and feeds the arduino with the result. I read somewhere on this forum that calculating over and over every single sin function variable consumes processor time and for this reason I want to compare what solution is faster.
I don't have an sketch to show right, but I will be continue researching more.
Thanks in advance
Regardless of what you are sending over Serial, it all goes out as a byte steam. Increasing the bit rate to 115200 will of course transmit faster than lesser speeds. How you transmit the value is a separate issue and depends not so much on what you want to do, but how the receiver is set to interpret your data stream. A float is four bytes. Converting a number such as 16.38398908 to ASCII characters will consume 11 bytes (BTW you won't get a float with that many digits) and will (obviously) take longer to transmit. So, you need to determine first, how must you transmit, not by your wants, but by those of the receiver.
Converting a number such as 16.38398908 to ASCII characters<== Can this number be converted to HEX and if so, how many bytes as a result will I get?
I can of course, lower the number of decimals to a lesser number of them;however, I want for the moment to keep them intact.
Can this number be converted to HEX and if so, how many bytes as a result will I get?
It depends on what you mean by "this number".
The binary (floating point) representation that approximates that number is contained in four bytes, and those four bytes could be converted into eight bytes in the hexadecimal representation.
Note: on Arduino, floating point numbers are accurate only to 6-7 decimal digits, so it is pointless to print out more digits. You are currently printing out 10, so the last 3-4 of those are random nonsense.
All numbers are stored as binary. How you display them, (decimal, hex, octal) is independent of the storage. If you convert the number to a char array, that's different. As a float, there is a 32-bit ISO format that reserves 1 bit for the sign, 8 bits for the exponent and 23 bits for the significand (mantissa, or the bit to the right of the decimal). The value to the left of the decimal is zero. This will transmit as 4 8-bit bytes regardless of how you choose to display the data, you can't make it shorter without loss of precision.
DKWatson:
...(BTW you won't get a float with that many digits) and will (obviously) take longer to transmit. So, you need to determine first, how must you transmit, not by your wants, but by those of the receiver.
Actually, as this program shows, you can send as many digits as you wish:
void setup() {
// put your setup code here, to run once:
float num = 1.0/3.0;
Serial.begin(115200);
Serial.println(num, 16);
}
void loop() {
}
The program displays 16 digits. The problem is that the precision of a float is such that only the first 6 or 7 digits mean anything. The remaining digits are simply the computer's best guess. The code above displays: 0.3333333492279052
hbtousa:
I am working on initial steps to send a CSV via file, which contains 6300 floating numbers. Each number is the result of 57344sin(0); 57344sin(0.001);57344*sin(0.002), and so on
...
I read somewhere on this forum that calculating over and over every single sin function variable consumes processor time and for this reason I want to compare what solution is faster.
This sounds like a big XY problem to me.
(What is an XY problem? See: http://xyproblem.info/ )
What do you ultimately want to do with these numbers?
hbtousa: Converting a number such as 16.38398908 to ASCII characters<== Can this number be converted to HEX and if so, how many bytes as a result will I get?
When we make a definition like this float x = 16.38398908;, the Compiler automatically stores a 32-bit (4 byte) value into 4 consecutive memory locations. The standard that the Compiler follows for this transformation is known as binary32/IEEE-754. The following data structure could be used to catch these 4 bytes data in the array named byte myArray[4].
union
{
float x = 16.38398908;
byte myArray[4]; //content of myArray[0] is the lowest LSByte
} myData;
There is another complication if you try to send floating point variables in binary format - the receiving computer may not interpret the 4 bytes the same way that an Arduino does. There is probably some ability in the PC software to interpret the data correctly - but don't assume it will be the default system.
Sending the data in text form avoids that sort of problem.
Robin2:
There is another complication if you try to send floating point variables in binary format - the receiving computer may not interpret the 4 bytes the same way that an Arduino does.
The complication will not be there if the user knows the endianness of the Arduino Processor (little endian) and the endianness of the Receiving Computer which is usually of 'little endian' for Intel Processors.
It is convenient to transfer a floating point number in binary format using .write() method if the receiver has a plan to process the data. If the intention is just to display the number, then the .print() method is good enough to transfer the float number.
GolamMostafa:
The complication will not be there if the user knows the endianness of the Arduino Processor (little endian) and the endianness of the Receiving Computer which is usually of 'little endian' for Intel Processors.
For many users that in itself will be a significant complication. How does a newbie find out which "endian" is used where? How does a newbie even know what "endian" means?
But the complications don't stop there. Endian-ness may be enough to make multi-byte integers compatible. But it is not sufficient to ensure that floating-point representations are compatible.
Robin2:
For many users that in itself will be a significant complication. How does a newbie find out which "endian" is used where? How does a newbie even know what "endian" means?
But the complications don't stop there. Endian-ness may be enough to make multi-byte integers compatible. But it is not sufficient to ensure that floating-point representations are compatible.
A veteran with 40 years experience in programming and technical business management joins the Arduino Forum as a Newbie; the reverse is also true where a hobbyist with background in history joins the Arduino Forum as a Newbie. Therefore, s/he is the Newbie or the Brattain Member does not matter much to the Arduino Forum Volunteers in respect of disseminating their know-how in broadcast mode. Let there be the definitions of --
Little Endian: Assume that we have one byte data -- 0x23. We need only one memory location to hold this data as one memory location can hold only 1-byte (8-bit) data. Now, we have one word data -- 0x1234 where 34 is known as lower byte (by definition) and 12 is known as upper byte (by definition). In order to store the given word-data (2-byte) in memory, we need two memory locations. Let us assume that the arbitrary addresses of these locations are m0 and m0+1 where m0 is known as low-address memory location and m0+1 is known as high-address memory location.
We will say that the Arduino UNO Processor (ATmega328P) is of Little Endian architecture if the processor saves the lower byte of the word-data into low-address memory location and the higher byte of the word-data into high-address memory location in response to our following declaration : (Note: Arduino UNO Processor is of little endian architecture.)
unsigned int x = 0x1234;
32-bit Floating Point Representation: When we make this declaration float x = 12.35;, the Compiler stores 32-bit value (4-byte) into 4 consecutive memory location as per binary32/IEEE-754 format. This is known as 32-bit Floating Point representation Scheme where the accuracy is 6-digit after the decimal point.
64-bit Floating Point Representation: When we make this declaration double x = 27.53;, the Compiler stores 64-bit value (8-byte) into 8 consecutive memory location as per binary64/IEEE-754 format. This is known as 64-bit Floating Point representation Scheme where the accuracy is 13-digit after the decimal point.
If someone never heard of endian and knows f*** all about CPU hardware they would not even know that they need your definitions.
And if they don't try to send binary data they don't need to know so they can focus their limited learning capacity or time on something that is more useful to them. And we all have limited learning capacity or time - maybe playing Lego with the kids is more important than learning endian-ness.
Robin2:
If someone never heard of endian and knows f*** all about CPU hardware they would not even know that they need your definitions.
There is one poster in the Forum who is found to use f*** as a source of wit and humor; one more poster is in the process of being added in the list; but, the motivation is not well understood.