[SOLVED] Pic to pic uart communication

Hai,
iam trying to establish communication between 2 PIC mcu, PIC18F4520 and PIC16F628A.
actually i need to establish long distance communication so i am going to use max232 and all.

But now i just tested them with direct connection. ( no max232 or anything in between) with wires few cms long. but it doesnt seem to work.
sometimes i get random values and other times nothing.


In 18f4520 i am using following configs
crystal iam using 16mhz

in 16f628a their was no registers to set, just initialized UART to same baudrate.

The circuit works fine in proteus

is their anyway i can test whats going wrong ? something like meters on Rx or tx line ?

Did you test your code and design on any simulating software(Proteus), if it worked there then it should work on real world provided your hadware designs are correct

in 16f628a their was no registers to set, just initialized UART to same baudrate.

Click to expand...

What about stop/star bits number of bits etc Below is the code to initialize the 16F628 to 8 bits no parity one stop bit. Tested and working.

it worked in proteus.


finally i got it to to work in practical.. i had to reduce baud rate from 9600 to 2400

so whose baudrate you reduced? PIC18F or 16F?

I reduced both of their baudrate.. btw it has to be same anyways right?

Can I strongly suggest that you configure the ESUART of the PIC18F4520 completely (including the baud rate registers) before you enable the peripheral. (You have the "TXREG.TXEN=1;" as the 2nd of 9 instructions.) While the theory (and simulators) might be that this makes no difference, in the silicon it can make the difference between success and failure.
I note that the PIC18F4520 does not have the ESUART receiver configured - I assume that you will only ever be using this as a "send only" device.
I don't know what compiler you are using, but the BRGH bit is on the TXSTA register according to the data sheet, and not the BAUDCON. That should have been picked up as a syntax error by the compiler.
The PIC16F628A as 8 different oscillator modes - which one are you using and at what Fosc as that can make a big difference to the stability of the USART.
The reason for all of these questions and comments is that there is no reason why either of the devices you are using should not handle 9600 (and a heck of a lot faster as well) with ease.
By having to drop to 2400, that tells me that the oscillators are way out of frequency and you need to go to the lower BAUD rate to compensate. The clocks need to be within a few percent for accurate transmission and reception and some RC clock sources are simply not stable enough, but crystal-based oscillators are almost always fine.
Susan