Hallo, ich sitze seit Tagen an diesem Problem. Ich habe einen DS1307 über I2C an einem Atmega128. Sobald ich den externen Quarz mit 16Mhz einstelle funktioniert das Ansprechen der Uhr nicht mehr. Wenn ich den internen 8Mhz Quarz benutze läuft alles super. Der I2C soll wie im Datenblatt mit 100KHz laufen. Die Taktrate ist auch im Pogramm definiert F_CPU 16000000UL Ich habe extra die oft benutzte Peter Fleury Lib eingearbeitet und diese macht die gleichen Probleme wie meine vorherige Variante. Sobald ich alles auf 8Mhz stelle läuft die Uhr. Ich habe auch noch eine RS232 Verbindung zum PC diese läuft mit beiden Taktraten. Der DS1307 hat auch seine Pullups (fertige Platine aus I-Net). Irgendwo ist der Fehler versteckt! Gruß Nook
Sicher, dass F_CPU auch "richtig" definiert ist? Denn in der TWI-Master wird es ggf. nochmal auf 8MHz definiert
1 | |
2 | |
3 | |
4 | |
Setze ggf. mal SCL_CLOCK auf die halbe Geschwindigkeit. Du hast nicht zufällig CKDIV8 an? Dann würde der AVR beim internen Quarz real mit 1 MHz laufen, wohingegen mit gesetztem CKDIV8 und externem 16MHz der AVR mit 2MHz laufen würde. Welchen du AVR du verwendet hast sowie jeglichen Quellcode hast du uns ja dummerweise verschwiegen.
ja, dort hatte ich auch die 16mhz eingestellt. ich hab eben mal 50KhZ ausprobiert. geht leider auch nicht.
Wie siehts mit CKDIV8 aus? Und wo bleibt der Quellcode? Wie groß sind deine Pullups an SDA und SCL? Erzähl bloß nicht zu viel!
ohh was ist CKDIV8 ???? quellcode kann ich erst wieder morgen schicken. Pullups 3.3K. Den RTC habe ich: http://www.ebay.de/itm/I2C-RTC-DS1307-AT24C32-Real-Time-Clock-Realtime-Module-Batterie-for-AVR-ARM-PIC-/320854497094?pt=Bauteile&hash=item4ab46b1746
CKDIV8 ist ein Fusebit (hat nicht jeder AVR, aber die neueren wie ATmega88). Standardmäßig ist CKDIV8 immer an. Aber ich glaube der Atmega128 hat kein CKDIV8 (sorry hatte erst überlesen dass du den 128er hast)
ich glaub es sind die Pullups. 3.3Kohm ist wohl zu wenig. laut diversen Foren sollte diese 10K seien. Es hatten wohl einige auch Probleme mit 4.7K. dies kann ich haber leider erst morgen testen.
3.3k ist voll OK. Je schneller du übertragen willst um so kleiner muss er sein. 4,7k sind so quasi standard für 100khz. Bei 400khz sollte man langsam kleinere nehmen aber das kann der 1307 eh nicht. Bis 3mA darf man machen, bei 5V also ~1,7k
Timmo H. schrieb: > /* define CPU frequency in Mhz here if not defined in Makefile */ > #ifndef F_CPU > #define F_CPU 8000000UL > #endif Sowas ist natürlich großer Mist. Da darf man sich über Fehlfunktion nicht aufregen. Wennschon, dann nur so:
1 | |
2 | |
3 | |
Such mal im gesamten Quellcode (*.c, *.h) nach "F_CPU", ob da irgendwo son Mist auftaucht und lösche ihn umgehend.
Welche Version der I2C Routinen vom P.Fleury hast du genommen? Die Assembler Version oder die C-Version? In der Assembler-Version ist die Realisierung des Timings ... nicht so toll. Da muss man eingreifen, denn es sieht nicht so aus, als ob Peter da eine automatische Anpassung vorgesehen hat. Die C-Version sollte allerdings ok sein, solange F_CPU auch korrekt gesetzt ist. Sicherheitshalber würde ich mal bei #ifndef F_CPU #define F_CPU 16000000UL #endif den #ifndef Kram weglassen, nicht dass dir ein im Makefile angegebener Wert da einen Strich durch die Rechnung macht und der Code gar nicht mit 16Mhz rechnet. Früher hat man das gerne mit dem #ifndef gemacht. Aber im Laufe der Zeit hat sich herausgestellt, dass das gar nicht so schlau ist. Wenn F_CPU nicht gesetzt ist, dann ist das als Fehler zu betrachten und nicht als Aufforderung einen Default-Wert zu benutzen. Edit: PeDa war schneller
@Peter Dannegger: ich habe nur selbst in der Hauptdatei F_CPU. Aber auch testweise in die twimaster reingeschrieben. in der makefile sollte es nicht stehen, oder macht AtmelStudio, dass von selbst? Beim AVR Studio musste man es extra angeben. ich benutze die C Version die aktuelle gestern von der Webseite geladen und eingespielt. zudem habe ich die abläufe mit meiner version aus dem großen internet verglichen.
Nookie Nook schrieb: > in der makefile sollte es nicht stehen, doch. Eigentlich sollte es genau dort, und nur dort stehen. Denn nur so ist defnitiv sicher gestellt, dass alle C-Files auch tatsächlich immer mit dem gleichen Wert für F_CPU rechnen. > und eingespielt. zudem habe ich die abläufe mit meiner version aus dem > großen internet verglichen. Alles schön und gut. Aber wenn dein Programm mit einer realen Taktfequenz von 8Mhz und einer Einstellung for F_CPU von 8000000 funktioniert und du dann den µC auf 16Mhz umfused und als Ausgleich dafür den F_CPU auf 16000000 setzt, dann muss (wenn alles richtig programmiert ist), wieder das gleiche Zeitverhalten herauskommen. Und dein Problem dürfte ein Timingproblem sein. Irgendwas ist zu schnell. Und das kann wiederrum nur sein, wenn irgendwo irgendwelche Warteschleifen oder Timereinstellungen nicht korrekt von F_CPU abhängig gemacht wurden, bzw. wenn Portpins zu schnell hintereinander (ohne Wartezeit dazwischen) gesetzt oder gelöscht werden.
FUNKTIONIERT! Icd hab die 3.3K Widerstände mit 10K ersetzt! Danke für eure Mühe!
Gast
#3014721
>FUNKTIONIERT! > >Icd hab die 3.3K Widerstände mit 10K ersetzt! Lächerlich, das muss auch mit 3k3 funktionieren. Genau genommen sogar besser weil die Flanken steiler werden. Nimm mal deine 3k3 und miss mal nach ob das nicht 330 oder 33 waren.
Gast
#3014728
>Nimm mal deine 3k3 und miss mal nach ob das nicht 330 oder 33 waren.
Oder 33k, 330k.
Nookie Nook schrieb: > FUNKTIONIERT! > > Icd hab die 3.3K Widerstände mit 10K ersetzt! Das beweist nur, daß ein Timingfehler vorliegt. Anstatt den Fehler zu beheben, verlangsamst Du die Anstiegsgeschwindigkeit durch einen größeren Pullup. Dein Verhalten entspricht etwa folgendem: Du fährst 60 und kommst in eine 30-Zone. Anstatt nun den Gang runter zu schalten, ziehst Du die Handbremse an. Das eine ist nicht gut für Dein Auto, das andere ist nicht gut für die Zuverläsigkeit Deines Programms. Man sollte daher immer die Ursache beseitigen und nicht die Wirkung bekämpfen. Peter
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.