Detect when serial cable is disconnected

[grasspuddle]

About a month ago I was working on a project which required the pic to know when something was d/c from it through the serial connection. I failed miserably. I ended up putting in a watchdog to see if it timed out when a getc was called and d/c the cable on the pic's reset.

Now i'm curious as to anyone has tried doing the same thing and succeeded. The way I thought it out was to have the ground or any other pin on the serial cable that I knew would be always high or low when connected and poll it periodically. It never worked the way I planned, but once I did get it to recognize when it was connected(opposite of what I wanted). Probably because by connecting it, the voltage wavered.

I tried changing the pins inputs, used input(pin_a0) command and also checked the direction. What would've been the correct way?

[asmallri]

what is d/c meant to mean? Disconnected?
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[grasspuddle]

yes, disconnected

[Ttelmah]

If the RS232 transceiver being used, is working properly, 'getc', _should not_ hang on cable disconnect. Cable disconnect, should result in the pin at the processor going low, which will give a received character every character time, with a value of '0', and with the 'framing error' bit being set (since no stop bit is seen).
In the past, I have used my own check for FERR, and in the interrupt receive routine, turned off the UART, if the byte is a zero, with this bit set. Then in a timer routine, I simply read the input pin, and re-enable the UART, if the signal goes high.

Best Wishes

[grasspuddle]

thx for the fast response, I never even considered checking for stop bits. Just fooled around with the actual physical connection. That makes a lot of sense now.

[PCM programmer]

MAX232-type transceivers have a 5K pulldown resistor on the inputs
of the receivers. If the cable is disconnected, the input to the receivers
therefore is a logic zero. This gets inverted by receiver and puts out
a logic high level to the PIC's UART Rx pin. A logic high is the idle
state for the UART. The getc() function will then "hang" (wait).

The solution for this is to call kbhit() to see if a character is available
before you call getc(). Or, use the CCS function "timed_getc()", which
has a timeout feature. It's in the Examples folder:
c:\program files\picc\examples\ex_tgetc.c

[grasspuddle]

Unfortunately I have to use a software USART as the picf452 i'm using has its hardware one wired into something else. I tried to get kbhit() to work with the software one, but it never worked.

I am using a max232/3 interface so I guess thats why it does hang, thx I now understand that.

[Ttelmah]

This is actually a 'classic', that caught Dell out on their laptops.
You will find that there are really two meanings to 'break'. Detecting a cable break, or detecting a 'transmission' break. Systems using the MAX232, can only do the latter, not the former. Normally by detecting 'no data for 100mSec'. However a lot of the 'clone' chips default to giving a low, to allow detection of the former.
Now Dell elected on their laptops, to save power, by turning off the RS232 drivers, if the line stood low for a time, reasoning that with the 'Max232' approach, nobody would know the difference. Unfortunately, a lot of other systems do detect the line state, and this then causes problems (a search for Dell laptop RS232, will give an idea of just how much of a problem this is...).
I remember the designer of the MAX232, posting a while back, that he had elected to see a floating input as a 'mark' state. Some chips even allow this to be programmed.
The 'safe' appraoch, is to only ever retrieve characters inside an interrupt, or with a kbhit test first, and signal a 'break', either if the line state suggests it, or if there is a long pause in transmission.

Best Wishes

[grasspuddle]

not to totally go off topic here, BUT

Last year I did encounter a huge problem with dell laptops' serial ports. Lots of weird timeout errors and since the older laptops worked perfectly with all the software/cables the newer laptops were definately the cause. Spent days trying to figure a workaround. We were forced to use usb->serial adaptors to fix the problem. I never found out the problem, but what just said seems to describe the symptoms perfectly.

You're 2 for 2

Cheers.