Hallo, ich habe einen Atmega128, ein EEPORM und einen LM75. Der LM75 ist noch nicht da, darum sieht meine Schaltung aktuell wie auf dem Bild gezeigt aus. Ich nutze die I2C-Bibliotek von Codevision. Leider kann ich mit dem Oszi keinen Clock messen(triggern) und auch die SDA-Leitung ist dauerhaft auf 5V. Kann das an der offenen Leitung bzw. den Leitungslängen liegen(insgesamt ca. 20cm je SCL- und SDA-Leitung)?? Was könnte ich noch testen?!
Hallo, bei 20 cm sollte es auch bei einem Takt von 400 KHz noch keine Probleme geben. Den Clock solltest Du triggern können. Gerade das Signal hat ja einen konstanten Rechteck. Der SDA zappelt meist herum. Gruss Klaus.
Wie testest du denn? Ich persönlich empfinde die TWI-Schnittstelle vom ATmega etwas gewöhnungsbedürftig, die Implementierung ist nicht ganz trivial. Erzeugst du eine START-Condition? Die solltest du eigentlich sehen.
Hallo, ich verwende nicht die Atmel TWI, sondern die I2C-Bibliotek von Codevision. Diese funktioniert in einem anderen Projekt auch problemlos. Ich messe nun, dass die Signale SCL und SDA vom Atmega aus passen, doch die Antwort vom EEPROM ist "dauerhaft" auf high. Mit dem Oszi sehe ich zwar, dass das EEPROM den Pegel runterziehen will, dieser schafft es aber nicht. Geht Bitweise ca. auf 4,7V. Kennt ihr sowas? Was kann ich nun weiterhin tun? Das Protokoll habe ich überprüft :-(
> Mit dem Oszi sehe ich zwar, dass das EEPROM den Pegel runterziehen will, > dieser schafft es aber nicht. Geht Bitweise ca. auf 4,7V. Die I2C Portpins am Atmega auf Open-Collector gestellt ? HTH Jörg
Rückzug, vielleicht will das EEPROM auch gar nicht anworten, da auch
wenn ich von meinem Atmega 0xFF sende, diese schmallen Pics auf 4,7V
kommen
> der Baustein rührt sich einfach gar nicht.
Jochen schrieb: > da auch > wenn ich von meinem Atmega 0xFF sende, diese schmallen Pics auf 4,7V > kommen Könnten vielleicht auch nur Überkopplungen sein...!?
Der I2C Bus wird sowieso nicht korrekt abgeschlossen. Daher ist es auch egal, ob am Kabelende jemand hockt oder nicht.
Also SDA und SCL hab ich jeweils DDR=0 und PORT=0, so war es auch im Beispiel und müsste passen. Was meinst du mit Überkopplungen?
10 k-Widerstände sind zu hoch, das geht zwar oft, oft aber auch in die Hose. Von Philips/NXP sind spezifiziert bei 5 V: 1.5-1.8 k, 2.7 k geht fast immer noch,
Hallo, 10k Pullups sind nicht zu hoch. Ich meine bei der CC2 sind sie z.B. standard. Und bei MSP430F2013 haben die inneren Pullups sogar noch höhere Werte. Man kann sich aber die Flanken der Signale per Oszi ansehen. Sind sie zu arg verschliffen muss man die Pullups eben verringern. Ein Wert von 2,7K oder 2,2K ist da gut vertretbar. Auf 1,5k würde ich nicht gehen. Aber bei 20cm Leitungslänge dürften noch keine kapazitiven Lasten auftreten die nennswert sind. Mit Pullups von 2,2k schafft man locker einige Meter. Einen PCF7574 habe ich mal bei 100KHz über eine Kabeltrommel an 50m Leitung betrieben. Ein DS1631 macht da schon viel früher nicht mehr mit. Was mir noch einfällt. Mein Angaben beziehen sich auf 5V. Sollte der Bus mit 3,3V betrieben werden sieht es anders aus. Gruss Klaus.
Ist die Frage, ob du den EEPROM überhaupt korrekt adressierst? Welcher EEPROM ist es? Hat der Hardware-Adress-Eingänge? Ich finde die 10k auch ziemlich hoch, noch dazu, da man keinen Einfluss auf das Timing in den CodeVision-Routinen hat (ausser ne falsche Taktfrequenz anzugeben, was aber wieder andere blöde Auswirkungen hat). Benutze deshalb die mitgelieferten Routinen nicht mehr. Versuch mal 3k3.
also wenn scl nicht kommt ist die Adressierung der Peripherie ziemlich wurst. Dann stimmt was mit der Initialisierung der Pins vom AVR nicht. nimmste Hardware IIC oder Software? Bei Software, welche Pins? JTAG - Fuse?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.