samtal:
To the main point: My question was related to large number mixed values concatenating and formatting. Saving into a buffer can be an option, but not a nice one, and I need to test it to make sure I can format each individual value differently.
Why is using a buffer not a "nice option"? No matter how you print something, a temporary buffer is used, Note that if you declare a buffer in a function, it's ram usage exists only as long as the function runs. The memory is freed when the function is complete.
What we all should be using is C's standard "[b]printf[/b]" , but in keeping with the Arduino policy of not supporting essential functions in order to save half a dozen bytes, we are forced to either use a bunch of "[b]Serial.print (this)[/b]" and "[b]Serial.print (that)[/b]" functions, ad-nauseaum, in order to print a simple, single line of text on the terminal or [b]sprintf[/b] and a buffer.
And, because of the fear of using a few more bytes of memory by using standard in, standard out and standard error, burned into everyone's mind by people who don't have a clue what they are talking about, Arduino users won't even use a simple library that automatically provides stdin/out/err access claiming every reason from "uses a few more bytes" to "it blocks" to "it will stop the sun from shining" to "the IDE doesn't support it" (when, of course, the IDE doesn't support ANYTHING... AVR-GCC does and indeed AVR-GCC does support all C/C++ functions) and instead happily go on typing ridiculous stuff like this:
int volts = 120;
Serial.print ("Voltage: ");
if (volts < 10) {
Serial.print (" "); // align columns
}
if (volts < 100) {
Serial.print (" "); // align 100's place
}
Serial.print (volts);
Serial.print (" VDC");
Serial.print ('\r'); // goto...
Serial.print ('\n'); // ...new line because the Print library doesn't even
// know how to translate a Unix newline into a CR/LF.
When they COULD just do this:
int volts = 120;
fprintf (stdout, "Voltage: %3d VDC\n", volts);
Don't know why... maybe there's some perverse pleasure in repeatedly ramming one's head into the wall.... ?
And, if the user doesn't want to install a simple library to make things 1000% easier, the next best method is to use a temporary buffer and "[b]sprintf[/b]" which is almost as good (but not AS good) as using printf directly.
While we're at it, the Arduino developers, in their wisdom(?) not only disable floating point print support without providing the option of using it if desired, they also espouse the use of "[b]dtostrf[/b]" which is complicated, not understood by a lot of people, doesn't fully support "printf style" formatting and requires the user to provide a temporary buffer for it (and the user is responsible for making sure the buffer is large enough).
Everyone shies away from floating point because it uses a few dozen more bytes of memory, but the fact that "dtostrf" also consumes program and ram space doesn't seem to bother anyone.
I feel sorry for any Arduino user who ends up programming for a living, because they will forever be hampered by all the convoluted or just plain wrong "facts" they learned from the "experts". Learning something new is tough enough without having to also UNLEARN the wrong stuff the "experts" taught them.
...and don't even get me started on the absurdity of worrying about a function "blocking" when the code is single tasking/ single threaded and running on a toy microcontroller with a quarter meg or less of memory (or, nuttiness in the other direction...) setting up a bunch of interrupt handlers to read the state of a switch or blink an LED on and off... 