Board index » cppbuilder » Serial Port Buffer

Serial Port Buffer


2007-02-25 03:46:46 AM
cppbuilder16
I have a Serial app that seems to crater from time to time and I suspect that the Serial Port buffer is filling up. Is there a way to monitor the buffer status? I was thinking of showing a prograss bar that showed the number of bytes in the buffer with respect to the configured max. buffer size. Is something like this possible? If so, please advise how to do so.
Thanks,
Kev
 
 

Re:Serial Port Buffer

"Kev" < XXXX@XXXXX.COM >wrote in message
Quote
I have a Serial app that seems to crater from time to time and
I suspect that the Serial Port buffer is filling up.
What do you mean by "crater" exactly? Are you using hardware or
software flow control?
Quote
Is there a way to monitor the buffer status? I was thinking of
showing a prograss bar that showed the number of bytes in the
buffer with respect to the configured max. buffer size. Is
something
like this possible?
ClearCommError() returns the number of bytes in the buffer.
Gambit
 

Re:Serial Port Buffer

By "crater" I mean the data just gets scrambled. Obviously the data packets are getting misaligned with my structure. The data packets ar 48 bytes. I did manage to get the ClearCommError working on my own. I am sure I am not using the best of methods, but I am trying to get data from an industrial instrument that connects at 19200,N,8,1 and outputs 48 byte pckets at a maximum rate of 50ms/pkt. I am "intercepting" this data using a pretty cool app called "SerialShare". This allows me to keep in place the current instrument / software serial interface without changing it in any way. I just get a copy of the data stream and chart it. I had managed to get the app working except that after running for several minutes, all of a sudden the data was scrambled and it may or may not come back. After getting the CommError function working, I could see that the problem occured when the buffer was full (and sometimes when it was 0). I am just using a brute force method to get the data meaning just a Timer event rather than a thread. In any case I "solved" the problem by automatically adjusting the Timer interval and increasing the buffer size to 16k. I monitor the buffer size and speed up the Timer if the buffer exceeds some limit and slow it down if it falls below a threshold there by always keeping some data in the buffer.
I have to have a buffer because I am charting (with TChart) 12 chanels of data in realtime and as the chart series' data buffers start getting bigger and bigger, the chart starts slowing down. I only show the latest 500 or so data points, but 12 channels is still a pretty good load. Even with the Timer automatically adjusting, the 16k serial buffer fills up in about 1 hr. Even with the timer automatically ratcheting down to 1ms, it can't keep up with that much data. After about 1hr I have over 850,000 total data points in the chart. This is plenty good for the current application.
I suspect I will have to modify this in the future. I think I will probably have to "off load" the chart data to files at some interval keeping the total datapoints contained in the TChart within some predetermined boundries.
thanks,
Kev
"Remy Lebeau \(TeamB\)" < XXXX@XXXXX.COM >wrote:
Quote

"Kev" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>I have a Serial app that seems to crater from time to time and
>I suspect that the Serial Port buffer is filling up.

What do you mean by "crater" exactly? Are you using hardware or
software flow control?

>Is there a way to monitor the buffer status? I was thinking of
>showing a prograss bar that showed the number of bytes in the
>buffer with respect to the configured max. buffer size. Is
something
>like this possible?

ClearCommError() returns the number of bytes in the buffer.


Gambit


 

{smallsort}

Re:Serial Port Buffer

Hi Kev,
Quote
it was 0). I am just using a brute force method to get the data
meaning just a Timer event rather than a thread. In any case I
"solved" the problem by automatically adjusting the Timer interval
and increasing the buffer size to 16k. I monitor the buffer size and
I think using a timer for serial i/o is the worst solution. You wrote
that your TChart is filling up with the data from your device. When the
TChart has to redraw its content your program can't poll the serial port
in this time and it's just a question of time when the timer event comes
to late for your data (it seems that you're not using HW/SW flow
control). Your program isn't multithreaded so the timer event has to
wait until the TChart has finished its drawing, regardless of the timer
period!
What can you do?
1. Put all your serial code in a thread and use blocking reads on the
serial port for the device data. Put the received data in a thread-safe
queue and inform your main thread with an asynchronous message (::Post
message, NOT SendMessage or SYNCHRONIZE!) about this event. So your
serial port thread will never block and with this low data rate you will
never lose a byte anymore (I wrote low data rate because I'm using RS485
devices with 1.25 MBps here).
If you don't want to write this code on your own then look at the CPort
serial library. It is a reliable serial port library and should do
everything you need.
2. Don't store your data in the TChart. It is fast but at some point it
will make your application unresponsive if you have too many data points
in it. Let the TChart only display the data the user wants to see and
store the rest in an array or better an STL container or write it to a file.
Quote

I suspect I will have to modify this in the future. I think I will
probably have to "off load" the chart data to files at some interval
keeping the total datapoints contained in the TChart within some
predetermined boundries.

Keep your UI responsive and take care that you're serial i/o ist always
ready to read data.
Bye,
--
Dipl. Ing. Oliver Rutsch
EMail: XXXX@XXXXX.COM
Sympatec GmbH