È possibile la frequenza mista I2C?

Supponiamo di avere un bus I ² C a 400 kHz . C'è un master e un sacco di dispositivi slave. Vorremmo introdurre un altro dispositivo slave, ma sfortunatamente va solo a 100 kHz.

Chiaramente, le solide scelte di design sono:

• basta eseguire quel bus a 100 kHz
• utilizzare bus separati per le periferiche da 400 kHz e 100 kHz

Ma la domanda riguarda solo un hack: cosa succede se usiamo un bus e indirizziamo i dispositivi a 400 kHz a 400 kHz e commutiamo il bus a 100 kHz quando parliamo con lo slave 100 kHz?

Oppure lo slave più lento potrebbe comportarsi in modo errato in risposta all'hash 400 kHz che vede sulle linee I ² C perché pensa erroneamente di essere indirizzato?

Possiamo contare su dispositivi a 100 kHz per essere ancora in grado di elaborare il segnale I ² C a 400 kHz sufficientemente bene da ignorare in modo affidabile i messaggi indirizzati verso altri slave?

Come suggerisci, farlo non è una buona pratica ingegneristica. Mentre alcuni dispositivi ignorerebbero maggiormente il traffico che non sono in grado di ricevere (sottocampione), altri potrebbero ingombrare il bus con frame errati.

Pertanto, la risposta che stai cercando dipende dalle tue specifiche dell'applicazione come:

• lunghezza delle connessioni I2C
• valore resistori pull-up
• compatibilità del dispositivo

Naturalmente, è difficile prevedere cosa succederebbe a un dispositivo gestito al di fuori delle sue specifiche alcuni anni lungo la strada.

Un'altra opzione è quella di eseguire una linea di arresto per rallentare i dispositivi o passare la linea di clock (a condizione che non possano generare il segnale di clock) attraverso un gate AND.

Un'altra opzione, se non si dispone di un bus I2C aggiuntivo in uscita dal master, è utilizzare uno switch I2C, come il PCA9543A / 43B . Metti gli slave 400kHz su un ramo e gli slave 100kHz sull'altro e commutalo se necessario.

Non è garantito che il dispositivo a 100 kHz non si comporti in modo anomalo quando esposto al traffico a 400 kHz: è possibile qualsiasi cosa, dagli NACK ai blocchi del bus.

Dovresti far funzionare l'intero bus a 100kHz o avere un bus a bassa velocità separato per la tua periferica lenta.

Altre opzioni. Invece di avere due bus, potresti semplicemente usare una linea aggiuntiva (più facile con un software / bitbanged I ² C). Una linea di clock separata o una linea di dati separata. Oppure utilizzare un I ² C tampone o I ² interruttore C a mettere quel singolo chip 100MHz su di esso il proprio segmento, senza dover cambiare ogni altra cosa.

O semplicemente provalo su un singolo bus. È del tutto possibile che il chip da 100 kHz influisca sulla linea. Potrebbe leggere ogni 4 bit e finire per pensare che sia stato risolto. Ma dovrebbe vedere una condizione iniziale valida, e quindi leggere ogni 4 bit dai successivi 32 bit come indirizzo esatto, quindi dovrebbe provare a leggere i successivi due byte come informazioni valide per scrivere nei suoi registri o prova a disconnettere i dati. Non credo sia una situazione troppo probabile. La soluzione migliore è semplicemente collegarlo in un circuito di prova e verificarlo.

Due cose da notare, se questo è un circuito unico, o se ne stai facendo solo alcuni, è abbastanza facile rischiare o cambiarlo. Se si tratta di un articolo prodotto in serie, potresti semplicemente voler avere il secondo bus. L'altro, è che devi considerare che il chip da 100kHz è stato semplicemente prodotto secondo le specifiche I ² C originali e potrebbe benissimo supportare velocità di clock più elevate. Semplicemente non è stato testato con le specifiche di velocità superiore a 400 kHz.

Il design del bus I2C è tale che -

1. quando si verifica un fronte di discesa su SCL, ciò può causare un dispositivo slave a far valere immediatamente SDA, senza alcun ritardo minimo particolare;
2. l'ordinamento relativo dei fronti di salita e di discesa è di fondamentale importanza.

A causa della differenza nella potenza del driver e nella capacità della linea, sarebbe teoricamente possibile che un dispositivo possa rispondere a un fronte di discesa un po 'lento su SCL guidando SDA così velocemente che un altro dispositivo vedrebbe cadere SDA per primo.

Potrebbe essere stato possibile definire più soglie logiche su SCL e specificare che affinché un fronte di discesa su SCL sia considerato come proveniente da un bordo su SDA, deve essere comunque superiore a 2/3 VDD quando viene rilevato il bordo su SDA, ma un dispositivo potrebbe non far valere SDA in risposta a un fronte di discesa su SCL fino a quando non è sceso al di sotto di 1/3 VDD, ma la specifica non è scritta in tali termini.

Invece, i dispositivi che vedono fronti di caduta quasi simultanei su SDA e SCL considerano generalmente il bordo su SCL come avvenuto per primo a meno che non sia sostanzialmente preceduto dal bordo su SDA. Alcune implementazioni I2C gestiscono ciò sincronizzando SCL e SDA con un clock esterno e richiedendo che un fronte discendente di SDA sia osservato due periodi prima di quello di SCL per essere considerato come il primo. Se la velocità delle operazioni su SCL e SDA è troppo elevata rispetto al clock di sincronizzazione, i dispositivi possono percepire sequenze arbitrarie di segnali alti e bassi su SCL e SDA; se una di quelle sequenze sembra indirizzare il dispositivo lento, potrebbe reagire di conseguenza, schiacciando qualsiasi altra comunicazione che potrebbe essere in corso.

Non vi è alcun motivo particolare per cui i dispositivi su un bus I2C debbano fare affidamento sulla sincronizzazione con un clock di sistema (essere in grado di rilevare due soglie discrete su SCL sarebbe meglio), ma il fatto è che alcuni dispositivi funzionano effettivamente in questo modo. Si noti che anche se un dispositivo limitato a basse velocità internamente volesse coesistere con un bus veloce, probabilmente dovrebbe impiegare almeno un clock che si allunga ogni volta che succede qualcosa a cui potrebbe essere interessato.

Ciò farebbe sì che alcune comunicazioni avvengano più lentamente di quanto potrebbero altrimenti, ma il degrado della velocità probabilmente non sarebbe così grave come richiesto dal design sincronizzato dell'orologio (la quantità effettiva con cui il dispositivo lento allunga gli orologi probabilmente non lo farebbe essere così cattivo come la quantità di cui l'orologio deve essere rallentato per evitare guasti dello scenario peggiore nelle unità di orologio sincronizzato).