18F67K40 rs232 polarity

[developer]

hi,
i use my project 18F67K40 and rs232. I change data polarity BAUDxCON register bit 4 (SCKP), but not connection and data transmission. I used last project 18F46k22 and BAUDxCON register RX and TX data polarity. but i cant see 18F67K40 RX polarity. Can you help me pls

[Ttelmah]

There isn't one.

The polarity on this chip is targeted at synchronous operation. It doesn't have a polarity control on the async receive pin. You can program a comparator as an inverter.

[developer]

"You can program a comparator as an inverter." i dont understand. how can i use comparator? can you give an example code

[Ttelmah]

A comparator gives a high output, when it's Vin+ is above it's Vin-, and a low output, when Vin+ is below Vin-. If you feed the incoming signal into the Vin- of the comparator, and program the Vin+ to connect to the FVR, then, when the incoming signal is above the FVR, the comparator output will be low, and when it is below the FVR the output will be high. Select a suitable level on the FVR, and you have an inverter, without using any external circuitry. Problem is that you lose pins.

[temtronic]

Interesting tidbit about 'polarity'! Learned something new today and I've used the 46K22 for years....
Since he needs both xmt and rcv to be inverted, perhaps an external chip is best? Something like the 74HC04 hex inverter ? Even a 2N3904 could suffice ? If a 74HCT86 quad ex-or gate was used it could be 'programmed' to invert or not. Either by HW ( pin jumper) or SW ( PIC pgm does it).

Jay

[developer]

I used it before 18F46K22 serial communication(RS232). My circuit is
receiver IC transmitter IC
RX PIN <------------> TX PIN
TX PIN <------------> RX PIN
and BAUDCON register bit4 and bit5 is polarity control. Cable order is change and PIC changed polarity control. BAUDCON.4 and BAUDCON.5. if communication is ok -> BAUDCON.4=1 and BAUDOCON.5=1, else BAUDCON.4=0 and BAUDCON.5=0. The cables are also working without sequential connections.

But i use 18F67K40 and not polarity receiver pin.
***********************************************************
SCKP: Synchronous Clock Polarity Select bit
Asynchronous mode:
1 = Idle state for transmit (TX) is a low level (transmit data inverted)
0 = Idle state for transmit (TX) is a high level (transmit data is non-inverted)
Synchronous mode:
1 = Data is clocked on rising edge of the clock
0 = Data is clocked on falling edge of the clock
***********************************************************

[Ttelmah]

First of all, get rid of the term 'RS232'. Your signalling has nothing whatsoever to do with RS232.....

RS232 is a signalling standard, using a voltage of -3 to -15v to signal a '1' and +3 to +15v to signal a '0'. The PIC does not have anything to do with 'RS232'. To work with RS232 you would need a RS232 transceiver (typically the MAX232). This driver produces a hardware inversion of the signal. Note that 0v, is actually in the undefined region for RS232.

You are using inverted TTL async serial.

It looks as if your second device is actually accepting the 'non existent' (but often used...) '5v RS232'. This is signalling which has the inverted signals required for RS232, but does not use the -ve voltages required for RS232, instead accepting perhaps +3v as the 0, and perhaps 0.6v as the 1. The PIC hardware serial is never really designed to drive this. 90% of the PIC's don't offer the ability to invert to drive this, and if you use this to talk to an external device you really should have the extra protection involved in a chip designed to have it's lines going 'off board'.

Honestly, use a buffer chip. If you must have the PIC driving it directly, then choose a PIC that does offer the ability to invert the TTL async serial. The chip you have here doesn't (the inversion is designed for use only on the synchronous clock mode - hence it's name).....

[temtronic]

As Mr T said (and me) ... use a buffer chip.
One big benefit to using a 'buffer' is that it offers a layer of protection. You don't say what the physical connection is, distance, device, environment, etc. but a buffer will take the brunt of an EMP thus saving the PIC.

It's really too bad CCS fell into the 'RS232' mantra 3 decades ago. While they should have called it '#USE TTLSIO() ", back then everyone DID use RS232 (1488, 1489) interface chips to connect to the real World, which was mostly real RS232 devices (modems, barcode readers, printers,etc.). Course back then RS232 was a 25 line connection....where 2 was xmt, 3 rcv.

Jay