Re: Serial port monitoring

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

ok, I'm convinced :)


Thanks

Phil


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message news:696jr3l2n2mt3gs1vvodne3mu6butb5d9i@xxxxxxxxxx
Actually, it probablly isn't easier to implement, because it involves introducing a
potentially unbounded blocking I/O call in the main GUI thread, and in addition introduces
a gratuitous 100ms delay that is not necessary.
joe

On Mon, 18 Feb 2008 07:56:49 -0000, "philip" <mfc@xxxxxxxxxxxxxxxxxxxxx> wrote:

Joseph

thanks for the information.

Whilst I fully accept that your methods are better, if (like me) you more
naturally think 'single-threaded and sequentially', my method may be simpler
to implement.

I'll take a look at your link as it sounds cleaner.

Phil


"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:853ir3t7d6kbktnfpeis8hq8mu95fa7uuu@xxxxxxxxxx
It is inappropriate to use a static string for this purpose. There's no
need for one.

First thought you should have when writing a global variable or static
variable: "I'm
making a design error". The variable should be a member variable of the
thread that is
doing the I/O.

There is no need for a timer; you want to get data when it is available,
instead of
waiting 100ms. The timer approach means you are still thinking
single-threaded and
sequentially.
joe

On Mon, 18 Feb 2008 00:30:59 -0000, "philip" <mfc@xxxxxxxxxxxxxxxxxxxxx>
wrote:

anywhere you like really :)

I was in a hurry and put a method in a view window and then set the timer
call it - this is not necessarily the best place

The main thing is that every 100ms or so you check the serial port and
read
whatever is there

In my project the device is sending lines of ASCII text

The problem is that when the Timer is triggered you may only have part of
a
line in the serial port, then by the time of the next trigger the rest has
arrived (plus some on the next line too). So I keep a static string to
hold
the data, building it up as data comes in.

Then I check this string for a carriage return - split the string at this
point, process the line and keep anything after in the static CString

The 'EVENT' is really the discovery of a Carriage return from the serial
port - The Time is just a way of looking for this.


Try setting up a new SDI project and just put the timer event in the View
class. Then you watch stuff come in until you get the hang on what's going
on.
You can also play with the timer interval to balance performance with CPU
hogging

Good luck





"Kahlua" <kahlua@xxxxxxxxxx> wrote in message
news:%14uj.22000$s33.11695@xxxxxxxxxxx
Where in my app would I place this checking routine?


"philip" <mfc@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:OAgp4DccIHA.4072@xxxxxxxxxxxxxxxxxxxxxxx
In my program I have a timer every 100ms that just does something like

COMSTAT ComStat ;
int characters=ComStat.cbInQue;
if (!characters) return;

if there is something I then use
DWORD dwLength;
BOOL fReadStat = ReadFile(m_digitizerFile, buffer,characters,&dwLength,
NULL);

to actually get the data

Like Scott says if you poll too often (1ms) the program just hogs the
whole processor and customers complain! But at around 100ms intervals
it
works pretty well - note: my implementation is not in a seperate thread

Phil



"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:e%23dX9zbcIHA.536@xxxxxxxxxxxxxxxxxxxxxxx
"Kahlua" <kahlua@xxxxxxxxxx> wrote in message
news:gV2uj.7748$wK4.308@xxxxxxxxxxx
In my earlier days of "Turbo C" when I wrote an aplication that uses
the serial port I did something like this.

1st I would initialize the comport and open it, of course (Com1)
I would then have a loop that checks for char in serial buffer.
I would read the char and depending on its value I would jump to
other
parts of the program
Then I would return to the loop which just sits there looking for
chars
in serial buffer.
As far as I know this is obviosly not desireable in VC++
So, my app has to be able to "watch for char in serial buffer" while
also able to react to buttons clicked on screen.
If a char enters the serail buffer I want to be able to retrieve it
and
check its value.
Everything is done within my app.
Like a large loop running.


With a Windows program you can't poll the port because your program
can
be suspended for hundreds of milliseconds, so your loop would miss
characters. The built in serial port device driver handles inputting
and
queues the input to a buffer for you.

You also have to avoid a loop continuously running, because that
steals
all the CPU time from other programs. MFC runs your message handlers
when you have an incoming message, but at all other times your main
thread is suspended. So the ideal way to handle serial input is to
input it in another thread (you will often get more than one
character)
and transfer the received data to your main thread by posting a
message
to it. I don't know if your COMDrv++ library does that for you. If
not, you will have to do that yourself.

There is a sample program and article in MSDN named MTTTY that shows
how
to do it.

--
Scott McPhillips [VC++ MVP]



Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

.

Quantcast