String concatenation for Serial.print

TonyWilk: Yes, although 'code size and efficiency' is somewhat dependant on requirements; simple debug output is one thing, formatting several lines for an LCD is another.

When I did 68HC11 assembler programming, I had good luck formatting and printing text on an LCD display simply by making a "virtual" LCD screen in ram, then placing characters and numbers where I wanted them, then called a simple block copy subroutine to copy the "virtual" LCD screen to the real one.

The 68HC11, BTW, only has 256 bytes of SRAM, 512 bytes of EEPROM and a 64K address space (shared by eeprom, sram and registers).

Now THAT'S a processor where you need to watch each and every byte!

Delta_G: Not bad depending on what you're going for. Convenience or code size. I'd like to remind that the OP in this case was concerned with code size and efficiency.

Ah, but what is "efficiency"? Ease of writing code? Easy to read and debug source? Small, compact machine code? Tight, fast running loops?

"Efficiency" can mean many different things.

krupski: Now THAT'S a processor where you need to watch each and every byte!

Getting off-topic now... Ah yes, programmers these days think they're hard done by with Kilobytes of memory.

Many moons ago I worked for Texas Instruments and then National Semiconductor (now joined) on very early micros. The NatSemi COP400 series was a 4-bit processor with a huge 64 NIBBLES of RAM. You didn't even have a byte to watch.

Can't exactly say those were the good old days tho' :)

Yours, TonyWilk

Attiny13, which is sort-of supported by tinycore, has 1k flash and 64byes RAM. Fortunately, it doesn't have. Serial port, either, so the choice between serial.print and printf is a bit moot.

I would have thought that the atmega48, with 4K flash, would have gotten more attention, but I guess the mega8 passed I in price

krupski: Ah, but what is "efficiency"? Ease of writing code? Easy to read and debug source? Small, compact machine code? Tight, fast running loops?

"Efficiency" can mean many different things.

Efficiency can mean many things. In this case it was explicitly laid out that the OP was not concerned with it being efficient to write but rather efficient for the processor to run. See reply #4 where the OP made that quite clear. Seems you're so distracted by your rant about why the IDE doesn't include some feature that you desire that you've completely forgotten that we are answering a concrete question with explicit parameters for which your answer is still wrong. Changing the question makes it different sure. But for the question here as asked and clarified in #4 adding extra overhead to have the processor format the text is the opposite of what the OP asked. You can rant and rave about all the reasons why YOU like this way or that way better. But the question we are answering isn't about what you like but about which method is less work for the processor.