how to implement 9-bit communication under C#.NET & Win32

I've been trying desperatly for the past couple of weeks to implement a 9-bit protocol (a.k.a multidrop) under c#.

just to make clear:
bytes under the protocol are 8 bits, where the first byte of the packet has a parity of 1 (Mark) and addtional bits have the parity of 0 (Space).

writing packets are the easy part, simply setting the parity for each byte.

reading the packets is the problem and here lies my problem:

.NET SerialPort class only signlas that there was a parity error, but not in which bit it was occured. Only closest solution is to use the ParityReplace member - which causes 2 new problems: first byte information is lost and we have no way of identifying whether it is the first byte or a part of the information.

I turned to importing kernel.dll functions such as ReadFile/WriteFile which .NET SerialPort class implements under the hood. The reasonable solution is to use the Space parity settings, set fAbortOnError flag to true, so when a byte with the 1 (Mark) parity bit will be recived, communication will stop until i'll renew it - and so it works.

So what's my problem?

Appearantly, bytes I have yet to recieve, are stored in an internal win32 buffer which only saves the 8-bit data and not the parity bit along it's side. So when my program is dealing with other matters, every byte - whether its parity is 0 or 1 - is inserted to the buffer, causing to the program to read more than a packet length.

consider the code:

while (true)
{
WaitCommEvent(mFileHandle, out comEvent, IntPtr.Zero);
ClearCommError(mFileHandle, out errors, out comstat);
ReadFile(mFileHandle, tempBuffer, cMaxPacketSizeInBytes, out actualBytesRead, IntPtr.Zero);
}

I configured the port to wait for a parity error (mask = parity event).

WaitCommEvent waits for the first parity error to occur (first byte of the packet is 1), ClearCommError releases the closest error and ReadFile (Should) read until the next error (Parity 1 when expected 0).

however ReadFile gives me ALL of the recieved bytes = 15 packets where I made sure to send them with the first byte Parity Marked.

I have scanned the web desparately and I KNOW there is some solution to this other then reprogramming serial.sys driver as there are software packages who implement this protocol.

any help will be most appreciated.
gilzuAsked:
Who is Participating?
 
gilzuConnect With a Mentor Author Commented:
Solution documented here: http://gilzu.com/?p=6
0
 
Dave BaldwinFixer of ProblemsCommented:
Here's an article from National Instruments that tells how to do it: http://digital.ni.com/public.nsf/websearch/3BDC7FF03541F772862564990057F919?OpenDocument

The problem is that 9-bit communication is not natively supported in PC uarts like the 8250/15550 and the clones.  Here is another page showing uarts and chips that do natively support it: http://rs485.bocc.de/rs485_desc1.htm
0
 
gilzuAuthor Commented:
Thanks for the reply, however:

link 1: discusses what i've already said and the solution i tried which failed due to the buffer. it also uses Labview and not .NET.

link 2: solves it by hardware, I'm looking for a software solution as i dont intend to build a special microcontroler
0
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

 
Dave BaldwinFixer of ProblemsCommented:
The software solution on a "modern PC" probably requires you to bypass the Windows serial port driver and write your own that can manipulate the bits.  And it's one byte at a time.  You can't use the buffering because then the 9th bit won't track with the correct byte.  In the 'old days', we used to use a Zilog 82530 chip for this because it had the hardware built in.  Sealevel Systems still makes such things http://www.sealevel.com/store/serial/synchronous-serial/pci.html but they've gotten very expensive.
0
 
gilzuAuthor Commented:
As far as i've gotten through searching the web, some threads end with suggesting to get the Rx FIFO buffer to 1 or to keep a hi-priority thread that will keep pool bytes from the serial port.

none which i've been able to achieve
0
 
Dave BaldwinFixer of ProblemsCommented:
Glad you found it.
0
 
LeeTutorretiredCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.