Serial communication between two 16F877As

Hello all.

I am using PICBasic Pro to program two 16F877As that are cross linked via portb.4 and portb.3. On both MCUs i am using portb.4 as the TX pin and portb.3 as the RX pin. Using the serin2 and serout2 functions, i have been able to transmit data through a max232 converter to the PC with no problem whatsoever. I even have it working wirelessly through Linx Technologies' ES Series RF modules, which is what i want to be using when all is said and done.

However, going from PC to MCU is a different story. At first I tried that to see if the PIC could read information by waiting for the ascii string "start" and then lighting an LED. I sent the string through LabVIEW, and I know it works correctly because of a few tests i did. It only lights when I send about 20 "start"s over the TX line in rapid succession. I then configured another MCU to 'talk' to the previous one, hard wired as described in the first paragraph. Again, this works intermittently.

I find it strange that with no hardware changes the PIC can transmit data correctly to the PC, but the same data cannot be read by another microcontroller at the same baud rate and settings. My feeling is that the controllers are becomming out of sync, even though this is asynchronous serial communication. If anybody has any suggestions or comments or questions please let me know. Thanks in advance!

Cameron

could be tons of things, i would suggest you to post your both code here.

ok so im going to answer my own question. i know how to code for the most part, and these are simple programs, so that wasnt the problem. however, i cant seem to find the file that shows me how serin and serout, as well as the other functions actually work, so they are still mysterious to me.

hardware is something that can never be thrown out as the source of the problem, but i checked that over and over again, and that was fine. the only thing i didnt do when hard wiring the pics together was to lay a common ground. once i did that poof, they were great. however the wireless link still did not function properly.

using an oscilloscope i looked at the incoming data on the RX pin. it was all there, just as it always had been. i switched boards and looked at the the outgoing data. the 'normal' state of the TX pin is high, opposite of the RX pin on the other end of the link. what could have caused this? i still havent figured out what the root of it was, but that was the problem. the solution: use inverted data with the serin and serout functions. this drives the TX pin low normally, sending the data accross the wireless link exactly as if there was a wire there.

if anyone wants to enlighten me as to the reason the TX pin is high normally that would be great. could have been an internal pullup because i am using portb.4, but i thought those were disabled on POR. could be the way serin "true" works, which is why i like to know how the functions work, not just what they can do.

Cameron

Hi Cameron,
I wasn't sure whether you were using the rs-232 still but these invert the signal as well as increasing the voltage to 12V. Could this be your problem?

Mike

Mike,

Since I now have communication between two microprocessors, i have no need for RS232 communications anymore. However, when they were being used before, the logic levels were stepped up using a MAX232 IC included in the dev board i am using, so that was taken care of for me.

The problem was that for some reason serout2 leaves the TX pin high at the end of whatever you are sending, at least when using driven true modes. I ended up just using driven inverted modes, and it seemed to alleviate the problem. However i do not know WHY it did so. Knowing WHY is like being taught how to fish. Knowing that it solved your problem is like being given a fish.

Cameron

RS-232 idles in steady MARK. The start bit is a SPACE bit. After the character has been sent the stop bit(s) are again MARK. MARK is defined as a negative voltage and SPACE is a positive voltage at the high level RS-232 interface.

The MAX-232 chips are inverters. In order to get a steady MARK after the character, SEROUT2 is doing the right thing and leaving the TTL line out of the PIC as a high (5V) level.

In order to get the correct state BEFORE sending a character with SEROUT, I find it pays to "condition" the line by setting the serout pin HIGH with a PAUSE longer than a character duration.

HIGH SeroutPin
PAUSE 10
SEROUT pin, mode, [data,data,data, etc]

HTH
Brian