Erstmal danke für die schnelle Antwort und dass du dir die Mühe machst, uns zu helfen! Also die Pullup Widerstände sind für die Datenleitung und für Clock drin. Da ham mir jeweils zwei 10KOhm Widerstände Parallel geschlossen, weil wir leider gerade keine 4,7K da hatten... Ich hoffe die 300 Ohm Unterschied sind da net so schlimm.^^ Und Oszi ham mir leider keins zur Verfügung. Den break Befehl hatten wir zum letzten Testen mal reingemacht um zu schaun, ob die Funktion wenigstens einmal ganz durchläuft.^^ Ich glaub ich werde einfach mal nach jedem Programmabschnitt einfach mal eine LED an/aus schalten um mal zu schauen, wo genau das Problem liegt. Beim Debuggen stand das Programm soviel ich weiß bei der Start-Funktion. Aber wie gesagt, sind wir mit unserem Latein dort langsam am Ende. ^^

MfG Bastian

Noch keine Idee?

OK, pass auf:
ich schaue es mir nachher nochmals genauer an.

Vorerst solltet ihr mal die Statuskodes auswerten, die die TWI-Hardware nach jeder Aktion generiert! Alle Werte sind im Datenblatt mit genauer Beschreibung dokumentiert.

Habt ihr mal meine Bibliothek versucht?
Die habe ich schon in zwanzig Projekten verwendet (allerdings mit Auswertung des Statusregisters!) und sie läuft 100% korrekt.

Ich schaue es mir nachher nochmals an, muss jetzt weg.

_________________

Problem lokalisiert:

Nach der Stop-Kondition wartet ihr wieder, dass TWINT gesetzt wird. Hätte man das Datenblatt gelesen (oder meine Lib genommen...) wäre das nicht passiert; siehe Datenblatt (Using the TWI):

"Note that TWINT is NOT set after a STOP condition has been sent."

Ändert also euren Teil

void stop_i2c()
{
 TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);		// Stoppe I2C
 while (!(TWCR & (1<<TWINT)));				// Warte, bis fertig
}

nach

void stop_i2c()
{
 /* Stoppe I2C */
 TWCR = (1<<TWINT)|(1<<TWEN)|(1<<TWSTO);
}

Und nach dem Stop sollte er nicht mehr bocken.
wenn es danach nicht geht, nochmals genau kontrollieren.
Wenn immer noch nicht, dann melden, weil ich nicht weitergesucht habe (Zeit).

P.S.: auch wenn es unter C meist geht, klassische C-Kommentare sind nur mit der /* */-Schreibweise möglich, der Doppelschrägstrich kommt aus C++ und sollte in reinen C-Programmen nicht benutzt werden.
Gut gemeinter Tipp am Rande

Edit:
Habe aus Neugierde nochmals reingeschaut und in der Funktion void i2c_senden(char) habt ihr vergessen, TWINT zu pollen, bis die Daten abgesendet wurden.

Hier mal meine Funktion:

void
i2c_transmit(uint8_t const data)
{
	TWDR = data;
	/* und Daten abschicken */
	TWCR = 1<<TWINT|1<<TWEN;
	while( !(TWCR & (1<<TWINT)) );
};

Weiter habe ich jetzt aber wirklich nicht geguckt

_________________



[ Diese Nachricht wurde geändert von: DonComi am  7 Apr 2010 22:46 ]

Supi!!!! Ein rießen Danke an dich!!! Werden es nächste Woche gleich ausprobieren. Müssen gerade leider noch an einem SPS-Projekt für die Schule arbeiten.^^

MfG Bastian

Vielen Dank nochmal! Es waren genau die Fehler, die du mir aufgezeigt hast! Jetzt funktioniert alles!

MfG Bastian

_________________

Hallo, ich bin es mal wieder.^^

Mein nächster Schritt ist es nun, mehrere Atmega16 im Master-Slave-Modus zu betreiben und Daten auszutauschen. Hab mal gelesen, dass es durch Interrupts möglich ist einen Slave als Master zu setzen. Und sobald die Daten ausgetauscht wurden, er wieder in den Slave-Modus geht. Nur weiß ich leider nicht mehr, wo ich dies damals gelesen hab. Vielleicht kann mir ja von euch jemand auf die Sprünge helfen. Ich würde mich sehr freuen!

MfG Bastian


Edit:

Hab hier doch noch was gefunden.^^

https://forum.electronicwerkstatt.d......html

Weiß jemand zufällig, ob dies auch mit mehreren Atmegas möglich wäre? Also ich meine, dass ich z.B. 5 Atmegas habe, welche zwischen Master und Slave wechseln können und somit Schaltzustände übertragen.

[ Diese Nachricht wurde geändert von: terrorfreak am  3 Mai 2010 11:41 ]

Ja, gehen tut das schon, nur:
Die in deinem Link von mir hochgeladene Bibliothek implementiert nur die Schnittstelle zur Hardware, ohne die Statuskodes auszuwerten. Ich selbst habe die Bibliothek mittlerweile dahingehend verändert, dass Statuskodes ausgewertet werden und Fehler erkannt werden können.

Bei deinem speziellen Problem kann es passieren, dass zwei oder mehr Megas gleichzeitig versuchen, den Bus zu kontrollieren (vom Slave zum Master werden). Da ist Arbitrierung des Busses gefragt.

Du solltest mal ins Datenblatt gucken, da ist das beschrieben.

Du kannst auch versuchen, nur einen Master zu benutzen. Die zu übertragenden Daten werden zwar größer, aber es ist einfacher zu implementieren.

Was soll denn genau übertragen werden?

Achja,

Zitat :

dass es durch Interrupts möglich ist einen Slave als Master zu setzen.

Soso. Du solltest gründlicher lesen.

_________________

Oh, ok.^^ Das klingt schwierig^^. Ich wollte eigentlich im Rahmen meiner Technikerarbeit zwischen mehreren Atmegas paar Datenpakete per TWI hin-und herschicken und dadurch dann an einem Port paar Leds blinken lassen und noch auf Knopfdruck die Temperatur anzeigen lassen. Es war eigentlich gedacht damit zu zeigen, dass man mit Atmegas über TWI eine Art Mini-HausBUS machen kann. Aber ist es dann einfacher, wenn ich einen Atmega als Master definiere und der Rest dann im Slave ist? Muss der Master die Slaves dann periodisch abfragen?

Mit der Umschaltung von Master zu Slave wärs schon das "Sahnehäubchen" gewesen, aber wenn ihr mir davon abratet, vertraue ich da euch. Ich denke es ist besser eine Technikerarbeit zu haben, die Funktioniert, anstatt eine, die theoretisch funktionieren könnte.^^

Gruß Bastian

Hallo Bastian,

Zitat :

Ich wollte eigentlich im Rahmen meiner Technikerarbeit zwischen mehreren Atmegas paar Datenpakete per TWI hin-und herschicken

Geht ja prinzipiell - nur ist der I2C-Bus eigentlich als Einmaster-Bus konzipiert worden. Multimaster-Systeme gehen mittleweile auch - siehe Arbitrierung!

Zitat :

Es war eigentlich gedacht damit zu zeigen, dass man mit Atmegas über TWI eine Art Mini-HausBUS machen kann.

Dazu ist I2C resp. TWI aber nicht gedacht und geeignet. I2C bedeutet "Inter Integrated Circuit" und dient der Kommunikation vieler IC in einem System, meistens sogar nur auf einer Platine, maximal aber nur im Gerät. Selten ist er nach außen geführt.
Für sowas eignet sich dann eher RS485. Das ist ein Bus für viele Knoten, und die Teilnehmer können einfach so Daten auf den Bus schreiben oder davon lesen. Kollisionen müssen dann per Software erkannt- und gehandelt werden.

Zitat :

Aber ist es dann einfacher, wenn ich einen Atmega als Master definiere und der Rest dann im Slave ist? Muss der Master die Slaves dann periodisch abfragen?

Kommt auf die Datenmenge an und die Zeit, in der sie maximal verarbeitet werden müssen. Periodisch abfragen wäre eine Möglichkeit (Polling), vor allem dann, wenn zeitliche Versätze nicht kritisch sind (ein Tastendruck kann auch 10ms später ausgewertet werden).
Ist die Anzahl der Slaves zur Compile-Zeit fest? Wenn ja, ist es einfach zu implementieren. Man könnte dann auch mit Hardware-Interrupts arbeiten: ein Slave löst über ein Interrupt-Signal beim Master ein IRQ aus und dieser fragt dann erst ab. Da gibts viele Möglichkeiten - aber allesamt für Hausbusse ungeeignet!

Zitat :

Mit der Umschaltung von Master zu Slave wärs schon das "Sahnehäubchen" gewesen,

Ist doch in meiner Lib sogar als expliziter Befehl vorhanden.
Man kann dir nur helfen, wenn du selbst ein wenig mitdenkst. Die Hinweise auf meine Lib waren ja nicht zum Spaß.


_________________

Gut, also mit der Master-Slave-Umschaltung is es mir glaub ich noch zu schwer.^^ Ich denk dafür reicht mein Anfängerwissen leider noch nicht aus. Die Zeit in der die Ausgänge gesetzt werden sollen is jetzt nicht so Elementar. Ich wäre schon froh, wenn ich die Reine Kommunikation hinbekomme.^^ Ich werd einfach mal versuchen einen Atmega als Master zu definieren, der periodisch die anderen abfragt. Habt ihr zufällig ein wenig Lesestoff, wie ich mich in die Sache ein wenig reinlesen kann? Also Beispielprogramme oder einfache Tutorials oder so wären mir eine super Hilfe.

Und danke nochmal DonComi, dass du so nem blutigen Anfänger wie mir hilfst.

Gruß Bastian

Moin,

Im Datenblatt werden die Dinge schon gut erklärt, inkl. Statuskodes und Beispiel-Programmen.


_________________