Problems with Asyncronous Communications

[BertMan]

Background:
I have "device A" that consists of a sensor, a pic, a max232, and a pc. Device A was intended by the manufacturer to connect directly to the pc and interfaced with hyperterminal.

Goal:
What I want to do is remove the pc component and put a pic in its place. The pic would send commands to device A, and device A will respond back to the pic.

Problem:
I cant get communications going between the pic and device A.

Observations:
I have put numerous debugs inside the program, and have come to the conclusion that the data from the pic is not being interpreted by device A. I have also put a scope on the output of device A and see no activity.

Questions:
Since device A is using a max232, I used true form instead of inverted. But this is confusing because I am not sending data to a max232, I am receiving it. So do I still use true form?

Example code:
SerOut2 M50_OUT, 16416, [66] '16416 = 19200 baud/true. 66 = ASCII B
'An ASCII B tells the M50 to send data
SERIN2 M50_In, 16416, 500, Main, [test1, test2, test3, test4]
'Four bytes are received from the M50

[BertMan]

Also, the pic I am using is a 18f2520 which has an onboard hardware UART. Is there any advantage to using this and HSEROUT over the software method?

[arniepj]

First check your cable/connector connections to be sure tx goes to rx in both directions.Ususally pin 2 to 3 and 3 to 2.I would troubleshoot the pic code connected to a pc first,since you can monitor the output of the pic,plus send data to the pic.

[BertMan]

RX and TX are fine and I am connected to a pc for debugging. I am still having this issue if anyone can help.

[BertMan]

Here maybe a pic will help. In this situation, would data between 182520 and max232 be inverted or true? I do not have access to the code on the 16f84 on the Micro 50, but I would assume it would be true because it was intended to communicate with a pc and it has a max232 in between. So then it would be safe to assume that data is inverted on the other side of the max232. So then if I am trying to connect a 18f2520 to the side that the pc would normally be on, then data would be inverted... correct?

[Charles Linquis]

TTL <-> RS-232 level shifters invert in both directions. It is normally assumed that you will use such a device, so the setup when you use one is call 'TRUE' in PBP lingo.

Inverted mode is necessary when no level shifter/translator is used, like when you connect a PIC directly to the serial port of a PC (but please put a resistor in series with the TxD line of the PC!)

When running in TRUE mode, the output/input of the PIC will be high when in the idle mode, and pulse low when sending/receiving bits. Of course, it will be of opposite polarity on the "far side" of a MAX232.

I see in your example code that your are writing '16416'. This number would indicate that bit 14 is set - meaning that you are sending INVERTED. To send/receive in TRUE mode at 19.2Kbaud, this number should be 32.

If you are "talking" this fast, your PIC should be running faster than 4Mhz.

Also, are you certain that you have your TRIS register set for output on the transmit line, and input on the receive line?

[Bruce]

With the 18F connected to the RS232 output of the MAX232 from the MICRO 50 board, you should insert a series limiting resistor (like shown in your PBP manual) for a direct RS232 serial connection, and use serin, serin2, debugin etc with inverted mode.

Some of the "A" version 14-bit core, and the majority of the 18F series will flat out refuse to work with direct RS232 level voltage applied to an input pin.

The best option is to just toss in another MAX232 converter. It can/will save you a ton of time & trouble. Some of the 14-bit "A" versions refuse to work even with the old series limiting resistor trick.

You can use the 18F's hardware USART with HSERIN/HSEROUT if you use another MAX232 IC (or equivalent inverter circuit) on the 18F side.

18F true mode: Can use any serial command or hardware USART
18F tx > ttl in >|max|> rs232 out >--> rs232 in >|max|> ttl out >--micro 50
18F rx < ttl out <|max|< rs232 in <--< rs232 out <|max|< ttl in <--micro 50

18F inverted mode: serin/serout, serin2/serout2
18F tx > -----------> rs232 in >|max|> ttl out >--micro 50
18F rx < --/\/\/\----< rs232 out <|max|< ttl in <--micro 50

Check the MICRO 50 board docs also to see if it requires handshaking. If you're not seeing anything output by the MICRO 50 board, it may be waiting for a control byte or handshaking signal before transmitting.

And as Charles already mentioned, be sure to use an oscillator that supports the data rate.

[BertMan]

Thanks!! I am starting to see data now coming from the M50 now that I added a pull down resistor to the output. Still not getting valid data though. I will take your advice and use another max232. I will let you know how it goes. Thanks for the help.

[BertMan]

Sorry, one more thing. I am using the internal 8mhz clock for testing purposes. Is this fast enough to keep up with the 19200 baud?

[Bruce]

8MHz should work at this data-rate, but take into account that the iinternal osc can/will drift - so and it's not the best option for timing sensitve things like serial data exchange. A crystal is by far the best option if you want repeatable results under varying conditions.

Temperature changes will cause internal oscillator frequency drift & loss of communications/data. You have the option of tuning the internal osc to compensate for freq drift, but it's more of a pain than it's worth in my opinion.

[BertMan]

Got it working! I decided to use a max232 and have been scratching my head as to why the pic still wasnt picking up the serial data from the micro 50. The resolution included taking a DEBUG statement out that was between the SEROUT and SERIN commands. I am hoping everyone has made this mistake before so I dont feel like a complete tard. Thanks for all the help.