Monitoring two serial ports

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello.
I am trying to produce a pc-program that can monitor the rx-pin of two
serial ports.
(My own little port-analyzing application!)
Everything works fine, except that there seems to be some timedelay from the
moment the bytes arrive to the port, and to the moment my application can
read them.
This means that I cannot timestamp the arrival of the bytes accurately.
I tried both approaches in comport handling; event driven and polling...no
luck.

Perhaps I need to be able to set the rx-trigger level in the 16550 uart to 1
byte - but if thats the case, I dont know how to.

Can anybody help me, please?
 
I found a way arond the problem.
The solution was to read each port until its empty, and NOT read one byte
from portA followed by reading one byte from portB etc.
My receiver thread (polling based) now looks like this:
//*******************
private void ReceiveThread()
{
byte AVal, BVal;
bool keepon;

while(true)
{
keepon = false;
while(ReadBufferA(out AVal))
{
if(CurrentChannel != 'a')
{
CurrentChannel = 'a';
if(++WIndex >= monBufSize) WIndex=0;
MonBuf[WIndex] = -1;
}
if(++WIndex >= monBufSize) WIndex=0;
MonBuf[WIndex] = AVal;
keepon = true;
}
while(ReadBufferB(out BVal))
{
if(CurrentChannel != 'b')
{
CurrentChannel = 'b';
if(++WIndex >= monBufSize) WIndex=0;
MonBuf[WIndex] = -2;
}
if(++WIndex >= monBufSize) WIndex=0;
MonBuf[WIndex] = BVal;
keepon = true;
}

if(!keepon)
Thread.Sleep(1);
}
}

where the ReadBuffer() - contains the ReadFile() - p/invokes.
 
Hi,

No.

The simple fact is that there is no real-time access to serial data (or any
other resource) under Windows, much less subordinated by the Windows serial
driver and the classes that implement the framework. Also, realize that the
standard PC UART implements a 16-byte receive FIFO (and some other
hardware/software devices even deeper FIFOs). The processing of the
receive FIFO is interrupt driven, but also is processed by timeouts at the
diver level.

YOU can set the rx-trigger level to 1 to improve this, but not to eliminate
the timing issues.

Also, if you depend on the DataReceived event, you are relying on a
Background (worker) thread for notification from each port. There is no
assurance of which thread will be processed first. You CAN poll, instead of
using DataReceived -- but even this process offers no guaranty.

The only way to tackle this with any assurance is outside the relm of
managed code. It would involve a laborious process or writing your own
serial device driver to do the time-stamp for you at a much lower level.

From managed code, the best that you can do is to get "sorta close." BTW,
your second post illustrates this. If that is good enough, then, OK.
Problem solved.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.
 
Back
Top