Hallo zusammen! ich hab ein kleines i2c problem: ich habe einen atmega8 als master und einen attiny2313 als slave. die kommunikation funktioniert wunderbar wenn ich beide auf 4mhz laufen lasse. wenn ich allerdings den atmega auf 16mhz und den tiny auf 8mhz laufen lasse dauert die kommunikation ewig oder funktioniert gar nicht... hat jemand eine idee woran das liegen könnte? ich verwende im master die I2C Lib von Peter Fleury und im slave die usi / twi lib von jtronics Danke! johnny
Wenn Du beide auf UNTERSCHIEDLICHEN Taktfrequenzen laufen lässt, musst Du natürlich das Timing, Pausenzeiten und ggf. Timereinstellungen für eventuelle Interupts ganz neu justieren, das ist Dir doch hoffentlich klar? Kenne zwar beide Libs nicht, die Du da verwendest, aber wenn von einem 1:1 Timing auf ein 2:1 Timing umgestellt wird, kann das ja wohl kaum ohne Anpassung aller Zeitparameter klappen.
Bödefeld schrieb: > Wenn Du beide auf UNTERSCHIEDLICHEN Taktfrequenzen laufen lässt, musst > Du natürlich das Timing, Pausenzeiten und ggf. Timereinstellungen für > eventuelle Interupts ganz neu justieren, das ist Dir doch hoffentlich > klar? Mir ist das nicht klar. IIC ist ein asynchroner Bus. Was sein kann, dass die LIBs nicht 'ausgereift' sind.
Willi schrieb: > Mir ist das nicht klar. IIC ist ein asynchroner Bus. I²C ist asynchron? Wozu ist dann die Takteleitung da?
STK500-Besitzer schrieb: > I²C ist asynchron? Wozu ist dann die Takteleitung da? Sorry, da ist ein 'a' zuviel. Natürlich synchron, weshalb das Timing unkritisch ist und sich nach dem langsamsten Teilnehmer richtet.
> Sorry, da ist ein 'a' zuviel. > Natürlich synchron, weshalb das Timing unkritisch ist und sich nach dem > langsamsten Teilnehmer richtet. Nö. Sooooo unkritisch ist das Timing ganz sicher nicht. In solchen Libs, die irgendjemand mal geschrieben hat, kann es nämlich sehr leicht passieren, dass Latenzzeiten nicht eingehalten werden, die bei der Entwicklung nichtmal auffallen, weil man z.B. auf sehr kleiner Taktfrequenz entwickelt hat. Erst bei hoher Taktfrequenz stimmen dann Setup- und Latenzzeiten nicht mehr. Das hat mit dem eigentlich Protokoll garnichts zu tun, ich rede hier vom internen Timing der IO-Prozeduren.
Jtronics schreibt unter Infos: You have to change the CPU Frequenz in the files main.c and makefile !!!! http://www.jtronics.de/avr-projekte/library-i2c-twi-slave-usi.html Ähnliches findet man auf Peter Fleurys Seite: Adjust the CPU clock frequence F_CPU in twimaster.c or in the Makfile when using the TWI hardware implementaion. http://homepage.hispeed.ch/peterfleury/group__pfleury__ic2master.html Aber ignorier das ruhig, ist ja synchron. I2C ist auch nur aus Spaß auf 100kHz (400kHz high speed) beschränkt.
Willi schrieb: > weshalb das Timing unkritisch ist und sich nach dem > langsamsten Teilnehmer richtet Wenn der Master mit 4facher Rate SCL taktet, der Slave aber nur mit 2facher Rate samplen kann, kann es schon sein, dass die Übertragung ausser Takt kommt, auch bei völlig korrekten Libs. Also, den Libs die richtige Quarzfrequenz verraten, oder die Timingparameter von Hand anpassen.
F_CPU habe natürlich korrekt eingestellt bei beiden aber ich werde mir die libs noch mal genauer ansehen. Danke euch schon mal für die Hilfe!
Johnny schrieb: > die libs noch mal genauer ansehen. Schau Dir doch lieber erstmal die Übertragung an, dann weisst Du, nach was Du in den Libs suchen musst.
Treiber zu klein bzw. Kapazität der Leitungen zu hoch, Pullup zu hochohmig
Beide Libs müssen das clock stretching bentuzen. Der Slave braucht es, um dem Master zu sagen, wann er fertig ist. Und der Master muß solange warten. Das HW-I2C macht es immer, aber das USI hat einen Mode, wo es nicht erfolgt. Die beiden Pullups (1,8 .. 4,7k) sind drann? Peter
Mit welcher Taktfrequenz/ Übertragungsgeschwindigkeit willst du die Daten zwischen beiden übertragen? Normalerweise musst du nichts außer die CPU Frequenz bei beiden im makefile ändern. Die Libs funktionieren auch bestens miteinander. Habe ich selber getestet auch bei unterschiedlichen CPU Frequenzen. Beachte bitte auch, dass eine Übertragungsgeschwindigkeit vonn 400Khz bei 8Mhz nicht möglich ist.
Jetzt hab ich geschafft der Fehler lag der definition von F_CPU in der lib von Peter Fleury. Hier gibt es:
1 | #ifndef F_CPU
|
2 | #define F_CPU 4000000UL
|
3 | #endif
|
allerdings habe ich F_CPU überhalb der Includes selbst mit 16000000 festgelegt. Deswegen dachte ich es dürfte keine auswirkung haben. Wenn ich in der lib dann F_CPU auch auf 16000000 setzte funktioniert es wunderbar.... Danke für die Hilfe!! Johnny
Nee, das kann so nicht sein. Du musst F_CPU in der Kommandozeile setzen, also im Makefile oder in den Projekteinstellungen von AVR-Studio. Denn twimaster.c wird doch getrennt übersetzt. Die Quellen von Fleury muss man hierzu nicht anfassen... Gruß Hermann-Josef
Ah ok ich gebs als Symbol mit dann funktioniert das... Gut zu wissen das erklärt es natürlich!
johnny schrieb: > Hier gibt es: > #ifndef F_CPU > #define F_CPU 4000000UL > #endif Das ist ganz falsch! Wenn eine wichtige Systemkonstante fehlt, dann darf man sie doch nicht einfach durch Lottozahlen ersetzen. Wenn, dann so:
1 | #ifndef F_CPU
|
2 | #error !!! Error: F_CPU not defined !!!
|
3 | #endif
|
Peter
Aber dein Problem ist ja auch in der Anleitung von Herrn Fleury beschrieben. Denn du sollst ja F_CPU in der Datei twimaster.c anpassen wenn du es nicht im makefile angibst. Klaus2m5 schrieb: > Ähnliches findet man auf Peter Fleurys Seite: > Adjust the CPU clock frequence F_CPU in twimaster.c or in the Makfile > when using the TWI hardware implementaion. Aber schön das das Problem gelöst ist. ... wieder einer mehr glücklich ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.