Re: Serial port monitoring

Tech-Archive recommends: Speed Up your PC by fixing your registry

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]




.

Quantcast