Informazioni su bus I2C, possibilità utilizzo moduli custom

[Anonimo]

Vorrei utilizzare i moduli di espansione I/O con una mia CPU, a tale scopo ho bisogno di sapere il protocollo di comunicazione, ho guardato il manuale utente ma non lo riporta, come faccio a sapere come si comandano questi dispositivi ?

[Sergio Bertana]

Il bus di espansione I2C del sistema SlimLine viene gestito con comandi I2C compositi, un comando di scrittura seguito da un comando di lettura. Sono gestiti 256 comandi suddivisi su più bytes, ad ogni comando che la CPU invia al modulo il modulo crea la corrispondente risposta che viene acquisita in lettura dalla CPU.

Dovendo gestire accessi in multitasking da parte del modulo CPU tutta la gestione slave I2C è realizzata con una logica FPGA per garantire l’interoperabiltà della comunicazione tra i diversi tasks. Tutta questa gestione richiede un certo carico di lavoro da parte della CPU e per evitare problemi nella temporizzazione dei comandi non diamo indicazione su come gestire il bus da parte di terzi. Quindi i nostri moduli di I/O sono gestibili solo dai nostri moduli CPU.

[Sergio Bertana]

Aggiungo al topic una considerazione, solitamente è richiesto il contrario di quanto da te chiesto, ossia viene richiesta la possibilità di collegare ai nostri moduli CPU delle schede di I/O realizzate custom dal cliente.

Questo è molto utile in applicazioni specifiche o cost sensitive, in quanto permette al cliente di realizzare un proprio hardware che ottimizza l’interfaccia verso la sua apparecchiatura minimizzando i costi, poi tramite un nostro modulo CPU può gestire il programma utilizzando la programmazione nei 5 linguaggi standard della IEC-61131.

Per questo abbiamo realizzato una specifica funzione SysI2CWrRd per gestire l’accesso in lettura e scrittura di un qualsiasi dispositivo I2C connesso al bus. Utilizando questa funzione è possibile fare coesistere senza problemi i nostri moduli di estensione con moduli custom realizzati dal cliente.

[Sergio Bertana]

Ecco in questo post come realizzare un sistema per la gestione di motori passo/passo utilizzando IC direttamente connessi al bus I2C di estensione.

[Ruben]

Ho bisogno di utilizzare 5Vdc per alimentare un modulo periferico collegato al Bus I2C. Vorrei sapere la differenza tra pins di +5Vdc e pins di +5v (Aux).

[Sergio Bertana]

In questo topic viene trattato un esempio di gestione di un display alfanumerico connesso al bus di estensione.

[Sergio Bertana]

Le due tensioni in origine sul modulo CPU sono connesse tra di loro (Sono la stessa tensione), sono state diversificate sul bus di estensione per compensare la caduta di tensione dovuta ai cavi ed alle connessioni.

+5Vdc: Deve essere utilizzato per alimentare tutti i circuiti logici connessi al bus di estensione.
+5V (Aux): Deve essere utilizzato per alimentare eventuali dispositivi presenti sul modulo, esempio relè, LED, display, ecc. che non sono direttamente connessi al bus di estensione ma vengono pilotati da drivers.

[Michele]

Mi servirebbero informazioni riguardo l’I2C dei vostri moduli SlimLine, l’I2C l’ho già usata in passato. Quello che vorrei fare è creare un scheda custom connessa ad una vostra CPU Compact Base RS232. Qual’è la velocità dell’I2C ? 100k, 400k o 1M ?

Ho letto da manuale Hardware come connettere i pin +5V, +5V (Aux), RDYO-N, SCL e SDA quindi non ci dovrebbe essere problema da questo punto di vista. Quello che mi servirebbe sapere è come funziona il blocco SysI2CWrRd dal punto di vista della connessione fisica. Il blocco accetta 5 valori: Address, Nr bytes to write, Buffer to write, Nr bytes to read, Buffer to read. Cosa da in output sull’interfaccia I2C ?

Immagino che il primo byte sia l’indirizzo, poi come è strutturato il pacchetto ? Ho letto forse sul forum che si hanno al massimo 8 byte compreso un CRC16 come sono distribuiti ?

[Sergio Bertana]

Il bus I2C dei sistemi SlimLine e NetlogIII opera a 400Khz. La funzione SysI2CWrRd ha questi parametri:

Address (USINT) Indirizzo dispositivo I2C (Range da 16#00 a 16#7F).
WrBytes (USINT) Numero di bytes dati da scrivere. 0 se solo lettura.
WrBuffer (@USINT) Indirizzo buffer memoria che contiene i dati da scrivere. NULL se solo lettura.
RdBytes (USINT) Numero di bytes dati da leggere. 0 se solo scrittura.
RdBuffer (@USINT) Indirizzo buffer memorizzazione dati letti. NULL se solo scrittura.

Il frame I2C si compone di due sequenze eseguite una di seguito all’altra.

Se definiti dati da scrivere (WrBytes <> 0, WrBuffer <> NULL), inizia con start seguito da indirizzo I2C (Address), comando di write poi sono scritti tutti i bytes ed infine stop.

Se definiti dati da leggere (RdBytes <> 0, RdBuffer <> NULL), inizia con start seguito da indirizzo I2C (Address), comando di read poi sono letti tutti i bytes ed infine stop.

In merito alla composizione dei comandi I2C tu ti riferisci ai nostri comandi proprietari di gestione moduli di espansione che hanno un CRC per verificare la correttezza dei dati. Ma tu puoi utilizzare i comandi che desideri, in base al componente hardware da gestire. Discorso a parte sulla lunghezza dei dati da gestire in scrittura/lettura, noi consigliamo di tenere frame non più lunghi di una decina di bytes in totale questo per evitare jitters sulla esecuzione delle tasks (Vedi ulteriori informazioni in questo topic).

[Michele]

Un ultima cosa mi serve sapere, i comandi di write e read a cosa sono uguali ? Fosse per me userei per il read e il write un bit e gli altri 7 bit per definire l’indirizzo della variabile da leggere o scrivere. Come funziona ?

[Sergio Bertana]

Il bus I2C è uno standard ben definito, non si può inventare. Il primo byte inviato dopo il bit di start start è proprio composto da 7 bits di indirizzo (Infatti il range dell’indirizzo è compreso tra 16#00 e 16#7F) e da un bit che identifica il comando di read (Bit a 1) o write (Bit a 0).

[Anonimo]

Mi sembra utile la possibilità di collegare moduli I2C alla CPU. Potrei usare una versione OEM dello SlimLine per creare una sorta di controllore dedicato.

Da un’altra parte del forum ho visto che ci sono limitazioni al numero di byte da scambiare. C’e’ qualcuno cha mi può dare qualche informazione più precisa ? Non ho particolari criticità sui tempi di risposta e le attività svolte dalla CPU saranno essenzialmente sequenziali.

[Sergio Bertana]

Hai colto l’essenza di quello che si vuole offrire con l’utilizzo della funzione SysI2CWrRd, la funzione offre proprio la possibilità di gestire dal modulo CPU dei proprii moduli di I/O. Questo permette di sfruttare tutte le potenzialità offerte dall’ambiente di sviluppo LogicLab e/o CODESYS e dalle librerie da noi fornite su di un hardware costruito sulle esigenze del Cliente abbattendo i costi.

In merito al limite sul numero di bytes da scambiare è un problema solo legato al tempo di scambio che se i bytes sono molti provoca dei jitters sulla esecuzione delle tasks in interrupt (Task Fast e Slow). Ma è comunque possibile  frazionare i comandi, così ads esempio se devo gestire una memoria I2C anche da 1 Mb basterà scrivere/leggere i dati a blocchi di 10 bytes alla volta in modoi da permettere all’interupt di “entrare” tra una gestione è l’altra.

In pratica la funzione SysI2CWrRd è atomica, quindi ad  esempio se operasse su 100 bytes consecutivi fino a quando non ha terminato le tasks Fast e Slow sono bloccate (In questo topic trovi ulteriori informazioni).

[Autore]

Post