As I am running short of memory space for my sketch, I was wondering if I could "shorten" this part of the code somehow. Like for example "joining" the different elements first and then just doing ONE Serial.print with several elements (if that's possible at all?). Some kind of loop is no option, as the different variables are all independent.
At the same time - to make things a little bit more difficult - this part of the code is quite time critical and serial writes take quite a long time. So, if "more" could be written within a single Serial.print statement, this would be a huge advantage.
As I am running short of memory space for my sketch, I was wondering if I could "shorten" this part of the code somehow. Like for example "joining" the different elements first and then just doing ONE Serial.print with several elements (if that's possible at all?). Some kind of loop is no option, as the different variables are all independent.
"Joining the different elements" is possible. But, you need someplace to store the "joined elements", and that takes memory, which you seem to be in short supply of.
At the same time - to make things a little bit more difficult - this part of the code is quite time critical and serial writes take quite a long time. So, if "more" could be written within a single Serial.print statement, this would be a huge advantage.
No, it wouldn't. The Serial.print(), Serial.println(), and Serial.write() methods simply transfer data to a buffer, if there is room in the buffer. Transferring 10 bytes takes 10 times as long as transferring one byte.
If there is not room in the buffer, then the functions block until there is. Whether that happens in the 4th of 10 print() calls, or the 1st of 1 makes no difference in how long it takes to get the data to the buffer so it can be sent.
The speed of the serial prints is limited by the speed of the serial port. If the calls are blocking, that means the serial output buffer has filled up, forcing the program to wait until there's room in the buffer to put what you're trying to print into it. Serial.print itself is pretty fast as long as there's space in the buffer to put the stuff you're printing. Serial speeds are in baud, which is bits per second, and serial has 1 start bit and 1 stop bit in addition to the 8 data bits, so 9600 baud = 960 bytes per second max
Without seeing more code though, it's impossible for us to generalize about optimizations (other than that you should be using the F() macro to save SRAM - that won't help you with flash though)
@PaulS: How could I "join the different elements". If you could give me an example, I could check whether maybe I can gain more space by having less instructions compared to what I am loosing for the "joining". . I see your point regarding the timing. Now that you mention it, it seems obvious, but I was somehow under the impression that the simple fact of using the instruction would consume a "large" amount of time.
@DrAzzy: Thanks for telling me about the F() macro, I didn't know it yet. But you are are right, in this case it is exactly the SRAM that I'm running short of, so this will unfortunately not help.
@el_supremo: Loops are unfortunately no option as the values are completely independent and no array (I think getting them into an array would take me more instruction space than leaving as is)
If you could give me an example, I could check whether maybe I can gain more space by having less instructions compared to what I am loosing for the "joining".
The sprintf() function can write to a buffer. Then, you can Serial.print() the buffer.
Pete , OP told you about running out of memory a showed you a snippet of code he thinks is causing his problem.
So what made you to make such blanket and misleading suggestion?
Where is the memory saving coming from?
Putting Serial.print("") into loop?
Putting variables into an array?
Maybe time to bump up to a processor with more SRAM?
'1284P, 16K SRAM, 128K flash.
I offer boards in various form factors, such as this Uno style board.
FTDI interface (onboard or offboard options), 32 IO, 2 hardware serial ports. www.crossroadsfencing.com/BobuinoRev17/
// print 10 data elements, varArray[0] to varArray[9]
for (byte x = 0; x<10; x=x+1){ // print 10 data elements, varArray[0] to varArray[9]
Serial.print(" ");
Serial.print (varArray[x], DEC);
}
@PaulS: Thanks for pointing me at the sprintf() function. I think that's probably what I was looking for and what's as good as it can get under the given conditions.
@all: I understood el_supremo's (pete's) idea and it was actually what I was initially thinking about myself (if the variables were in array form, the loop can save lots of instruction space). However my variables are no array and getting them into one will probably take me more space than leaving as is. Crossroads' sketch is exactly this loop method. Thanks again.
However the optimizing compiler is very clever. It may have already worked out that it only needs to store " " once and all three print statements can refer to the same memory location. This version may actually be bigger when it is compiled.
The F() macro is going to make a lot of difference but not in this part of the code. I usually use it for any string longer than 4 chars. Short strings cannot be made any smaller by using F().
However the optimizing compiler is very clever. It may have already worked out that it only needs to store " " once and all three print statements can refer to the same memory location. This version may actually be bigger when it is compiled.
The F() macro is going to make a lot of difference but not in this part of the code. I usually use it for any string longer than 4 chars. Short strings cannot be made any smaller by using F().
Thanks for posting this. I was actually trying to convey similar stuff in my post, and I am glad you did pointed out the Serial.print "nothing memory hog".
I just did not want to get into this too deep.
The OP was not too clear if he is running out of variables memory space or code space.
They both need different "solution".
And I did not get why would "sending" more data in one Serial.print instruction improve desired "timing" anyway. Beside it look as he was just "sending" numbers anyway.
Specially when the OP stated he cannot put the variables in an array - struct are pretty handy dealing with different TYPES of variables if need to.