Go Down

Topic: Serial out buffer (Read 2877 times) previous topic - next topic

Goitaca

My question is about a  8)serial out:smiley-mr-green: buffer.

I am implementing a SW for my University that requires serial port to be sending and receiving messages all the time, very fast.
The main routine takes like 100 ms and cannot wait for a complete message completion.

Is it possible to send messages to a write buffer, something like read buffer, that will be administred with Arduino to send bytes for me, when serial TX port is available automatically?

Thank you very much!!!!  :)

fat16lib

Arduino 1.0 will have buffered serial output.  Beta 3 was just released.

westfw

Note that buffering will NOT speed up serial output if you are sending data "all the time, very fast."

I can't figure out why more people don't understand that.  If your serial port runs 9600bps, you can't send any faster than 9600bps...

fat16lib

While an app can't go faster than 9600, if that is the set baud rate, it can go slower.

Apps that have a lot of CPU or I/O overhead formatting output can be improved with buffered serial output.

The app can format the next message while previous output is sent by an ISR.

westfw

yes, if you send "less than a buffer worth of data, occasionally", then buffering can be a big help.
But that doesn't seem to be the case that people expect it to help...

fat16lib

I agree with westfw that serial output buffering doesn't help most applications.  At least not the way most users expect.

In my opinion, forcing output buffers in Arduino 1.0 to be the same size as input buffers is a mistake.  I would like an option to use unbuffered serial output.

Large serial input buffers can be very useful in apps like serial data loggers.  This allows longer latency for writing to SD cards when logging at high baud rates.

fungus


While an app can't go faster than 9600, if that is the set baud rate, it can go slower.

Apps that have a lot of CPU or I/O overhead formatting output can be improved with buffered serial output.


Only if you put in interrupt handling to send data in the background.

If you do that you run into multithreading problems...it all gets messy very quickly.
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

fat16lib

Arduino 1.0 beta does use interrupts for output and works fine.  No multi-threading problems.

I don't think most Arduino programs need buffered output.  I think it is a waste of RAM for most programs.

CrossRoads

Not much point in buffered output if there is no flow control to keep it from going out once written to the UART.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

retrolefty


Not much point in buffered output if there is no flow control to keep it from going out once written to the UART.

???
There won't be any kind of flow control on the interrupt driven buffered serial output in the new version. But it will keep the Serial output commands from being blocking commands, so the rest of the sketch can keep on keeping on while the buffer is emptied via the ISR.

Lefty

fat16lib

The 1.0 beta Serial works and is non-blocking as long as no more than 64 bytes are queued.

If Arduino was a multi-threaded system this could be a real win.

I have played with 1.0 and don't find programs that run faster due to output buffering.

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

fungus


The 1.0 beta Serial works and is non-blocking as long as no more than 64 bytes are queued.


Well that's the problem, right there...

Any program which does a lot of serial output will fill the buffer up and then the buffer becomes useless. It achieves nothing.

The buffer helps with programs which send a byte occasionally and need to return instantly. For programs which are sending large amounts of data it makes virtually no difference.
No, I don't answer questions sent in private messages (but I do accept thank-you notes...)

retrolefty

Quote
The buffer helps with programs which send a byte occasionally and need to return instantly. For programs which are sending large amounts of data it makes virtually no difference.


I think you overstate the negative. It of course will help in some very common applications like sending short messages to a serial LCD display. And in cases where it doesn't help, it hurts performance no worst then what we have presently, always blocking, at of course with the cost of the additional buffer. I consider it a worthwhile incremental improvement, like so many added over the last 3 years.

Lefty


fat16lib

It is a big problem for some apps.  If you log fast serial data to an SD, having a large input buffer can improve performance due to write latency for the SD.  It avoids dropped data.

Now you are required to have a large useless output buffer when you increase the input buffer size.

I don't believe the LCD example without more info.

retrolefty


It is a big problem for some apps.  If you log fast serial data to an SD, having a large input buffer can improve performance due to write latency for the SD.  It avoids dropped data.

Now you are required to have a large useless output buffer when you increase the input buffer size.

I don't believe the LCD example without more info.


Well complaining to me won't help you that's for sure.  ;)

Here is a link to the Arduino developers mailing list where they argue about and decide on what changes are and are not to be made to the IDE. http://arduino.cc/pipermail/developers_arduino.cc/

Lefty

Go Up