Ok let's go to 1st principles.
U want to send a number between 2 pics with a common Gnd.
let's use 2 pins to comm between em. To keep the control coding simple.
Assuming 1 way data flow here, we have the Xmit Pic and the Rcv Pic. Also assume they have the same clock speed. And GPIO1/2 is Dig out on the Xmit PIC and set as Dig Inputs, on the RCV PIC.
Ok..Xmit GPIO1 goes hi....Rcv Pic GPIO1 sees this and initialises a counter variable (Rcount)
Xmit PIC waits some inst. cycles to make sure the Rcv PIC is rdy before sending data, as we have no acknowledgement with uni directional data.
Now send pulses (= to the number u want to Xmit) via the Xmit PIC GPIO2 pin, the Rcv PIC GPIO2 pin is being checked by s'ware or an interrupt or is T0Ck count configured to count.
When Xmit PIC is done sending it pulls its GPIO1 pin LOW and the RCV PIC sees this and your number now resides in the Rcount variable in the Rcv PIC. RCV PIC stops counting and returns to main prg loop until next xmit HIGH on GPIO1
Notes: since we're not exactly synced unless u have a common crystal running both PICs etc, each transmitted pulse should last at least 4 inst. cycles with a 50% duty cycle to ensure no missed counts. The RCV GPIO1 pin that alerts the RCV PIC to start receiving should be an interrupt driven PIN to ensure quick response by the RCV PIC. Otherwise you'll have to time your RCV PIC prg loop to determine how long the Xmit PIC should wait for the RCV PIC to be rdy to RCV.
If u are prgoramming an ASm this will work ok, With C or BASIC compiles u will have to allow for longer pulses to ensure proper comms. Do a bit of sim. testing to see.
That's the basics, a good s'ware UART will have something called handshaking and acknowledgements and maybe a checksum to ensure accurate comms.