retrolefty:
So a program can lock up just because I don't open the serial monitor to see the output?
Blocking should really be optional
No, there is no handshaking between the PC/FTDI/8u2 and the AVR, it just sends data out regardless if there is anything out there ready to read it. Blocking only lasts as long as it takes the serial characters to leave the hardware USART on the chip, so it's baud rate dependent as well as how many characters need to be sent.
Lefty
As far as handshaking goes that is assuming a simple UART implementation.
Some "Arduino" boards provide serial communications over native USB
(teensy for example) which does have flow control handshaking.
And while those implementations are not using the Arduino core code,
in order to have a consistent API, the serial API should clearly define its behaviors.
Currently, it doesn't. The serial.write() function currently (pre 1.0) does not define if it blocks or not.
For those programs that do not want blocking to ever occur, blocking for
"as long as it takes the serial characters to leave the hardware USART on the chip" may be too long.
Which can be quite a long time since things like print() can block on each output character once
the output buffer fills.
I can easily envision applications that would need the API to never block even for a
single character (say you want to output characters from an ISR), or simply can't tolerate any
blocking because of other critical timing.
And then there are other cases where you want no buffering due to RAM needs or other synchronization needs
and others where you want buffering but it is ok to block like it does today in 1.0
Applications can have needs and uses for buffered output as well as non buffered output
but the newest HardwareSerial code is forcing a change from a non buffered output implementation that
was smaller and used no RAM that had been in place for many years
to one that is larger and uses quite a bit of RAM with no ability to alter the buffering
or behaviors.
The current 1.0 implementation is now a hybrid. It sometimes will block and sometimes not block
depending on character output patterns and baud rates,
but yet you always pay for it in terms of code size and RAM usage because there is no way
to configure it without editing the actual HardwareSerial source code.
serial 1.0 defines a return value of how many characters were written.
Once the API defines a return value of the number of characters written, users must now be prepared
to deal with that being zero - while today that is not the case, the new 1.0 serial API does allow that.
So for example, if the serial write() function were to return zero when the buffer filled vs block,
things like the Print class break (or probably not work as expected) because while
they do use the return value from write() they do not use it advance the
character pointer. i.e. any characters passed to write() when write() returns zero are dropped on the floor.
There are pros/cons to having a non blocking Print class but this is currently not configurable.
Seems like this implementation needs more tweaking before a final release because like I said
before, these API and under the hood changes are changing several things all at once
and offer no way to tune the behaviors or additional resources being used nor
do they offer a way back to the previous behavior and minimal resources used.
I agree with fungus, in that I question the value of forcing buffered output on everyone.
I think that the new buffering functionality should have to be be requested rather than forced so that by default
those less sophisticated users (which is what arduino is all about) can continue to have the
simpler, non overlapping, more code and ram efficient interface they've had
for years and those that want/need the additional capabilities can turn them on
tune them to their needs. (rx&tx buffer sizes, and blocking/non-blocking on full tx buffers)
--- bill