Tx sends recieved values twice sometimes

20 views
Skip to first unread message

Chris Peeters

unread,
Jan 25, 2021, 7:00:57 AM1/25/21
to jallist
Hello all,

I have a PIC16F1575 that recieves data from one pic and sends it to an other one.
Baud is 38400 but does not matter, it happens on all speeds and different clockfrequencies.
The data consists out 3 bytes and is send randomly. 95% of the time is the data correct but sometimes, i recieve a byte twice (I recieve 4 bytes).
I made a test setup with 2 ftdi's en just a basic program and still the same problem.
Is the problem related to the different devices on the RX and TX pin ?

Anyone an idea ?

Thanks


include 16F1575
include PPS
include delay

pragma target clock     16_000_000       -- oscillator frequency
pragma target OSC       INTOSC_NOCLKOUT
pragma target WDT       DISABLED
pragma target LVP       disabled        -- no Low Voltage Programming
pragma target MCLR      external        -- reset externally
pragma target PWRTE     enabled         -- enalbe powerup timer
pragma target BROWNOUT  DISABLED        -- no brownout reset
pragma target PLLEN     disabled

OSCCON_IRCF = 0b_1111                   --16Mhz

--IO pin selection
------------------
enable_digital_io()

pin_A2_direction = INPUT                --Hardware Rx via PPS 
alias pin_RX is pin_A2
alias pin_RX_direction is pin_A2_direction
pin_C2_direction = INPUT               --Hardware TX via PPS
alias pin_TX_direction is pin_C2_direction
alias pin_TX is pin_C2


--PPS(Pin Pheripheral Select)
-----------------------------
RA2PPS = PPS_RX
RXPPS = PPS_RA2                         --Input selection        
RC2PPS = PPS_TX                         --Output selection       

--Serial hardware
-----------------
const usart_hw_serial = true-- true = RS232, false = SPI
const serial_hw_baudrate = 38400--9600

include serial_hardware
serial_hw_init()
serial_hw_enable

--Communicatie
var byte hwread           
var byte swread           

forever loop
    if serial_hw_read(hwread) then
        serial_hw_write(hwread)
    end if
end loop

Rob CJ

unread,
Jan 25, 2021, 1:33:25 PM1/25/21
to jal...@googlegroups.com
Hi Chris,

The only thing that I can imagine is that the internal oscillator is not as precise as you think. Some time ago I made a cat repellent creating a 40 kHz signal and noticed that the only way to get it right was by tuning the internal oscillator using an oscilloscoop.

If one PIC is running a bit too slow and the other is running a bit too fast I am not sure if that would give a problem although for low baudrates I would not expect it.

You have 2 options to verify if this is the problem:
1) Measure the clock output and tune the internal oscillator using the OSCTUNE register. You need to set CLKOUTEN to ENABLED so that you can measure this. Note that it will be the internal clock divided by 4 so 4 MHz.
2) Use a crystal.

Kind regards,

Rob




Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Chris Peeters <chris.p...@gmail.com>
Verzonden: maandag 25 januari 2021 03:39
Aan: jallist <jal...@googlegroups.com>
Onderwerp: [jallist] Tx sends recieved values twice sometimes
 
--
You received this message because you are subscribed to the Google Groups "jallist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallist+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallist/a3ab9db8-d615-4b2c-afcf-a777f133db54n%40googlegroups.com.

Mike

unread,
Jan 28, 2021, 12:27:26 AM1/28/21
to jallist
Hi Chris,

Why is TX set to INPUT?

Regards,
Mike


Chris

unread,
Feb 2, 2021, 7:27:03 AM2/2/21
to jal...@googlegroups.com

Hi Mike,

 

That is standard in the hardware_serial procedure.

Both RX as TX are input.

 

Kind regards

Chris

 

Van: 'Mike' via jallist <jal...@googlegroups.com>

Verzonden: donderdag 28 januari 2021 6:27
Aan: jallist <jal...@googlegroups.com>

--
You received this message because you are subscribed to a topic in the Google Groups "jallist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jallist/9mVyqIMLYhY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jallist+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallist/1c588157-4032-41f9-b20e-85957fa99079n%40googlegroups.com.

Chris

unread,
Feb 2, 2021, 7:37:40 AM2/2/21
to jal...@googlegroups.com

Hi Rob,

 

Thanks for your fast reply.

Indeed, that will be the problem. But I don’t gone shuffle with the osctune. I’ve been messing with that a time ago and my conclusion was that it’s very difficult to maintain a very stable clock without crystal.

Temperature is one of the variable that is very important in that matter.

 

I’ve made a buffer of 30 bytes on the received data. And when the processor has the time to transmit, he can empty the buffer.

 

Tis works well.

 

Thanks for your thoughts

 

Kind Regards

Chris

--
You received this message because you are subscribed to a topic in the Google Groups "jallist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jallist/9mVyqIMLYhY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jallist+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallist/AM0PR07MB6241D52C65D52D18F6801481E6BD0%40AM0PR07MB6241.eurprd07.prod.outlook.com.

Reply all
Reply to author
Forward
0 new messages