SOLVED When was printf added ?

I have some older code which uses both plain printf and Serial.printf
As in past I have modified Print class (in current release) per this article.

http://playground.arduino.cc/Main/Printf

Using plain printf works , but Serial.printf gives this error

<command-line>:0:8: error: 'class UARTClass' has no member named 'iprintf'
/home/jim/Arduino/I2C_LCD_TEST/I2C_LCD_TEST.ino:46:10: note: in expansion of macro 'printf'

It appears that printf is now part of the core, therefore the modification of the Print class is not necessary.
If that is true, when was printf implemented ? In what IDE release?
( I could go back to release prior to printf implementation.)

Secondary question - why does not Serial.printf compile?
According to the modification to Print class it should work.

Due to extensive usage of both printf and Serlal.printf I like to correct the Serial.printf problem.
I currently using Linux 1.6.11 and this is the only issue stomping the compiler.

Appreciate help.

I have checked printf on Windows IDE 1.6.4 , it compiles but does not output.
It outputs on 1.6.11.
Serial.printf indeed compiles and outputs on 1.6.4.
Right now I cannot find which print.h was modified , it was couple of year back, sorry.
It also looks as print.h was part of AVR core code. IDE 1.6.4 has no SAM directors as far as I can tell, but I am sure I missed it.

All and all - knowing about printf is nice , but I really need Serial.printf to work to avoid major code rework. ( find and replace in all tabs -scary but doable )

I've found that printf seems to be part of the SPI library.

Arctic_Eddie:
I've found that printf seems to be part of the SPI library.

"Print" is an Arduino class declared / defined in Print.h , printf should be part of be standard stdio header.
Little confusing.

Do you know which SPI cpp or header file? It would help.

It was found in the TMRh20 library for the nRF24 radios. I saw it used in their examples but it failed if SPI was not included. The essentials are not very well defined.

printf() is not part of the Arduino core but typically comes with the compilers libC library.

But it takes some glue to make it work as in an embedded system it has to have some assistence to get the characters handed to the proper output device driver.

There is a difference between having a printf() function and having printf() as part of the Print class.

You may want to take look at the writeup I did here:
http://playground.arduino.cc/Main/Printf

The teensy core has a printf() function as part of its Print class so you can reference from any object that inherits the Print class. No mods necessary.
For all the other cores, you will have to add it yourself.

If you want to take the easy way out and add a printf() function to the Print class, have a look at the PrintEx library.

While it isn’t yet documented, the latest version of PrintEx has the ability to wrap an object definition to transparently add a printf() function to the object.

It works like this:

#include <PrintEx.h>

Then declare your objects like this:

// for Serial
PrintExWrap<typeof(Serial)> &__Serial = PrintEx::wrap(Serial);
#define Serial __Serial


// for other objects where you get to define the object
PrintExWrap<name-of-your-class> objectname (with optional constructor);

— bill

As a first step in identifying where is the Serial.printf error coming from I found the preprocessor options in this link:
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
They are used in platform.txt and setting the -H option does nice job printing all include files hierarchies.
Little overwhelming, but it is a start. No more guessing the includes tree.

It's getting late, but the whole problem is that I have been modifying WRONG Print.h
So the -H option pointed me to right one. Now if I can only figure out why compiler uses .arduino15 device / directory and I just cannot see it under my /home directory structure.

So not IDE problem anymore , just learning curve on Linux.

<command-line>:0:8: error: 'class UARTClass' has no member named 'iprintf'

/home/jim/Arduino/I2C_LCD_TEST/I2C_LCD_TEST.ino:46:10: note: in expansion of macro ‘printf’

I’m disturbed that this seems to indicate that some header library you are including has redefined “printf” as a macro that translates it to “iprintf” - this seems like a really bad idea, and would affect the usage of both the libc “printf” AND any attempts to add a “.printf” method to the arduino “Print” or “Stream” classes.

julyjim:
It's getting late, but the whole problem is that I have been modifying WRONG Print.h
So the -H option pointed me to right one. Now if I can only figure out why compiler uses .arduino15 device / directory and I just cannot see it under my /home directory structure.

So not IDE problem anymore , just learning curve on Linux.

So far all the things you have been talking about in this thread have nothing to do with linux.
It seems to much more a learning curve on how the Arduino IDE works and does its builds using the gcc toolset.

--- bill

westfw:
I'm disturbed that this seems to indicate that some header library you are including has redefined "printf" as a macro that translates it to "iprintf" - this seems like a really bad idea, and would affect the usage of both the libc "printf" AND any attempts to add a ".printf" method to the arduino "Print" or "Stream" classes.

SAM core platform.txt has -Dprintf=iprintf in C & C++ compiler flags.

oqibidipo:
SAM core platform.txt has -Dprintf=iprintf in C & C++ compiler flags.

I'm with westfw on this.
Why the F would they do that?

It is obviously a "fix" for something that was done the wrong way and at the wrong level.

--- bill

This works on Nanos, Megas, and probably most others. It does not support float type. Serial.print is still needed for that type.

#include <printf.h>

void setup() 
{
    printf_begin();
}

void loop()
{
    // Example
    uint16_t weight = 32; // Grams
    printf( "The weight is %d grams.\r\n", weight );
    delay( 1000 );
}

westfw:
I'm disturbed that this seems to indicate that some header library you are including has redefined "printf" as a macro that translates it to "iprintf" - this seems like a really bad idea, and would affect the usage of both the libc "printf" AND any attempts to add a ".printf" method to the arduino "Print" or "Stream" classes.

westfw:
I'm disturbed that this seems to indicate that some header library you are including has redefined "printf" as a macro that translates it to "iprintf" - this seems like a really bad idea, and would affect the usage of both the libc "printf" AND any attempts to add a ".printf" method to the arduino "Print" or "Stream" classes.

To be honest I really wanted to find out WHAT caused this "iprintf" error , mainly because I use Serial.printf in my own macros.
But I kinda lost interest when I found I was modifying wrong Print.h file.

I have no issues with patching bogus code like this printf.
My heartburn comes when the documentation is non-existent,sketchy or grossly outdated.
As far as that - there seems to be no connection / continuity between "developers" and this site.

Perhaps two different companies? Or none?

Sorry for rant, I need to get back to coding.

Jim

I have some older code which uses both plain printf and Serial.printf
...I have modified Print class (in current release) per this article: http://playground.arduino.cc/Main/Printf

My heartburn comes when the documentation is non-existent,sketchy or grossly outdated.
As far as that - there seems to be no connection / continuity between "developers" and this site.

There are a couple of things you should probably understand:

  1. printf() is part of avr-libc, not part of Arduino. It's documented pretty well in the avr-libc documentation.
  2. the "playground" is an area for describing user-contributed software, so the Serial.printf() feature you've been adding isn't an official Arduino feature either.
  3. The whole directory structure and install methods for 3rd party libraries had changed drastically in the relatively recent past. Getting old user-provided features and/or documentation updated to the new methods is a big problem; users don't necessarily stay interested over the required timeframes, and they had in mind sharing a neat thing that the figured out, not being a support expert for that thing, forever.
  4. The directory structure for platforms (cores) (third party or otherwise) has also changed drastically in the relatively recent past. Same support problems :frowning: (Personally, I think installing extensions to "system" software (like the compilers for new platforms) in per-user directories is a terrible idea (and I use the "portable" feature that puts them in yet another place), but apparently Microsoft likes it.
  5. Yeah, the official Arduino.cc developers don't seem to participate much on the forums here. There's a separate "developers" mailing list that has more technical "internals" discussions, and the github "issues" list is another communications channel. Interestingly, it seems that arduino.org has specifically "addressed" this issue by assigning some people to respond to forum questions. Unfortunately, they don't seem to do it very well :frowning:
  6. Arduino.cc pays for and maintains the web site and forum software, manages the 3rd-party code contributions (in terms of deciding what does and doesn't become part of the official releases), does their own development, and builds the releases.