mscomm in vc++ - parity error

Hi,

I'm writing some logging software for an embedded alarm panel design that uses an RS485 bus and proprietary protocol. I've attached the obligatory RS485 -> RS232 converter and connected to a free serial port on my PC. All good so far!

Now, the alarm panel deliberately causes a parity error on the header byte of all packets transmitted on the bus. This parity error is used by all peripherals on the bus to sync to the header byte. Fair enough say I (doesn't sound a great idea but who am I to complain).

Here's the problem... I'm using the mscomm32.ocx control in my VC++ application (used lots of times before with no problems). I have parity replace turned-on at the moment so that all parity errors are substituted with a custom character. When a header byte comes in (and a parity error is detected), this seems to cause the mscomm control to stop. Not good.

I've googled and only found answers for VB. None for VC++. The VB answer I've found does not work in VC++.

Has anyone ever come across this in VC++ and knows how to reset the error WITHOUT turning mscomm off then back on again (looses data doing it this way - I've tried it!).

Cheers Jim

Reply to
Jim
Loading thread data ...

mscomm32.ocx is a wrapper around the standard win32 libraries, if you want complete control, then you are going to have to get away from mscomm32.ocx. Hit codeproject for plenty of good examples.

Reply to
The Real Andy

Hi Andy, Done that. Been there etc... There are several reasons why to use mscomm.ocx the main one being that I've written loggers in the past and have classes all ready to re-use, that use mscomm. I was trying to find out how to do something in VC++ that can be done in VB (VB uses Er.clear or something like that). Reason??? - Well, not only do I have this new logger to write BUT I have a number of other loggers out there with the same code. That is, bugged code!. If I get a real parity error my logger is going to stop. I guess if the answer is not out there then yes, I'll need to go a bit closer to the bone. Code project, Code Guru etc. All have other serial classes available - along with the associated bugs. I'd just 'rather' use the tried and tested mscomm.ocx.

Thanks for your input Jim

Reply to
Jim

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

Reply to
Paul Keinanen

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.

Thanks for the input guys. Much appreciated. Jim

Reply to
Jim

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
 Click to see the full signature
Reply to
Tauno Voipio

Snip:

You are not that free to move if you stick to mscomm . You can write your own wrapper for serial port and i would suggest to make it a loadable module (dll) so it can be integrated to any application (VB , VC etc.). Have a look at

formatting link
code and you can convert this class to dll with little effort.

ali

Reply to
Ali

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.