I2C tra PIC sembra facile ...

D:\Documents and Settings\gianni\Desktop\FORUM3.odt
I2C sembra facile ma …

In rete si trovano Librerie I2C e qualche esempio quasi SEMPRE centrato sulla comunicazione tra MASTER e SLAVE ma con uno slave costituito da una Memoria Eprom o da un Orologio.

Io devo far comunicare due PIC uno Master PIC18F4550 (con funzione MSPP) e uno Slave PIC16F88 (Con funzione SSP).

Purtroppo questa comunicazione non è identica a quella che avviene con EEPROM o OROLOGI nel senso che il PIC SLAVE svolge SUE operazioni e deve comunicare con il MASTER attraverso INTERRUPT.

La chiave sembra stare TUTTA nella routine di interrupt dello SLAVE che ho scaricato dal sito www.vincenzov.net/tutorial/elettronica-di-base/ e che ripropongo spiegando di seguito quali sono le anomalie.

L'allegato spiega con qualche dettaglio quali sono le anomalie. Se qualche generoso ha un poco di tempo per rispondermi sarò molto grato.

ECCO l'allegato SCUSATE

Ora non sono fresco per dire che le impostazioni dei vari registri siano esatte.
In ogni modo mi sembra strano che il master non aspetti per un acknowledgment dopo aver trasmesso i byte. Non sono certo se la funzione di trasmissione implementa il controllo.

Se stai usando il bus I2C per far comunicare periferiche sul robot taglia erba considera in ogni modo un bus diverso. In particolare un bus con interfaccia RS485 (abbinata ad una USART) o il protocollo CAN (usando un transceiver MCP2551), visto che sono più immuni a disturbi, cosa che su un robot con motori elettrici abbondano. Il bus I2C viene normalmente usato per piccole distanze anche se sono presenti applicazioni con bus piuttosto lunghi.

Saluti,

Mauro

ciao Mauro

Avevo scelto il Protocollo I2c perchè mi sembrava banale e sperimentato ma purtroppo non è così. La documentazione sulla gestione degli interrupt dello SLAVE è veramente scarsa sia nel DATA SHEET che in giro sulla rete. Sono in difficoltà.

Si è vero sto sviluppando il nuovo Progetto di Rasa ERba in cui era mia intenzione collocare un PIC18F4550 e due PIC16F88 addetti uno alla gestione Ostacoli e Delimitazioni e il secondo alla conversione AD delle grandezze da tenere sotto controllo Vbatteria Iricarica, Tmotori ecc.
Prendo atto delle tue indicazioni ma PIC16F88 e CAN (o RS485) vanno d'accordo ?. Non sono un elettronico e devo studiare tutti questi ptrotocolli e circuiteria relativa !

E pensare che avevo gia realizzato la comunicazione tra i tre PIC usando RS232 (anche se la teoria dice che RS232 lavora solo tra due dispositivi!) Poi Mi sono posto il problema di un telecomando da realizzare con XBee che purtroppo si rifiuta di funzionare in RS232 se non da solo!

Ecco spiegata la mia conversione ad I2C. Se tu dici che devo riconvertirmi ancora mi adatto ma spero non sia come con il protocollo I2c SLAVE.

Saluti

Utilizzare un PIC in modalità slave è sicuramente interessante, visto che non si trova molto materiale a riguardo.
Gran parte degli esempi fanno riferimento al PIC come master. E' un topic sicuramente da tenere a mente.

Per quanto riguarda il protocollo CAN e l'interfaccia RS485 abbinata ad una USART, direi che il primo è il più robusto, non a caso viene utilizzato in ambito automobilistico...e nel mio robot Artorius!
Però utilizzare il protocollo CAN non è banale e necessita di PIC con CAN engine come per esempio il PIC18F4580 o meglio PIC18Fxx80.
Nella sezione Tutorial puoi trovare un tutorial sul CAN, inoltre ho scritto anche una libreria in C18.
Come esempi puoi vedere poi il convertitore RS232 CAN. In ogni modo il CAN non è facile ed è meglio utilizzarlo come seconda spiaggia o quando non si vogliono avere compromessi per la sicurezza.

Lo standard RS485 abbinata ad una USART, da un punto di vista elettrico è piuttosto robusto (immune al rumore), ma devi implementarti l'intero protocollo via software per poter raggiungere lo stesso livello del protocollo CAN.
D'altro lato utilizzare lo standard RS485 abbinato ad una USART è relativamente banale se hai già usato lo standard RS232 e l'USART.
Infatti il suo utilizzo si riconduce all'uso della USART ed invece di utilizzare il MAX232 usi il tranceiver MAX485.
La trasmissione è differenziale e sullo stesso bus puoi aggiungere più periferiche, quindi hai un bus condiviso.
Se hai domande puoi aprire un altro topic ed possiamo affrontarlo con maggior dettagli.

Guarda come esempio il progetto Freedom II.

Saluti,

Mauro