Serial.printf Does it exist?

msaine

Active member
As usual I'm a bit confused :)

I was using the XPT2046_Calibrated.h (and or XPT2046_Touchscreen.h) library to check the settings on a Raspberry pi 3.5 inch touch screen and noticed in the code:
tft.printf("%u-(%u, %u) [%u, %u] {%u, %u}\n", 4-waitloop,touch.x,touch.y, p.x, p.y, sp.x, sp.y);
and then later:

Serial.printf("[X_LO, X_HI] = [%u, %u], [Y_LO, Y_HI] = [%u, %u]\n", xLo, xHi, yLo, yHi);
and I thought cool Serial now supports printf, great. Compiled the test code and yes indeed it compiles and works fine.

Later I said that's cool, now I can use printf in other code, life's good....until...

I tried to compile my code and it gets a unknown member for Serial ????

C:\onedrive\Arduino\libraries\RF24/utility/Teensy/RF24_arch_config.h:22:16: error: 'class usb_serial_class' has no member named 'Serial'
#define printf Serial.printf
^
I did notice that this is an included file but it is the "first" error so it is the one that counts.

I checked the includes for both routines and all of these are in both files as my code also uses the touch screen stuff

#include <SPI.h>
//#include <XPT2046_Touchscreen.h>
#include <Adafruit_GFX.h>
#include <Adafruit_ILI9486_Teensy.h>
#include <XPT2046_Calibrated.h>

#include "MyLCD.h"
#include "ctrl.h"

I guess my real question is does Serial.printf exist?? if not why does the test code for calibration compile?

I attached to original calibration file, but it uses a different tft. Mine is modified for that an a lot stripped/changed out but I felt the original file would be needed as an example. Mine is the 11.6k version. Mine compiles but the third file, using printf does not.

What am I missing?
 

Attachments

  • TouchCalibration.ino
    10.2 KB · Views: 26
  • TouchCalibration.ino
    11.6 KB · Views: 22
  • controller00.ino
    22.8 KB · Views: 21
What board are you building for?

It is defined for Teensy boards and some other boards as well, and other boards it is not defined.
 
If you have code with Serial.printf() and you also add #define printf Serial.printf, then hopefully it's obvious the compiler will try to compile that code as Serial.Serial.printf(). That's going to give you an error about the class not having "Serial". It has nothing to do with lacking printf(). The error is caused by a define meant to allow bare printf() with no class instance happens to mess up Serial.printf().

To make this work, delete this:

#define printf Serial.printf

and search for any printf(). Change all printf() without Serial to "Serial.printf()".

Teensy definitely does have Serial.printf(), so this will work once you get rid of that define and make sure all printf() are with "Serial." prepended.
 
Teensy definitely does have Serial.printf(), so this will work once you get rid of that define and make sure all printf() are with "Serial." prepended.
At least in the past, there was the gotcha that if you used one of the space saving options, it would use a version of printf without the %g, %f, and %e format specifiers. Most users don't need those, but if you are doing floating point code, it may be an issue.

On other environments, the floating point stuff may be deleted all of the time.
 
If you have code with Serial.printf() and you also add #define printf Serial.printf, then hopefully it's obvious the compiler will try to compile that code as Serial.Serial.printf(). That's going to give you an error about the class not having "Serial". It has nothing to do with lacking printf(). The error is caused by a define meant to allow bare printf() with no class instance happens to mess up Serial.printf().

To make this work, delete this:

#define printf Serial.printf

and search for any printf(). Change all printf() without Serial to "Serial.printf()".

Teensy definitely does have Serial.printf(), so this will work once you get rid of that define and make sure all printf() are with "Serial." prepended.

Thank you Paul for your expert answer. The funny part is I will probably not be using printf in any form as it uses about 6% of the code space for just a little convenience :) The tft code accepts printf with the same 6% code hit, guess it's the same library at the root of things. Knowledge is king thou.

I do appreciate the time all of you took to answer thou. Keep up the good work and thanks for the support!
 
Just curious what you're doing that fills up the flash memory to the point where 6% usage matters?

You're probably right. I guess a jump from 15% to 21% is at this point nothing to worry about. :) Old habit's die hard. Use to be a problem in past devices. The finished product wouldn't have the Serial stuff anyway. :) Just old concerns popping up in an old mind.... After all I was in high school when Kennedy was shot!
 
Just curious why the final product wouldn’t have Serial output? I can think of a few reasons, but I’ve made a few products with logging to the Serial port, and that logging has saved the day in more than a few cases.
 
Just curious why the final product wouldn’t have Serial output? I can think of a few reasons, but I’ve made a few products with logging to the Serial port, and that logging has saved the day in more than a few cases.

The single biggest reason is time. Each print takes time from main loop, this can affect final operation in some instances. Not always a problem but can be. If the project is time critical or is acting erratic, than Serial output is the first thing to comment out when testing. I do agree that Serial is probably the best debug in the Arduino environment but I am always selective in what is left in on final release. Again old school actions :) For those not aware there is a very handy define that helps a lot in generic debugging "__LINE__", which is defined as the current line number in the source code. __FILE__ is also handy. Serial.println(__LINE__);
 
Back
Top