Re: Serial Interrupt

On May 21, 1:03 pm, "Dick Grier" <dick_grierNOSPAM@.msn.com> wrote:
The
standard UART does not allow you to set the parity bit separately from data.
Rather, parity is calculated by the UART hardware, and the bit is set by the
hardware. The UART does not support 9-bit data (which really is what most
protocols that use parity bit sync assume).

Some UARTs do in-fact support 9-bit communication although it is not a
very common option or feature. Additionally, all of the 16550 UARTs
that I've dealt with have support for both setting and getting the
parity bit (even if it's not strictly part of the standard 16550
driver.) This may be simply because the UARTS "support" the 16550
interface but allow for more feature via vendor specific registers
etc...

So... Even with a device driver modification, you'd also have to calculate
the actual parity (bit) required, and to set that parity immediately prior to
sending the associated byte. Similarly, on receipt, parity is not a
separate bit, but is indicated by an error bit in the status register.

What you want to do (probably) is possible, but I suspect that you will have
to disable both the transmit and receive FIFOs, and process data
byte-by-byte.

On some UARTs you can actually leave the Hardware Fifos enabled, I
know on one of the ones that I dealt with you could leave at least the
Rx Fifo enabled. Whether the Hardware fifos can be enabled really
comes down to the specific hardware in use. As Richard mentions, many
hardware platforms do require that the Fifo's are disabled as they are
only able to notify you of a single parity error.

My experience with writing these drivers is that it was simpler not to
implement a standard serial driver, but rather a Stream Driver for the
device. This was because our specific requirements did not require
the Serial Port to operate with other devices or require support for
all of the serial features. Depending on your specific requirements
you could also possibly save some time by simply writing a Stream
Driver.

Before you spend too much time trying to modify an existing solution I
would do the following:
1. Verify this is possible with your hardware.
2. Verify that you can still get enough information out of the
Standard Windows Serial Interface for your particular design.
3. Verify whether it makes more sense for your system to Implement the
Standard Windows Serial Interface or a custom Stream Driver Based
design.

Regards,
Brad.
.