next topic »

[Reply #15 on:]

Any one have a real world example where benchmarks show a big win?

The average data rate has to be lower than the serial data rate, and the size of data output "per call" has to be lower the the space available in the output buffer.

For example, a 64 byte buffer is a win if I send a 32byte message with a status update of my computations, once every second, at 19200bps.  With buffering, the computations will run essentially continuously.  Without, they'll be stalled waiting for the serial port.  Of course, under those circumstances, you're not spending a lot of time doing output anyway...

The following sketch is an example.  It runs about 250ms faster (out of about 20 seconds) in 1.0 than in 0022 (which is a bit odd, since I figure it ought to be running closer to 600ms faster (~30ms for each of ~20 lines printed.)  I wonder what's going on?)

Code:

unsigned long counter;

void setup()
{
  Serial.begin(9600);
  counter = 0;
}

void loop() {
  counter++;
    if ((millis() % 1000) == 0) {
    Serial.print("Counter reached ");
    Serial.print(counter);
    Serial.print(" in time ");
    Serial.println(millis());
  }
  if (counter >= 500000) {
    Serial.print("\nCounter Completed at ");
    Serial.print(counter);
    Serial.print(" in time ");
    Serial.println(millis());
    while (1) ;  //stop
  }
}

[Reply #16 on:]

Code:

if ((millis() % 1000) == 0) {

millis occasionally increments by 2.

[Reply #17 on:]

it hurts performance no worst then what we have presently, always blocking, at of course with the cost of the additional buffer.

When there's only 2K of RAM that cost might be too high.

The answer is to allow it to be customized - #define a size before you include the header file.

(Even worse I think is the problem that a 128 byte input buffer is currently allocated even if you only ever send data...)

[Reply #18 on:]

westfw,

I think each 32 byte line takes about 15 ms at 19200 baud.  With no buffering there is no blocking for the first two bytes so the difference should be for 30 bytes. 

20 lines at 15 ms/line is 300 ms total.

That's close to your observed 250 ms.

Thanks for the example. 

It only gains about 300 ms out of 20 seconds or about 1.5%.

[Reply #19 on:]

(yeah, but it's running at 9600bps...  And: here's the actual output without buffering.  Each print implies that the initial printing (before the second call to millis()) takes nearly 30 ms (as expected.)  And there are 21 of them, so that should be close to 600ms of just printing.)
Counter reached 1 in time 24
Counter reached 23839 in time 1029
Counter reached 47416 in time 2029
Counter reached 70968 in time 3028
Counter reached 94437 in time 4029
Counter reached 117989 in time 5029
Counter reached 141432 in time 6030
Counter reached 164851 in time 7029
Counter reached 188187 in time 8030
Counter reached 211739 in time 9030
Counter reached 235158 in time 10030
Counter reached 258576 in time 11030
Counter reached 281862 in time 12029
Counter reached 305280 in time 13030
Counter reached 328567 in time 14029
Counter reached 351878 in time 15030
Counter reached 375059 in time 16029
Counter reached 398585 in time 17030
Counter reached 422003 in time 18030
Counter reached 445397 in time 19030
Counter reached 468708 in time 20030
Counter reached 492101 in time 21029

Counter Completed at 500000 in time 21399
(with buffering, the code shows 1ms or less delay between the millis() calls.)

[Reply #20 on:]

Oh, you said 19200 but the posted code has 9600.

Wonder what's going on?