Si son varios los micros y están en la misma placa yo te recomiendo I2C.
EL I2C usa sólo 2 hilos, mientras que el SPI usa 3, pero con el PIC en I2C tienes detección automática de la dirección del esclavo. Al ser en la misma placa puedes usar la máxima velocidad que permita el PIC.
Yo tengo escrito un programa genérico en Linux para usar Modbus RTU sobre RS232 (o RS485) y sobre Ethernet, en modo maestro y esclavo, pero no lo tengo documentado por lo que es de poca utilidad. Como las comunicaciones de tu aplicación no van a salir de la placa no es necesario que uses un protocolo estándar, inventa uno lo mas sencillo posible.
En cuanto al protocolo Modbus para PIC tengo algunos fuentes sin probar, pero no recuerdo el origen, los encontré con Google.

Yo también usaría I2C. Una consulta, el pic 16f877 (si es este el modelo que vas a usar) no tiene el puerto D y E para temas de comunicación. Puerto paralelo creo que lo llaman, donde se usan los 8 bits del D para enviar datos y los del E para el control. Son muchos pines pero quizás se pueda usar.

No sé en que programaras el I2C, yo hace tiempo lo hice en ensamblador y no daba problemas, me parece que desde C han dicho alguna vez que si los da. ASM para los 16!

Aunque como dice Heli, si no vas a comunicarte con otros integrados pues lo mejor inventarse un protocolo sencillo. Una modulación por anchura del pulso como la de los mandos ir sería fácil de hacer, y sólo necesitas un pin, yo usaba la interrupción externa para detectar y recibir el envio de datos, para distinguir entre uno, cero o error, contaba el tiempo entre los flancos de bajada.

Un ejemplo de un mando JVC que capture para decodificarlo, para que me entiendas lo que digo, según la duración del Ton o Toff es un cero o un uno.

Hace una señal de inicio de comunicación de 8ms y 4ms on y off, para diferenciar entre cuando se pulsa un botón y permanece pulsado. Luego manda 2 Bytes, el primero de dirección y el segundo de datos. Quizás inventarse un protocolo como esto sea lo más sencillo.

Muchas gracias,

Creo que me han convencido definitivamente. Entonces tengo que resolver mis problemas con I2C. Les explico para ver si pueden ayudarme y me iluminan ...

Utilizando las rutinas I2C (lectura) no consigo establecer la comunicación entre un Master y dos esclavos entradas. El Master lee del 1º esclavo perfectamente pero cuando intenta leer del 2º esclavo se pierde.

Lo curioso es que si funciona correctamente si utilizo un Master y dos esclavos salidas, es decir el Maestro escribe un byte sobre el esclavo. He intentado de todo y no consigo

solucionarlo. Sin embargo las rutinas funcionan (están muy probadas) con módulos PCF 8574, Eeprom............. como comento solo cuando se trata de más de un Slave entrada.

El programa está configurado de tal forma que si cualquiera de los dos esclavos cambia de estado en su PORTB, activa una patita RC5, que a su vez genera una interrupción en el Master. Entonces este, según si activa el RB7 o RB6, lee una dirección u otra de cada esclavo. El Master recibe la siguiente cadena cuando lee del primer esclavo; S 01 A 73 N P (siendo 01 la dirección del esclavo y 73 el PORTB). Pero cuando procede a leer del segundo esclavo, recibe basura N 11 N 11 N 11.... A la inversa, el Master lee correctamente del segundo esclavo ( S 11 A 41 N P), siendo 11 la dirección y 41 el dato del PORTB. Nuevamente si intento leer seguidamente del pimero, recibo basura N 01 N 01 N 01 ....

Lo que he analizado es que cuando leo de un esclavo el otro también carga su dirección en la rutina MSSP HANDLER, y es incapaz de rechazar la dirección que no le corresponde y es entonces cuando los flags BF y SSPOV están llenos y es incapaz cuando realmente el Master quiere leer de él, de generar por hardware el bit ACK porque el buffer está lleno. Si realmente cuando su direcciión no coincide porque se carga con la dirección?????. Es cierta mi afirmación ??

Saludos!