Unable to detect a parity error with Windows SDK on a PCI serial card
Data warehousing applications, DataCenter, Development, Microsoft Windows, Network applications management, Network management software, Network protocols, Network testing, Networking, Performance management, Protocol analysis, standards, TCP
We are using a 9-bit protocol which sometimes sends a mark state and sometimes sends a space stage. When a space state is sent we want to be able to get a parity error in SDK. We can see the parity error in the hardware register but we want to be able to see the error with Windows SDK software. When we connect to a standard 232 serial port on a PC we are able to see the errors in SDK but when we add serial ports with the PCI card we are having unable to see the parity errors with the SDK software from Windows.
- We are using the OVERLAPPED I/O functions from the windows SDK.
- Parity errors are not detected by the driver. When using the SDK function "ClearCommError", we get no parity errors in the status flags.
- The characters are received very slow. When sending for example +/-25 characters at once. It takes about 500 milliseconds, before the driver has given the characters to the windows SDK. When sending a lot of data we detected delay's of more than a minute. And no, this has nothing to do with the limited baudrates. When disconnecting the serial cable, we still receive data from the serial port for more than a minute. Please check yourself using the OVERLAPPED I/O functions of windows.
We get the impression that the hardware is OK, but the driver has bugs in it. Any ideas?
Thanks
Kelly
Software/Hardware used:
Software/Hardware used:
ASKED:
June 1, 2006 2:26 PM
UPDATED:
June 6, 2006 6:37 PM
Answer Wiki:
Windows - or "my hardware is NOT real!" In DOS (Disk Operating System) the hardware was real and used a limited number of interrrpts to set flags that were readable and resettable directly by programs. In XP, and to varying degrees all the way back to '95, Hardware is 'virtualized' and NOT directly accessible. This means that interrupts are recognized and processed by 'Windows' and messages passed up to the programs. The virtue of 'Overlapped' I/O is removal of timing requirements and enhanced system stability, the downside is 'NO direct access'.
Decision time - If you want XP stability and multitasking then adjust to a 'virtual hardware' reality. If you have to have direct hardware interaction, then run DOS or some of the third party interfaces that gain direct control at the expense of multitasking and accept the crashes you will have. RTOS (Real Time Operating System) can do what you are attempting but it is NOT Windows and does not want to be.
The more you want 'Windows' with multi-tasking (e-mail AND Internet AND Word Processing) the less tolerant of 'bit-twiddling the system can be.
To see all answers submitted to the Answer Wiki: View Answer History.
That’s Windows multitasking, because there is so much overhead and hardware abstraction in the NT line of Microsoft operating systems. “Getting with the program” does not necessarily mean that one has to hobble his or her self with the restrictions imposed by control freaks at one operating system vendor.
There are many systems out there that are ideal real-time serial interfaces, but NT-based operating systems are not among them. Custom drivers can be acquired, but at a cost, and they still must deal with the Windows overhead and other negative aspects of how Windows controls access to devices and does its multitasking.
QNX, UNIX, Linux, RTOS, PalmOS, FreeBSD and several others all permit direct access to the serial ports of your hardware.