Serial Ports in DCE Mode?

[SMurf]

Hello,

I wonder if someone with a bit of serial port programming experience would riddle me this: recently it popped into my head that I would like to have a go at making some hardware, essentially a PIC project that controls a few (looking at 4) serial ports.

However, given that I know very little about PIC programming and loads about Windows programming I would like to be able to prototype the software design on my computer. Fortunately my computer does expose 1 serial port, and if I'm that fussed I can buy a PCI card for some more.

The idea behind the hardware is that you use a straight through (DCE-DTE) serial cable to connect to it, like a modem. What I would like to know is, can you change (with the aid of a gender bender) the working mode of a computer serial port from DTE to DCE? Would it involve changing the driver or is there a way that you can raise signals directly on a COM port?

For the purposes of designing this hardware I need to be able to raise the DSR signal. In theory by connecting the port to another normal port on the computer I should be able to work on the design no probs.

I've tried looking for an actual PCI serial port card that lists this in its abilities but it's either ambiguous or costs about £400.

[SMurf]

Some furious searching later, I have learnt that the Super I/O chips that are used on modern motherboards stick to the IBM PC standard and are hardwired to take input from the DSR, RI, CTS, DCD lines (there is no way to get the hardware to change their state). This is also true of the reasonably-priced PCI cards, the reasoning presumably being that the RS-232 standard explicitly defines a computer as being DTE (if someone made a product that provided DCE ports they would be breaking the spec).

Looks like I'm stuck with the massively expensive PCI/USB card options, which basically feature a CPU with RAM to supplement the one that's controlling it...

Does anyone know of a product that will provide me with DCE or software selectable DCE/DTE serial port?

[jimblumberg]

Hello,

I wonder if someone with a bit of serial port programming experience would riddle me this: recently it popped into my head that I would like to have a go at making some hardware, essentially a PIC project that controls a few (looking at 4) serial ports.

However, given that I know very little about PIC programming and loads about Windows programming I would like to be able to prototype the software design on my computer. Fortunately my computer does expose 1 serial port, and if I'm that fussed I can buy a PCI card for some more.

The idea behind the hardware is that you use a straight through (DCE-DTE) serial cable to connect to it, like a modem. What I would like to know is, can you change (with the aid of a gender bender) the working mode of a computer serial port from DTE to DCE? Would it involve changing the driver or is there a way that you can raise signals directly on a COM port?

For the purposes of designing this hardware I need to be able to raise the DSR signal. In theory by connecting the port to another normal port on the computer I should be able to work on the design no probs.

I've tried looking for an actual PCI serial port card that lists this in its abilities but it's either ambiguous or costs about £400.

You could use a null modem cable. But most PIC projects will only use 3 wires (Tx, Rx, Gnd) so you could make your own cable that connects PIC Tx to PC Rx, PIC Rx to PC Tx, and ground to ground. You might also want to check out Serial Port Central (Jan Axelson's Lakeview Research).

Jim

[cyberfish]

You could use a null modem cable. But most PIC projects will only use 3 wires (Tx, Rx, Gnd) so you could make your own cable that connects PIC Tx to PC Rx, PIC Rx to PC Tx, and ground to ground. You might also want to check out Serial Port Central (Jan Axelson's Lakeview Research).

Not quite. RS-232 is -12V to 12V, PIC is CMOS/TTL (0V-5V). You'll need something like a MAX232 chip to do the level translation, otherwise something will blow up.

As for the original question -
Do you really need the control wires? They are almost never used with microcontrollers anymore, because both microcontrollers and computers have become fast enough to really not require hardware flow control.

Without hardware flow control, you'll just have to connect Tx to Rx, Rx to Tx, and ground, and either disable hardware flow control, or use a few loop-back wires to trick the ports into thinking the other side is always ready.

Probably easier to just do it on the PIC.

[SMurf]

To be honest with you I have now settled on using a null modem cable, having searched in vain for an economical DCE add-on interface (who'd have thunk that adding support for 5 inputs instead of 3 would be such an impossible challenge?)

This hobbyist development isn't really about industry practice, more that I would like to learn and understand the "why" behind serial interfaces. Actually having the control lines do the job that they were intended to do would add an extra dimension to what I have read from Wikipedia and other sources.

Virtual serial ports are surprisingly buggy when it comes to more than simple bit-banging.

The best I can hope for is to wire my null modem interface to map DTR to DSR/DCD and RTS to CTS, that way there is at least a simulation of the way actual comms hardware works.

You're right about it being easier on the PIC though, Windows has never been great for this sort of thing...

[cyberfish]

Well, microcontroller UARTs (Tx Rx pair) don't have hardware flow control (anymore, maybe they used to, I don't know), so it will be useless when you finally port it over to the PIC.

People have gotten creative with the flow control pins, though.

For example, many people use the RTS pin to reset microcontrollers. This way, you can use software to reset the microcontroller before flashing (vs having to press a reset button). Basically using them as a few general purpose pins.

[cyberfish]

Actually, I don't know what I was smoking, but of course the UART won't have flow control (because it should be determined by your code when it's ready!).

If you want to use hardware flow control with the PIC, you'll just have to connect them to general purpose IO pins (through a MAX232), and read from/write to them appropriately, following the protocol.