I2C zwischen Controllern

[Klebwax]

Bei keinem der (wenigen) I2C-Bausteine, die ich bisher verwendet habe, gibt es Clockstretching. Alle liefern auf Anfrage Daten und kennen keine unvorhersehbaren Verzögerungen bei der Buskommunikation, weil sie die I2C-Engine in Hardware haben.

Das sagst du so locker.

Clockstretching tritt sogar ohne Slave auf. Nimm mal einen "sauber" implementierten I2C Master und betreibe ihn mit 400kHz, bei höheren Geschwindigkeiten ist der Effekt leichter zu erkennen. Ein Slave ist nicht angeschlossen, die Pullups sind so 10kOhm. Die 400kHz sind leicht nachzumessen. Nun schalte mal 400pF zwischen SCL und GND, das ist die maximale kapazitive Buslast nach der Spec. Der Bus wird jetzt merkbar langsamer (solange der Master sauber implementiert ist). Der Grund ist einfach: der Master setzt SCL für die halbe Bitzeit passend zu 400kHz auf low. Dann läßt er das Signal los und wartet, daß es high wird. Durch die hohe Kapazität des Busses dauert es aber eine Zeit, bis der High-Pegel erreicht wird. Erst dann startet er den Timer, wieder eine halbe Bitzeit, für die High-Phase von SCL. Die messbare SCL-Frequenz wird damit langsamer, die Clock "gestreckt". Es ist egal, wer oder warum SCL länger low ist, als der Master vorgibt. Der häufigste Fall ist natürlich, daß sich der Slave beim ACK erwas Zeit nimmt indem er SCL low hält.

Bei einer Prozessor-Prozessor Verbindung ist Clockstretching eigentlich unvermeidlich und sehr hilfreich. Man kann im Slave wesentlich lockerer mit Interrupten und Interrupt-Sperren umgehen ohne die Integrität der Übertragung zu gefährden.

MfG Klebwax

[RoboHolIC]

Nun ja. Wenn man das elektrische Tiefpassverhalten der Busverdrahtung (aus Sicht des Masters verständlich) auch dem Thema Clockstretching zuordnet, dann hast du natürlich recht.

Andererseits: 400kHz und 400pF sind zwar innerhalb der Spec, nicht aber in Verbindung mit den 10k Pullups, weil man damit eine RC-Zeitkonstante von 4µs, mithin 250kHz vorgibt, aber den Bus mit 400kHz betreibt. Die Busverlangsamung demonstriert dann, dass der Master das Clockstretching toleriert.

[Sauerbruch]

Also im Moment wäre ich ja schon froh, wenn der Slave einfach nur auf den Master reagieren würde... habe hierzu folgenden Code für den Master geschrieben:

$regfile = m8def.dat
$Crystal = 1000000

Config sda = PORTD.7
Config scl = PORTB.0

Do

I2cstart
I2cwbyte &b00000010
I2cstop

waitms 200

Loop

scl und sda sind mit 4k7 mit +5V verbunden, die Signale sehen gut aus.

Beim Slave wollte ich mit einer toggelnden LED einfach nur mal sehen, ob er wenigstens schon mal in die TWI-ISR springt, wenn der Master die Slave-Adresse sendet:

$regfile = m8def.dat
$crystal = 1000000

Config sda = PORTD.7
Config scl = PORTB.0

DDRD.0=1

TWCR = &b00000101
TWAR = &b00000010

On TWI Empfang
Enable TWI
Enable Interrupts

Do
Loop

Empfang:
Toggle PORTD.0
Return

Aber leider passiert nichts. Ich habe mir vorsichtshalber gerade die I2C-lib gekauft und werde sie heute Abend mal einbinden...

[RoboHolIC]

OK, mein Beitrag über dedizierte I2C-Slave-ICs war schon am Thema vorbei.
Aber jetzt klinke ich mich besser aus, weil ich aus dem Code nichtmal rauslesen kann, ob es sich um TWI-Hardware oder eine Emulation in den Slaves handelt.

[Sauerbruch]

Aber jetzt klinke ich mich besser aus, weil ich aus dem Code nichtmal rauslesen kann, ob es sich um TWI-Hardware oder eine Emulation in den Slaves handelt.

Ich würd´s Dir gerne verraten - wenn ich es selber wüsste

Mal sehen ob mich die I2c-Lib weiterbringt, ich werde jetzt noch ein wenig weiterpuzzeln!

[021aet04]

Ich kenne mich mit Bascom nicht aus, aber du verwendest TWAR und TWCR. Somit verwendest du Hardware I2C (TWI). TWAR ist das Adressregister (Two Wire Adress Register) und TWCR ist das Control Register (Two Wire Control Register). Wie du den Atmega als I2C Slave verwendest steht ab S177 im Datenblatt. Dort steht z.B. das das TWEA und TWEN Bit in TWCR "1" sein müssen. Bei dir ist das TWEA Bit aber nicht gesetzt (ist das 6te Bit). TWSTA und TWSTO dürfen nicht gesetzt werden.

MfG Hannes

[Sauerbruch]

So, jetzt habe ich mir das LIB-Paket von MCS Electronics gekauft und mich entschieden, für erste Versuche zwei Mega8 und Hardware-I2C zu verwenden, um es so unkompliziert wie möglich zu machen.
Trotzdem wirft das Ganze bei mir immer wieder neue Fragen auf, auf die vielleicht hier jemand die Antwort weiß:

1. Wenn I2C und TWI tatsächlich das gleiche sind, wie in der Bascom-Hilfe ja imer wieder mantrahaft wiederholt wird, weshalb gibt es dann für beides Befehle zur Konfiguration eines Slaves (CONFIG I2CSLAVE und CONFIG TWISLAVE)?

2. ist mir bei ersten Versuchen aufgefallen, dass der Befehl CONFIG I2CSLAVE lediglich zwei Labels benötigt (I2c_master_needs_data und I2c_master_has_data), während die Verwendung von CONFIG TWISLAVE gleich ein halbes Dutzend Labels verlangt (twi_addressed_goread, twi_gotdata, twi_stop_rstart_received, twi_addressed_gowrite, twi_master_needs_byte und twi_master_need_nomore_byte).

Wenn der Slave eine variable Anzahl an bytes empfangen soll wäre es doch sinnvoll, nach der korrekten Read-Addressierung eine Zählvariable auf 1 zu setzen, sie nach jedem empfangenen Byte um 1 zu inkrementieren, und damit ein Array zu füllen. Wie kann man so etwas denn lösen, wenn man den CONFIG I2CSLAVE-Befehl nutzt, und dementsprechend nur die Labels I2c_master_has_data und I2c_master_needs_data hat?

3. Mit dem Befehl CONFIG TWISLAVE kann ich bisher leider gar nicht rumexperimentieren, weil beim Kompilieren stets die Fehlermeldung "Illegal character [expected(, got "[TWI_CBTR]]" erscheint. Weiß jemand damit etwas anzufangen? (Habe die Bascom-Version 2.0.7.3)