Re: mscomm in vc++ - parity error

Jim wrote:
"Paul Keinanen" Wrote:


I don't know what mscomm.ocx is, but if you are willing to use C and
the Win32 API, you should call ClearCommError after each call to
ReadFile. ClearCommError reports the possible error condition before
clearing it and allowing more input to occur. You may have to
manipulate the DCB with Get/SetCommState APIs to activate the
fAbortOnError feature.

I don't know how well the Windows driver implements this, but in
general trying to receive those 9 bit bytes (with the high bit as the
address indication) using the parity error detection on ordinary 16550
family UARTs can be problematic if the Rx FIFO is enabled. If there
are several unprocessed bytes in the FIFO when the parity error
occurs, the parity error interrupt is generated immediately, so it is
hard to say, which byte actually had the parity error.

Only the received bytes are queued in the FIFO, but the error bits are
not queued with the received byte, since the error registers only
represent the status of the current received character.

To avoid this kind of problems, the Rx FIFO should be disabled, thus
interrupts would be generated and processed for every character and at
the same time the error registers should be read to see if the current
character contains the parity error.

Paul



Nice one Paul ! I had completely forgotton about that (FIFO needs to be off). Not at my work PC at the moment so I'll check when I can.
As it looks like its not possible to do some things in VC++ with mscomm, that can be done in VB (my VB workmates will have fun laughing at this one for ages I can just see it :-( ), then I guess I'm going to have to use a less tested method. Never mind.


It seems thet your panel is using what Intel calls uLan: there are
normal eight bit characters with a ninth bit added. The ninth bit
is used to signal a special character (frame start, frame end etc)
when an one. The Intel hardware (e.g. i82510, the 8051 family) has
an extra interrupt source from the ninth bit, so that the processor
can wait on it instead of scanning the bit stream passing by.

The standard PC serial chips (NS 8250 with derivatives) have a bit
called stick parity, which can be used for implementing the uLan
functionality. AFAIK, the Windows drivers are not able to use it.

--

Tauno Voipio
tauno voipio (at) iki fi
.

Relevant Pages

  • Re: mscomm in vc++ - parity error
    ... the Win32 API, you should call ClearCommError after each call to ... ClearCommError reports the possible error condition before ... family UARTs can be problematic if the Rx FIFO is enabled. ... are several unprocessed bytes in the FIFO when the parity error ...
    (comp.arch.embedded)
  • Re: mscomm in vc++ - parity error
    ... family UARTs can be problematic if the Rx FIFO is enabled. ... are several unprocessed bytes in the FIFO when the parity error ... represent the status of the current received character. ... the same time the error registers should be read to see if the current ...
    (comp.arch.embedded)
  • Request for comments - kgets()
    ... macro and a function-like macro macros below) ... pointers, dereferencing pointers, pointer arithmetic, and how (at ... character by character I can discuss a conceptual model of the ... FIFO Model - A block of memory having two pointers. ...
    (comp.lang.c)
  • Re: reading on serial port slow...
    ... FIFO has some characters waiting but no new ones have arrived ... IIRC "a while" is a few character times. ... the port to signal an interrupt after each character. ...
    (comp.os.linux.development.system)
  • Re: reading on serial port slow...
    ... the FIFO has reached a certain fullness or the FIFO has some characters ... waiting but no new ones have arrived for a while. ... to signal an interrupt after each character. ...
    (comp.os.linux.development.system)