Comunicazione tra 4 PIC (un Master e gli altri slave)

Buonasera a tutti, sono qui per chiedere il vostro aiuto:

Devo realizzare un sistema di controllo di 3 assi (X, Y e Z), e ogni motore (passo-passo o con encoder) deve essere gestito da un pic.
Quindi ogni pic comanda un motore (è una mia scelta per avere un sistema modulare).
Si aggiunge un quarto PIC che coordina tutti gli altri, cioè comunica ad ogni pic la posizione che il motore deve raggiungere (poi il pic dell'asse pensa a fare tutte le manovre di spostamento).

il PIC principale è un 16F877, (o meno probabilmente un 18F4550)
i PIC di ogni asse sono 16F88 (o se è un problema posso usare dei 16F877 anche per i 3 assi)

Il problema sorge proprio qui:
come faccio a fare comunicare tra loro questi 4 pic?
Il PIC principale deve comunicare agli altri le posizioni da far raggiungere ai motori (sarebbe meglio anche che i pic dei motori inviassero un "feedback" al pic principale per comunicargli che la posizione è stata raggiunta).
Il fatto è che non so come fare questa comunicazione... Con I2C, SPI, UART... Non lo so, e non so nemmeno come utilizzare i protocolli. So più o meno come funzona l'I2C, però applicato a eeprom e rtc, non tra PIC.

Mi potete aiutare?

Grazie, Marco

Ciao Marco!
Forse la cosa più funzionale sarebbe l'I2C.
Per darti un'infarinatura potresti leggere qualcosa su Wikipedia .
Ho controllato sul datasheet e confermo che il pic16f877 ha il modulo I2C lo spiega al paragrafo 9.2.
Quello che devi fare tu è settare come MASTER il pic che deve comandare tutto e come SLAVE gli altri 3. Quando il master vorrà comandare un motore trasmetterà il comando su tutta la linea avendo cura di spedire l'indirizzo del motore da comandare. Gli slave non trasmetteranno mai di loro spontanea iniziativa ma solo per spedire un feedback al master.
Per settare il modulo ci sono dei registri apposta che sono spiegati nel datasheet (scusa se non posso spiegartelo io ma non ho mai usato l'I2C su un PIC ).
Il resto è tutto software da gestire grazie agli interrupt che genera il modulo I2C in caso di trasmissione/ricezione/errore.

Mi dispiace di essere stato molto generico ma spero di averti dato un minimo di punto di partenza

Ciao,

essendo la comunicazione tra vari PIC effettivamente le scelte si ristringono.

I possibili protocolli/physical layer potrebbero essere CAN, RS485, I2C.

In un ambiente rumoroso, come quello in cui siano presenti dei motori e' meglio evitare l'I2C, perche' suscettibile ad errori dovusti a disturbi esterni. il bis I2C venne concepito per brevi distanze. Implementando un protocollo per la correzione degli errori e la gestione del rinvio dei dati si potrebbe anche usare ma sarebbe una scelta un po' forzata.

Il protocollo RS485 abbinata ad una USART del microcontrollore e' forse la soluzione piu' semplice. Il bus RS485 e' di tipo differenziale e quindi elettricamente meno suscettibile ad interferenze/deterioramento del segnale. Il suo utilizzo non risulta molto complicato visto che devi usare l'UART. Anche in questo caso dovresti eventualmente gestire la correzione di eventuali errori e rinvio di dati. Questa soluzione l'ho utilizzata nella scheda per il controllo dei motori PJ3007 . probabilmente e' la soluzione piu' semplice.

Il protocollo CAN sarebbe anche perfetto, ma vincola il microcontrollore a tipi "speciali"con modulo CAN. Il bus e' di tipi differenziale ed effettua automaticamente il rinvio dei dati ricevuti con errori. Ho scritto una libreria e puoi trovare del materiale qui:

1) Il protocollo CAN
2) Libreria CAN per PIC18
3) RS232 CAN protocol converter

Saluti,

Mauro
3)

Quindi mi consglieresti l'utilizzo del RS485 abbinato all'USART...

Ok, vada per questa scelta, se mi consgli tu, mi fido.

Ma è compatibile con i PIC16F877? e con i 16F88?
e ci vuole molto da zero a imparare ad effettuare questa comunicazione?

Ti ringrazio molto per la risposta, e ti chiedo in ultimo se esistono librerie che mi consigli per l'utilizzo di questo metodo.

Grazie, Marco

EDIT:
Mauro, non sarebbe un problema per me utilizzare anche un PIC18 se per te è meglio, va benissimo (anzi forse è meglio)

Ah, scusa borelg se non ho visto la risposta, ero andato troppo in giuù

Anche io subito ero per l'I2C, ma vista la spiegazione data da Mauro, e il fatto che è un po' complicato da implementare tra PIC (tra l'altro non esiste supporto online, ho cercato ma...)
Poi Mauro mi ha fatto ricredere e penso proprio che utilizzerò l'RS485 + USART.

Ciao, Marco