Can't reliably transfer over serial connection between two PICs

[CuriousOne]

Hello.
Having a strange issue.

PIC18F45K80 and PIC16F1936.

they are connected to each other via 22K resistor. PORTC.3 on both.

Trying to run the simple code:

TX: (1936)

barka:
serout2 portc.3,84,[345]
pause 100
goto barka

RX (45K80)

taka:
serin2 portc.3,84,[x]
if x=345 then stop
lcdout $fe, $c0, "X=", dec x, "    "
goto taka

It does not work, it never receives "345". received value is always random, but quite often it is 89.
Variable types are proper, port configs also.
I tried to change direction and send from 18F to 16F - same issue.
Checked signals with scope - no issues.
Tried to various resistors - 1K, 10K, 22K - no difference.

Yes I know that hardware port should be used, but PCB is already made.
Distance from one chip to another is about 10 centimeters and they're both on the same PCB and same power supply. I've checked signals with scope and there are no issues, like low levels or noise.

I tried to make code more complicated, like sending 8 characters + control character (enter) -this improves it a bit, might say that at least one try from 10 delivers proper result. Sometimes, it starts to work fine, but then again messes up. Also tried reducing port speed to 1200bps - no change.


Any ideas?

[Ioannis]

1. How can you be sure that the receiving PIC will start "listening" just before the sending PIC? Better use a start character on the sender and use this character as a WAIT one on the receiving PIC to synchronize both.

2. How is variable x defined? BYTE or WORD? 345 is more than a BYTE can store. 345 in Binary is 101011001. So if x is byte, it will randomly store 01011001 which happens to be, guess what?
Exactly 89...!!!

Ioannis

[CuriousOne]

Yes, X is word type, and it sometimes get values over 8 bits, but never 345.
I tried sending lower numbers, like 4 or 16 or whatever - they also got distorted.

I also tried like this:

arraywrite textline, ["ABCD1234"]serout2 portc.3,84,[STR textline\8,13]

Sometimes whole string is delivered fine, sometimes it is all garbled.

As I understand, you suggest to use WAIT/WAITSTR statements?

Meanwhile, by help of AI, this crude bit-banging "protocol" was developed. By hand tuning PAUSEUS values, it works, but I'd prefer "factory" solution if possible.

Sender:

Main:
    FOR TxValue = 0 TO 254
        GOSUB SendNumber
        PAUSE 300      ' Wait before sending next number
    NEXT
    GOTO Main


' --- Subroutine: SendNumber ---
SendNumber:
    ' Start bit (LOW pulse)
    LOW DataPin
    PAUSEUS 500
    HIGH DataPin
    PAUSEUS 500


    ' Send 4 bits (LSB first)
    FOR BitMask = 0 TO 7
        IF (TxValue >> BitMask) & 1 THEN
            HIGH DataPin
        ELSE
            LOW DataPin
        ENDIF
        PAUSEUS 500
        HIGH DataPin                 ' Return line HIGH between bits
        PAUSEUS 500
    NEXT
    RETURN

Receiver

Mainx:
    ' --- Wait for start bit: must see line LOW ---
WaitForStart:
    IF DataPin = 1 THEN WaitForStart  ' Keep waiting while idle is HIGH
    PAUSEUS 490                      ' Wait a bit into LOW
    IF DataPin = 0 THEN              ' Still LOW? good start
        GOSUB ReadBits
    ENDIF
    GOTO Mainx


' --- Subroutine: ReadBits ---
ReadBits:
    ' Wait until line goes back HIGH before first bit
    DO
    LOOP UNTIL DataPin = 1
    PAUSEUS 1000                      ' Move to middle of first bit period


    RxValue = 0
    FOR BitMask = 0 TO 6
        IF DataPin = 1 THEN
            RxValue = RxValue | (1 << BitMask)
        ENDIF
        PAUSEUS 1020                ' Move to middle of next bit slot
    NEXT


    ' --- Ensure line is HIGH again before next frame ---
    DO
    LOOP UNTIL DataPin = 1


    ' --- Display received value on LCD ---
    LCDOUT $FE,1                     ' Clear display
    LCDOUT "Received: ", DEC RxValue


    RETURN

[CuriousOne]

I just tried this code, and it does not work:


TX:

Main:
    FOR TxValue = 0 TO 255
      
        SEROUT2 DataPin, 84, [100,5,200, TxValue]
        PAUSE 500      
    NEXT
    GOTO Main

RX:

LCDOUT $FE,1
LCDOUT "Waiting data..."






RxValue VAR BYTE


Mainx:


    SERIN2 RxPin, 84, [WAIT (100,5,200), RxValue]


LCDOUT $FE, $C0, "Rx=", dec RXvalue, "   "


    GOTO Mainx

[CuriousOne]

if I reduce control values to 1 or two, then it works, but totally wrong data is being decoded.

[Ioannis]

How about this code:

x vart word
x=345
barka:
serout2 portc.3,84,["s",x]
pause 100
goto barka

RX (45K80)

x var word
taka:
serin2 portc.3,84,[wait("s"), x]
if x=345 then lcdout $fe, $c0, "X=", dec x, "    "
goto taka

Ioannis

[Jerson]

Why 22k? It seems pretty high to have. Your post suggests you've tried a lower value like 1K; if both PICs are running at the same voltage levels, then altogether do away with the resistor. Due to the resistor, it is possible the logic low level is not being met. If you fix this and still get the problem, then continue below.

I suspect the problem could be the software serial not getting the start bit reliably.

What you can do - since you use the 1936 is to configure the receive pin as interrupt on change pin; I believe all pins have IOC ability on this chip.

When you get the IOC interrupt, invoke the serin2 command in the ISR

I cannot advise with code as I am not up-to-date with PicBasic since some time now.

[CuriousOne]

Both 1K and 22K are actually suggested in PBP manual.
So I tried both, I tried 100 ohm resistor, I tried direct connection. No practical difference - actual "junk" bytes are getting different, but proper one still not delivered. The above slow code, suggested by AI, works with either 100 ohm, 1K or 22K.

Currently I'm sending data from 1936 to K80 because K80 has LCD screen so I can use it for debugging. In the real life, K80 will be sending data to 1936.

As a side "improvement", I can use additional data line from K80 to 1836, so SHIFTOUT/SHIFTIN should work then. I guess it will be more reliable?

[Ioannis]

The 22K is used ONLY when you are driving the INPUT of the PIC from a real RS232 line, which does -12 to +12 Volts on the pulses!

No need to have it on TTL connection as in your case. Remove it.

The 1K is used ONLY when you drive from the OUTPUT of the PIC to the RS232 line, to lower the current that PIC is forced to supply.

Again no need to have it on TTL connection as in your case. Remove it.

Have you tested the code on #6 with no resistors?

Ioannis

[richard]

Have you tested the code on #6 with no resistors?

works ok in simulator, apart from initial sync issue due to the comms line not beginning at a proper tty level before reception enabled

and then again i used complete programs not snippets full of guess work


@Ioannis you missed the spam in faq section