That number should fit into 64 bits, which means that it can be represented by a maximum of 8 bytes. Use the sdoull standard lib function to convert it. Note that this won't work on an Uno since it doesn't have the resources to include the std namespace. An ESP32, RPi Pico should be fine though
std::string str = "1214730647285";
uint64_t num = std::stoull(str);
Someone showed you a "number trick?" Now try 256(10). "256 is greater than 255 so we take the 25, then the 6 and get two bytes..." I prefer "old math" 100(16) over your 19 06(goofy)
Arduino Uno can use type unsigned long long variables.
Perhaps the OP would be better served by BCD where each byte represents 2 digits with no ambiguity and it can support very large values. That's how 4-bit calculators worked, with exponents as well as mantissas.
Using this algorithm if I have a number like "132.04" I can separate it into
"132" : 01 32
"04": 04
How can I know 04 is .4 or .04? Is there any standard library/function for it that handles these cases?
if you want to send values with decimal digits as integers, instead of floats, you can scale them up by a fixed amount: 10, 100, 1000 when transmitting and scale them down after receiving.
132.04 becomes 13204 which is 0x33, 0x94. but seems you still need to either specifiy the # of bytes being transmitted or transmit a fixed # of bytes for each value (e.g. 0x00, 0x00, 0x33, 0x94)
of course you can always send it as ASCI string "132.04" of varying lengths (e.g. ".1")
Because 04 in binary is 0000 0100
the first nyble is literally 0, the second literally 4
I dunno about a standard library but this goes back to the 60's if not before. It is how 70's hand calculators worked.
If you want a system with software and complete explanation/tutorial: Nick Gammon on Big Numbers
Nick was a very active member here when I arrived in 2011, he had many 1000's of Karma points then for good reason.
One level up on that link gets the whole set of whatever is there, it is a complete explanation with code, schematics and illustrations beyond what forum posts will getcha.
Your example deals with decimals in which case could be fixed length or be either fixed point where the last digit is always tenths or have a fixed length number of places like
0x01 0x32 0x04 0x02 with the last byte as 2 BCD places after the decimal point.
How I deal with decimals in binary is to choose my working units carefully, a version of fixed-place. If I want to deal with meters to 3 places I work in micrometers (long or unsigned long) and then when divisions occur I have 3 places precision to lose and still get correct results to the mm. The only time a decimal place turns up is in the displayed result that has to be text anyway and I code for that, have since the early 80's.
No, it was converted to 17 bytes if you're talking about ASCII (counting the commas and not counting a null terminator).
It seems that you (like countless other newbies) are wrapped around the axle when it comes to the concepts of binary numbers verses their representation in human-readable form.
The most efficient way to transmit numbers is in their raw binary form. Then, n bits of data occupy n bits on the "wire". This however presents problems with framing and ASCII transport mechanisms that don't work well with the non-printable control characters that binary data inevitably contains.
The standard method for transporting binary data (images, etc) over the internet with http and similar protocols is to use Base-64 encoding. With this, every 6 bits of data occupy 8 bits on the wire. So, it takes 4 ASCII bytes to transmit 3 bytes of binary data. This is a 4/3 X expansion, but it has the advantage that the data stream is all printable ASCII (though not human-readable). It's also more efficient than the 2 X expansion you'd get from using ASCII Hex. And, it's vastly more efficient than your proposed scheme.
So if you had the number 3678546345 you'd break it up into 36, 78, 54, 63, and 45. So you're sending 5 bytes.
But thtat number is already represented in your Arduino as 4 bytes in binary. Wouldn't it be more compact to just send the 4 binary bytes and reassemble on the other side?
That is stupid simple to do and doesn't involve any ambiguity like your method does.
Agreed, as long as the transport mechanism can deal with raw binary data and framing so the received bytes can be reassembled properly. Otherwise, if transport in printable ASCII is required, Base-64 is probably as efficient as you can get (Post #14).