PICED serial port default line states

I've been trying to get PICED to talk to my mobile phone all weekend with no success. I'm developing my logic, so I'm using PC serial ports. After much diagnostic effort I've come to the conclusion that my old Nokia 7110 does not want to talk back to PICED because PICED is not raising RTS or DTR. I've determined this by running a serial port sniffer and comparing the data from HyperTerminal (which works) and PICED (which doesn't).

I don't yet know whether this will be a problem when I eventually hook up my phone to the PAC. I suspect it won't be because I can wire the cable to loopback the control signals.

Even if PICED does not use Hardware flow control, it should raise RTS and DTR on an open serial port. Any chance this can be changed in the next release, or commands can be added to control the lines directly?

I've played with my phone's AT commands from Hyperterminal to try to make the comms work regardless of the state of the control lines, but with no success. Hopefully a breakout box will work around the problem so I can loopback DSR from the phone to RTS and DTR going back into the phone.

Thanks,
Brad.

 

How did you initialise the serial port for PICED. You would need to enable flow control along with bits, stop, parity etc.

 

PICED should use hardware flow control if you open the port that way.

Try building a "null modem with loop back handshaking" cable as described in http://www.lammertbies.nl/comm/info/RS-232_null_modem.html

A wiring diagram is attached.

 

The help for OpenSerial states that Hardware flow control for the PAC is not supported. I assumed that included PAC projects simulated under windows?

I'm pretty sure I tried turning on the flow control setting on the OpenSerial() call. I'll try it again tonight. I've borrowed an RS232 breakout box from work, so I should be able to get it working tonight and I'll report the results.

 

OK, I turned on flow control an it raises RTS but that didn't fix the problem.

To get my old phone to communicate I had to tap the high from RTS and break it out to both DTR to the phone and CTS coming back into my PC. Looks like there's two problems:

1. PICED doesn't raise DTR and my phone doesn't like that

2. For some reason my phone does not return CTS, and Windows / PICED does not like that.

My PAC solution will be OK so long as there is something high on the serial port I can route to DTR and CTS. Will either RTS or DTR be raised on the PAC?

 

The PAC does not drive any of the handshaking lines.

I think that if you use the null modem cable shown in the previous post, it will probably work fine, as long as your phone is a "DTE" device. If it is a "DCE" device it probably won't work.

 

Actually, the cable supplied with the PAC should work, as the handshaking lines are looped back within the PAC, as shown in the attached diagram.

 

Darren,

I think the PAC is only shipped with a USB lead. Are you referring to the serial lead provided with the CTouch B&W.

I have made a heap of different cross / serial leads to work with various pieces of hardware.

Question 2 would you clasify the PAC as DCE or DTE ??

 

You are quite right. I was referring to the black and white C-Touch cable.

As Ashleigh says, these terms are a bit misleading and imprecise. The PAC definitely isn't a DCE device, so by an extensive process of elimination, I have concluded that it is really a DTE.

 

I suppose it comes down to whether you consider the PAC gives or takes. I would have definitely thought DTE. A lot of standard reference re wiring illustrates connections between DTE and DCE devices, however, you chaps are right - the result of which is not always definitive.

 

I might be stuffed as it look like my phone doesn't raise any control lines back (DSR, CTS), and PAC doesn't raise any lines so I've got no 'high' line to tap into and bridge to DTR like I do when testing connected to my PC. Without DTR high, my old Nokia 7110 does not communicate. Possibly the serial interface is powered off DTR being high. I'll have to look at some external electronics to provide a signal to DTR for the phone.

In the future will PAC be able to assert control lines or is the hardware capability just not there?

Thanks for your assistance.

 

The hardware is not there. If you look at one of the diagrams I posted, you will see that the handshaking lines are just looped back internally.