SparkFun Forums

[stevech]

Any Ardino system software gurus out there?
Am I correct that the current Audino hardware serial library code does not use buffered output for the serial transmit? The code below, shows a busy-loop waiting on the prior byte to finish before sending the next. Unlike the hardware serial receive functions, there seems to be no ring buffer on the output, and use of transmit interrupts.

This busy loop would hose up timing-dependent code.

Code: Select all

void HardwareSerial::write(uint8_t c)
{
  while (!((*_ucsra) & (1 << _udre)))
    ;

  *_udr = c;
}

[stevech]

Any Ardino system software gurus out there?
Am I correct that the current Audino hardware serial library code does not use buffered output for the serial transmit? The code below, shows a busy-loop waiting on the prior byte to finish before sending the next. Unlike the hardware serial receive functions, there seems to be no ring buffer on the output, and use of transmit interrupts.

This busy loop would hose up timing-dependent code.

Code: Select all

void HardwareSerial::write(uint8_t c)
{
  while (!((*_ucsra) & (1 << _udre)))
    ;

  *_udr = c;
}

Perhaps a better question (I'm a c++ newbie) is: Are there derived functions for HardwareSerial::write() that implement buffered output?

[leon_heller]

http://siggiorn.com/?p=460

[westfw]

1) Yes, you're correct that there is no buffering in the core serial output function...

This busy loop would hose up timing-dependent code.

2) Any buffered output routine that didn't have an infinite output buffer would also potentially "hose up" timing-dependent code, mostly in less predictable ways that the current code. Unless you somehow guarantee that you generate serial traffic at a rate slower than it is transmitted (easy enough if you want to squirt out a analog reading or two every second. Considerably less easy in the general case!)

[stevech]

agree. But even a 128 byte output buffer would be a wise use of RAM. The application could check if that buffer is is too full before sending more output, and based on that, could elect to defer and do other processing. With the current unbuffered output, the application is likely to spin in a busy-loop on the UART output. At the default 9600 baud, this is about a millisecond of wasted CPU time and that's a lot of instruction cycles!