Is there such a thing as fast Serial.println?

Is there such a thing as fast Serial.println in a library some one has developed.

Similar to the fast digitalWrite functions.

The println's below tell me that loop() executes in 53 millisecods, but I would say that the vast majority of that time is in doing the serial output stuff.

I need to get a reasonably accurate execution time for these functions minus the serial output.

void startCycle()
{
  static unsigned long lLastTime = 0;
  long unsigned lNewTime = millis();
  unsigned long lRotationPeriod =  lNewTime - VirtualClockDisplay.getClockPeriod();
  float fClockTimeSlice = 0.0;
  
  VirtualClockDisplay.setClockRotation(lNewTime - lLastTime);
#ifdef _DEBUG
  //VirtualClockDisplay.draw(5, 17, 1, 2017, 16, 7, 0);
  Serial.print("startCycle() took ");
  Serial.print(lNewTime - lLastTime);
  Serial.println(" milliseconds to complete...");
  lLastTime = lNewTime;
#elif
  VirtualClockDisplay.draw(MyRTC.getDOW(), MyRTC.getDOM(), MyRTC.getMonth(), MyRTC.getYear(), MyRTC.getHour(), MyRTC.getMinutes(), MyRTC.getSeconds());
#endif
}

void loop() 
{
  if (IR_Reciever.decode(&IR_Results)) 
  {
  }
  else
  {
    startCycle();
  }
}

Take the Serial stuff out of the thing you're timing.

if (IR_Reciever.decode(&IR_Results)) 
  {
  }
  else
  {
// print "started"
// start the clock
    startCycle();
// stop the clock
//print elapse time
  }
}

It seems like you're trying to profile your code. There was a few posts about code profiling only a week or so ago, if you search the forum.

please post the whole sketch..... as this way no one can reproduce the problem.

You can use a higher baudrate e.g. 230400 and 345600 and 500000.
However the receiving end must support this speed.

use Serial.write( ptr, len ); for a slight speedup.

Most of serial's work is done in interrupts. If you want to time your loop properly disable interrupts for the portion of code in test. This will prevent serial from clearing its buffers while your critical code is running. This is useful if you have a portion of code that must run uninterrupted :P.

If you forget to turn interrupts back on Serial will stop sending and also loose data once the buffer is full.

The library linked in my sig makes it easy.

{
  AtomicBlock< Atomic_RestoreState > a;

  //Code here is protected from interrupts.
}
//Code here is not protected.

robtillaart:
You can use a higher baudrate e.g. 230400 and 345600 and 500000.

...and 1 M (my poison of choice).

If you forget to turn interrupts back on Serial will stop sending and also loose data once the buffer is full.

No, it won't. It will block waiting for room in the outgoing buffer. Of course, that will never happen, since room is made only by interrupts happening to shift data out, making room, and interrupts won't happen with interrupts disabled. So, the Arduino will hang.

PaulS:

If you forget to turn interrupts back on Serial will stop sending and also loose data once the buffer is full.

No, it won't. It will block waiting for room in the outgoing buffer. Of course, that will never happen, since room is made only by interrupts happening to shift data out, making room, and interrupts won't happen with interrupts disabled. So, the Arduino will hang.

Yeah I forgot that part, however the hang will only occur if the buffer is filled. I've had an app work fine, but no serial output until I intentionally sent large strings of frustration.

Disabling interrupts can also cause not being able to receive data..

I'm hoping that my answer, which has to be the best one 8), and is about taking the serial prints out of the thing to be timed, has not been lost to the OP in the clutter arcane discussion.

JimboZA:
I'm hoping that my answer, which has to be the best one 8), and is about taking the serial prints out of the thing to be timed, has not been lost to the OP in the clutter arcane discussion.

Your answer is the most to the point one! The best way to minimize time spend is not doing it :slight_smile:

robtillaart:
please post the whole sketch..... as this way no one can reproduce the problem.

You can use a higher baudrate e.g. 230400 and 345600 and 500000.
However the receiving end must support this speed.

I tried that.

Even if I go into Windows device manager and change the baud rate of the arduino com port and then use that baud rate in the call to Serial.begin I get total garbage in the serial monitor window.

boylesg:
if I go into Windows device manager and change the baud rate of the arduino com

That was news to me. So far all the programs I've used (Arduino IDE; Delphi, Processing ... ) you set the baud rate in the program when you "open" the port. Iif you set it i the window manager then the program will reset it to it's setting ... which fits you problem description.

The Arduino IDE does not support higher than 115200 baud.

Use a terminal program like putty.exe (not the best but it works)

robtillaart:
The Arduino IDE does not support higher than 115200 baud.

Use a terminal program like putty.exe (not the best but it works)

I like putty better than the serial monitor. No need to press the "send" button to transmit data. It's also more robust - if your sketch sends garbage serial data it's easy to crash the Arduino serial monitor.

The Arduino IDE does not support higher than 115200 baud.

It doesn't need to. The Serial Monitor, on the other hand, maybe should.

Msquare:
So far all the programs I've used (Arduino IDE; Delphi, Processing ... ) you set the baud rate in the program when you "open" the port.

I tried it that way too and I still get garbage in the serial monitor.

I think managed to get a bit of a rough idea of how long serial.print takes to execute with a numerical string of 3-4 characters via a couple of consecutive calls to it and using a 'micros() - nLastCount' sort of thing.

It appears to be 400 - 500us with a string a 3-4 characters long.

So the function I am actually testing appears to take roughly 5ms to execute, taking into account the above.

Still seems a bit slow given 16MHz clock speed.

So the function I am actually testing

which I'm not going to show you

appears to take roughly 5ms to execute, taking into account the above.

Still seems a bit slow given 16MHz clock speed.

Well, I can't argue with that.