Affinché un fronte di clock in aumento si verifichi in I2C, il master deve affermare il clock, il che può far sì che anche alcuni slave si uniscano nell'asserirlo, quindi il master e tutti gli slave devono concorrere a rilasciare il clock. Fino a quando tutti i dispositivi non rilasciano l'orologio, rimarrà affermato e tutti i dispositivi vedranno che è affermato.

Una volta che ogni dispositivo ha rilasciato l'orologio, ogni dispositivo slave "reinserirà" il circuito di mantenimento dell'orologio a meno che o fino a quando non sarà pronto per il successivo fronte di salita [alcuni dispositivi sono sempre "pronti" per i fronti di salita alla velocità con cui il master può inviarli, e quindi non necessitano affatto di un circuito di blocco del clock; altri possono a volte sapere che non saranno interessati a nessun fronte di salita fino a quando non appare la prossima condizione di avvio, e non riattaccano il loro circuito di blocco fino ad allora]. Quando il master vede che l'orologio è stato rilasciato, attende un periodo di tempo minimo per garantire che chiunque abbia bisogno di riarmare un circuito di attesa del bus abbia la possibilità di farlo, quindi riaffermare l'orologio e assicurarsi che sia tenuto abbastanza a lungo da consentire a qualsiasi circuito di attesa bus armato di unirsi per tenerlo. Il ciclo può quindi ripetersi.

I dispositivi slave generalmente non hanno una velocità minima di funzionamento, ma ne avranno una massima. Alcuni dispositivi sincronizzano tutta la loro logica I2C con un orologio interno e possono quindi richiedere uno o due cicli per inserire o attivare il loro circuito di blocco del clock. Inoltre, I2C richiede che i dispositivi debbano determinare in modo affidabile al 100% se i fronti sul filo di clock si verificano prima o dopo i fronti sul filo dati; poiché i cambiamenti della linea dati spesso si verificano quasi immediatamente dopo la caduta dei fronti di clock, i dispositivi possono aggiungere un certo ritardo quando percepiscono i cambiamenti della linea dati. Ciò richiede l'aggiunta di un ritardo tra il momento in cui il master cambia i suoi dati in uscita e il momento in cui aumenta il suo clock. A condizione che ogni dispositivo abbia il suo requisito di ritardo minimo soddisfatto, il master può ritardare quanto vuole; maggiore è il ritardo del master, maggiore è il tempo necessario per inviare i dati.

Seguendo i commenti:

Sì, la frequenza è hardcoded in alcuni registri specifici relativi a I2C. In fase di esecuzione.

Detto questo, la tua libreria Arduino potrebbe eseguire un po 'di sondaggio e misurazione del tempo di salita sul bus per determinare una frequenza di clock valida. Vediamo.

Dopo aver fatto un po 'di ricerca sui sorgenti, la risposta è in twi.h

  #ifndef TWI_FREQ # define TWI_FREQ 100000L # endif  

Un altro pezzo da quel file:

  TWBR = ((CPU_FREQ / TWI_FREQ) - 16) / 2;  

Dove TWBR sta per Two Wire Baudrate Register , sospetto.

La definirei una prova sufficiente e direi sicuramente, sì, la tua frequenza I2C è impostata direttamente dalla tua libreria senza alcuna negoziazione. Se vuoi cambiarlo, ti suggerisco di #define TWI_FREQ prima di #include twi.h (o indirettamente tramite Wire.h)

Dal sito Web di Arduino - Riferimento dettagliato della libreria Wire:

La chiamata twi.init () è interna alla libreria Wire. Esegue le seguenti attività: imposta la frequenza di clock che l'hardware TWI utilizzerà se / quando è il master sul bus I2C. È impostato nel codice sorgente a 100kHz, ma in teoria almeno puoi reimpostare questa frequenza ridefinendo TWBR prima di chiamare Wire.begin (), ad esempio: TWBR = 400000L dovrebbe impostarlo a 400kHz.

La libreria RTC che usi non cambia TWBR. Qualcos'altro che stai usando potrebbe averlo cambiato. Oppure il lungo e lento tempo di pull-up dei pull-up interni super deboli ha effettivamente causato il rallentamento del motore i2c di ATMega. Il motore controlla se la linea è alta o bassa prima di cambiarla.

Detto questo, la frequenza di clock i2c è arbitraria , fino alla frequenza massima più bassa supportata da qualsiasi dispositivo sul bus (e forse qualche decina di Hz in più). Più velocemente e inizi a ricevere problemi di lettura e scrittura. Alcuni dispositivi hanno frequenze minime prima del timeout, ma ho visto dispositivi a 400 kHz funzionare a 10 kHz. La velocità di clock è decisa esclusivamente dal master (cioè tu, il programmatore).

C'è un'opzione per allungare il clock da parte dello slave (mantiene la linea di clock bassa finché non è pronta, e richiede che il controllo principale per questo), ma le immagini dell'ambito non sembrano indicare che questo sta accadendo qui.

Se dovessi aggiungere alcuni pullup esterni appropriati, senza modificare alcun codice, dovresti vedere l'aumento della frequenza più vicino a 100kHz come la Wire Library definisce come standard