I²C mit Bitrate > 100 kHz - nur mit Treiber ?
Zusammenfassung vom 03. Dez. 2012, 09:20.
Die Aufgabe ist für mich gelöst, die durch Intitialisierung vorgegebene Übertragungsrate beträgt deutlich mehr als 400 kHz: TWBR=5 läuft fehlerfrei, mit TWBR=17 erhalte ich laut Rechnung mit dem 20MHz auf Master und Slave 400 kHz.
In diesem Posting (klick) ist das verdächtige Codeteil zu sehen nach "i2cdmy = i2c_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen".
In diesem Posting (klick) wird über den letzten, sehr gut funktionierenden Stand berichtet.
- - - - - Es folgt der ursprüngliche Beitrag - - - - -
Hallo Alle, bitte um Ratschläge.
Aufgabe:
o Eine Platine als Master, derzeit mit mega1284/20 MHz, I²C mit je 1x10kΩ, soll mehrere Slaves - weniger als zehn - treiben, die verschiedene Aufgaben erledigen.
o Derzeit hängt an einem Flachbandkabel 55cm EIN einziger Slave mit mega328/20MHz, I²C mit je 1x10kΩ.
o Auf Master und Slave wird zum I²C-Betrieb die Fleurylib benutzt.
Die Kommunikation läuft in dieser Konfiguration nur dann störungsfrei, wenn ich sie mit gemächlichen 100 kHz betreibe. Tests mit 200 gehen öfters schief, ein Test mit 400 funktioniert gleich garnicht. Diese 100 kHz sind mir eigentlich schon bei diesem 1-Slave-Aufbau zu wenig, da der Slave als Motorsteuerung arbeitet und zukünftig recht viel Rechenarbeit schon zu Regelung und Fahrplanung haben wird.
Nun möchte ich ja später mehrere Slaves dranhängen - da fürchte ich, dass dann der Master (und der Bus) recht viel zu tun bekommen. Ne ganz grobe Milchmädchenrechnung (Daumenlutschen) lässt vermuten, dass ich mit der geplanten Kommunikation bei der derzeitigen Datenrate das spätere, ganze System recht ausbremsen würde.
MUSS ich für höhere Bitraten unbedingt einen Treiber verwenden - z.B. den PCA9600? Da ich fertige Platinen verwende (~n möchte) käme mir ein aufge"klebter" Bustreiber garnicht gelegen . . .
Danke für Eure Hilfe.
PS: GAAAANZ grosses Manko im Forum: die Suche mit dem Suchbegriff "I2C" wird abgelehnt:
Die folgenden Probleme traten bei deiner Suche auf:
- Die folgenden Wörter sind sehr allgemein, zu kurz oder zu lang und wurden daher in der Suchanfrage ignoriert:
i2c
Können Interrupts ein Fehlerauslöser sein - evtl. wegen hörerer Priorisierung ?
Zitat:
Zitat von
oberallgeier
Hilft mir doch, danke! ... Eigentlich geht ... nur mit 100 kHz ...
Und bei den vielen Tests der letzten Tage war wohl der eine oder andere seltene Fall dabei, dass sich der Master auch bei 100 kHz aufgehängt hat - oder vom Slave aufgehängt wurde.
Codeschnippsel vom Master - Lesen I2C-Buffer
Code:
// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
// Lesen vom Slave ##### mit Änderung/Zusatz
if(!(i2c_start(SLAVE_MoCo+I2C_WRITE))) //Slave bereit zum schreiben/lesen?
{ //
// - - - - - - - - - - - - - - - - - - - - - - - - - -
// Musterzeile vom RN Wissen
// i2c_write(0x00); //Buffer Startadresse zum Auslesen
// i2c_rep_start(SLAVE_ADRESSE+I2C_READ); //Lesen beginnen
// - - - - - - - - - - - - - - - - - - - - - - - - - -
i2cdmy = i2c_write(0x00); // Buffer Startadresse 0 zum Auslesen
i2c_stop(); //
i2cdmy = i2c_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen
////i2cdmy = i2c_rep_start(SLAVE_MoCo+I2C_READ); // <<<### Lesen beginnen
btst1 = i2c_read (ACK); // 1. von 5 Bytes lesen...
Kann das an den Interrupt(s) liegen? Der Master (mega1284) hat einen Timer-Interrupt, 50µs von TIMER2 COMPA, der Slave (mega328) hat ebenfalls Timer-Interrupt, 50µs von TIMER2 COMPA, dazu werden kommen zwei extINT0 und ~1 von den Encodern, evtl. noch andere Interrupts. Der TIMER2 COMPA ist mit Vector 8 resp. 10 relativ hoch priorisiert, die extINT mit 2 bzw. 3 sehr hoch - dagegen ist der TWI mit vector 25 resp. 27 weit unten. Nun soll natürlich eine IRS immer warten, bis die laufende fertig ist - ich lasse keine nestet Interrupts zu - aber
es könnte Zeitverschiebungen in der I2C - Kommunikation geben. Macht das etwas? Könnte das der Fehler sein?
Experimentelle Softwareentwicklung
Zitat:
Zitat von
oberallgeier
... Weitere Bemühungen zum I 2C pausieren aktuell ...
... Nur pausiert das Gehirn nachts nicht immer. Das scheint nicht nur bei mir so zu sein, wenn ich mir so manches 2- (3- oder 4-) -Uhr-nachts-Posting ansehe.
Mir war ein-/aufgefallen, dass der Abbruch der I2C-Kommunikation immer nach einer ganz bestimmten, genau lokalisierbaren Aktion (UART-Ausgabe eines rückgelesenen Datensatzes) erfolgte, auch wenn oft vorher die gleiche oder ähnliche Test-Schreib- und Leseaktion durchgefahren wurde (läuft RC-5-gesteuert). Der Abbruch erfolgte mal nach mehr, mal nach weniger Durchläufen, manchmal sofort nach dem Lesen - je nach I2C-Geschwindigkeit. An dieser Stelle wurde die Leseadresse geschrieben - und danach ein "i2c_start(SLAVE_MoCo+I2C_READ)" gesendet. Jetzt, nachdem ich VOR diesem Readbefehl, nach dem Schreiben der Leseadresse ein i2c_stop gesetzt habe, rauscht mein I2C mit maximaler Geschwindigkeit - maximal nach ATMEL-Spezifikation: TWBR should be 10 or higher... , aktuell habe ich TWBR = 10.
Testaufbau: RNControl, m1284/20MHz, Eigenbau Servoplatine, m328/20MHz, 9-poliges Flachbandkabel, ca. 1m20.
Danke für die vielen hilfreichen Tips, danke m..c..
Anmerkung: Manche Menschen machen keinen Fehler zweimal, aber sie lassen auch keinen aus . . .
