Can anyone help me find a way to make a PC talk to a whole bunch of uC chips. I have built a RS232 - RS485/RS422 converter. I want to use the "serial address mode" of the '51 (Pic has it too) to reduce sw overhead.

It basically uses a 1 start, 8 data, 1 parity and 1 stop bit. To address a uC, you set parity to 1. All uC get a serial interupt when they receive that, check if they are adressed and if so change a setting to be interupted by all incoming bytes.

My problem is to handle sending from the PC. I need to set parity to 1 (mark) for the first byte in a message, then reset it to 0 (space) for the rest. I XP you never know when the data is sent and waste a lot of time waiting to make sure it is all gone. There is a replacement XP driver (Nielsen) out there, but I do not have the cash for it. Any other ideas?

The PC is the only master in the system and will only receive data in the data mode when it asks for it.

Hope you can help

Andre

 

This is not as difficult to achieve as it seems to be. How familiar are you with Windows API? You can access the communication port through Windows API and, specifically for serial port, there is a feature to set the parity bit to anything you want (even, odd, mark and space).

Have a look at MSDN, especially the Communications Reference in Windows API and how to set up a DCB.

Windows can be pretty complicated to program, especially if you are straying from the normal paths, that is requiring something different than what others usually do. If you encounter any problem in implementing a feature in Windows, then I would say the first call would have to be MSDN. You could do a lot of things with Windows API, although they are not that intuitive or easy to work with.

 

Yep, been there, Thats how we got it working in the first place!

BUT the problem is throughput: As you have no way of knowing when the data has actually all left the serial port, you have to wait at least one byte time plus a bit more for good luck before changing the parity bit and then wait a bit more before sending the data. It makes for sloooooowwwww and klunky code and communication.

The Nielsen serial.sys driver ceates a now serial mode and handles the sendstring just the way such a system needs it: First byte parity set, the rest reset.

Any other ideas as how to handle things - our harware is our design and very far from cast in stone, so if we have to do a few hardware changes to handle new changes, we will do so with pleasure.

Thanks a lot for the info so far.

Andre

 

You are right in that windows does its own thing in processing and sending the data. Mostly, this is controlled by the flow control and timeout value. I have, however, never encountered any problem with a long delay between data transmission, which should be expedited quite quickly in normal operation. Serial link is _far_ slower than what the processor/windows could do, so the bottleneck here is not in windows driver or the PC but actually the link itself. You should check on how you do your things and find out where the real problem is.

There are ways to poll when the data has actualy been sent, you could check the buffer or purge it, which would wait until the buffer is emptied through the link, or you could use overlapped event in writing to the handle.

You could also put a higher priority by using TransmitCommChar, but this would not solve your waiting problem. What you should do is look into how windows handle I/O and modify your program/approach to fit the scheme. You shouldn't use any fixed time waiting period, that is asking for trouble. Let windows does its own thing and check when it is done, that is mostly how it works for the best throughput.

If you decide that this is not your cup of tea, then you could always do the addressing externally. Put a micro in your 232-485 converter and devise a protocol with standard transmission between the PC and the converter. Let the converter does the parity addressing according to the PC control. This, however, wouldn't solve your transmission waiting time problem.