Hallo, bei der Kommunikation über UART sind ja Quarze für das präzise Timing notwendig. Trifft das auch für TWI zu? Ich plane zwei Mikrocontroller alle 10 ms nur ein paar Byte (< 8) übertragen zu lassen, also die Datenrate ist ja nicht so dramatisch. Kann ich dafür noch den internen Oszillator verwenden? Gruß, Georg
Stimmt, ich habs vergessen, der Master liefert ja den Takt gleich mit. Danke!!!
Hallo... Ich arbeite mit dem My AVR MK2 Board ich besitze einen TWI PORTExpander und eine TWI Echtzeituhr, welche ich für mein project benötige... Ich brauche aber einen Kompletten Port der Direkt vom ATMega 8 kommt... Um Port B gebrauchen zu können muss ich mir aber erst sicher sein das ich den 3,868400 raus nehmen kann... Ich benötige eigentlich keine wahnsinnige Schnelligkein, jedoch brauche ich die serielle schnitstelle mit einer BAUD rate von 9600... Reicht da der Interne 1Mhz Quarz? oder gibt es im seriellen bereich zu grosse fehler? PortD Kann ich nicht benutzen da ich die LCD Anzeige brauche und Port C kann ich nicht benutzen da ich den TWI brauche (PC4+5) >> Ist es möglich die LCD Anzeige über den Port B Laufen zu lassen? ann mir jemand Helfen? Ich danke vielmals.
Also serielle Übertragung ohne Quarz kannste vergessen, der interne ist zu ungenau (abhängig von Temperatur, Versorgungsspannung). Das mit dem Display auf den anderen Port zu schieben würde prinzipiell gehen, aber du wirst wahrscheinlich das passende MyAVR-LCD-Modul verwenden und das müsstest du komplett ummodeln.
Mike Dupo schrieb: > Ich benötige eigentlich keine > wahnsinnige Schnelligkein, > [...] > > Reicht da der Interne 1Mhz Quarz? Wenn du so eine wahnsinnige Schnelligkeit brauchst, warum nimmst du da nicht wenigstens den internen 8Mhz Takt. Uart mit 9600Baud sollte auch ohne Quarz funktionieren. Edit: Hab zumindest noch nie Probleme damit gehabt. (Für debug-Ausgaben bei Zimmertemperatur) Edit: bei 8Mhz, hat er immerhin über 800 Takte Zeit das Bit zu treffen. So falsch kann der Quarz gar nicht gehen.
Vlad Tepesch schrieb: > Wenn du so eine wahnsinnige Schnelligkeit brauchst, warum nimmst du da > nicht wenigstens den internen 8Mhz Takt. Ich brauche "keine" wahnsinnige schnelligkeit, nur die Baud rate macht mir sorgen, ich sende 10 mal die Stunde eine Adresse von 15 Zeichen dadurch... mehr nicht. Ich dachte immer der interne Quartz hat nur 1 Mhz... Oder irre ich mich da???
Mike Dupo schrieb:
> Ich dachte immer der interne Quartz hat nur 1 Mhz...
Da kein Quarz im Atmel drin ist kann der keine 1 MHz haben!
Es ist ein Oszillator mit z.B. 8 MHz und bei Auslieferung
gesetzter Fuse CLKDIV die durch 8 teilt.
Näheres im Datenblatt !
avr
Sag mal, TWI ist doch die Atmel-Bezeichnung für I2C. Da wird doch der Takt auf der Clock-Leitung mitgeliefert, einer ist Master, der andere ist Slave. Ich würde erwarten, daß das auch per RC-Oszillator geht. HTH, Joerg
Vlad Tepesch schrieb: > bei 8Mhz, hat er immerhin über 800 Takte Zeit das Bit zu treffen. > So falsch kann der Quarz gar nicht gehen. Das glaubst du vielleicht. Besser nochmal Datenblatt lesen ---> 7,3 bis 8,1 Mhz ist der ab werk kalibriert. Ich würde das OSCCAL – Oscillator Calibration Register nutzen, da kriegste ne bessere Genauigkeit hin. Dann klappts auch sicher mit der USART, ohne Fehler. Für TWI ist die Genauigkeit egal, da ja wie oben schon erwähnt durch den Master Clock das Signal synchronisiert wird. Gruß
Vlad Tepesch schrieb: > > Uart mit 9600Baud sollte auch ohne Quarz funktionieren. > > Edit: > Hab zumindest noch nie Probleme damit gehabt. > (Für debug-Ausgaben bei Zimmertemperatur) Vermutlich wird deine Zimmertemperatur nicht allzuweit von den Bedingungen bei der Werkskalibrierung (25 Grad) abweichen. Die Spannung hat zwischen 3V (Werkskalibrierung) und 5V eher wenig Einfluss auf die Frequenz (siehe Datenblatt). Unter diesen Bedingungen wird die Abweichung dann in der Regel deutlich kleiner als die erlaubten 10% sein, weswegen das dann noch hinhaut (für reine Debug-Ausgaben ist das ja auch OK, man darf sich nur nicht beschweren, wenn es mit einem einzelnen Exemplar mal nicht funktioniert). > bei 8Mhz, hat er immerhin über 800 Takte Zeit das Bit zu treffen. > So falsch kann der Quarz gar nicht gehen. So einfach ist das nicht. Der Pegel auf dem USART-RX-Pin wird immer in bestimmten Zeitfenstern eingelesen. Diese Fenster liegen zwar >800 Takte auseinander, die Zeitfenster sind aber trotzdem nur verhältnismässig wenige Takte gross (genaugenommen dürften die sich eigentlich nicht unterscheiden, egal ob der Prozessor nun mit 1 oder mit 8 MHz läuft, der USART läuft schliesslich in beiden Fällen mit dem gleichen Takt, nur der Teiler zum Systemtakt ist ein anderer). Ausserdem gibt es auch noch die Senderichtung, wo der Zeitpunkt, an dem der Empfänger (PC) den Pegel einliest, nicht beeinflussbar ist. Erschwerend kommt hinzu, dass der RC-Oszillator ja nicht wild hin- und herschwankt, sondern relativ gleichförmig "falsch" geht, weshalb sich die Abweichung auch nicht rausmittelt. Dementsprechend summieren sich die Abweichungen schnell auf, nach nur 10 Bits (Start, 8x Daten, Stop) kann das schon eine komplette Bitdauer sein (10%*10 = 100%)! Unter diesen Bedingungen kann von einer sauberen Übertragung keine Rede mehr sein. Wenn man den internen Oszillator selbst nachkalibriert (vielleicht mit Hilfe der TWI-RTC), kann man 1% Genauigkeit hinbekommen, damit kann man dann auch RS232 machen. Bei relativ grossen Intervallen (die Rede war ja von 10x pro Stunde, also ca. alle 6 Minuten) könnte man auch jeweils immer direkt vor einer Übertragung eine Kalibrierung vornehmen, um schwankende Umgebungstemperaturen auszugleichen. Je nach Wichtigkeit der Daten aber trotzdem noch ein Protokoll mit Checksummen drüberlegen, um Übertragungsfehler abzufangen! Zum Problem vom Anfang des Threads: Warum ist denn überhaupt unbedingt ein kompletter Port am Stück notwendig? So aufwendig (auch im Sinne von Prozessortakten) ist es nun auch wieder nicht, den 8 Bit-Wert für die Ausgabe am Schluss auf zwei IO-Ports aufzuteilen (z.B. Bits 0-5 auf PB0-PB5 und Bits 6 und 7 auf PC0 und PC1, dann ist das schnell erledigt: PORTB = (PORTB&0xC0)|(tmp&0x3f); PORTC = (PORTC&0xFC)|(tmp>>6);, ggf. noch mittels cli(), sei() Interrupt-fest machen). Einlesen geht sogar noch schneller, falls es Inputs werden sollen. Wenn die zusätzlichen Takte ein Problem sein sollten, kann man immer noch einen schnelleren Quarz nehmen, 3,8 MHz ist ja noch weit von den Limits des AVR entfernt. Andreas
Andreas Ferber schrieb: > > Vermutlich wird deine Zimmertemperatur nicht allzuweit von den > Bedingungen bei der Werkskalibrierung (25 Grad) abweichen. Die Spannung > hat zwischen 3V (Werkskalibrierung) und 5V eher wenig Einfluss auf die > Frequenz (siehe Datenblatt). Unter diesen Bedingungen wird die > Abweichung dann in der Regel deutlich kleiner als die erlaubten 10% > sein, weswegen das dann noch hinhaut (für reine Debug-Ausgaben ist das > ja auch OK, man darf sich nur nicht beschweren, wenn es mit einem > einzelnen Exemplar mal nicht funktioniert). Ups, falsches Datenblatt (ATmega88) erwischt. Beim ATmega8 ist die Frequenz deutlich stärker von Vcc abhängig, und Angaben zu den Bedingungen bei der Werkskalibrierung konnte ich auf die schnelle keine finden. Andreas
Hallo, zur ursprüngleichen Frage zurück. TWI / I2C ist eine Synchrone Datenübertragung. Solange Du die Minimalabständer der Zustandsänderungen der einzelnen Signale zueinaner einhälst, ist das Timing ziemlich unwichtig. Gruß Tom
@Andreas Ferber Danke für die ausführliche Erklärung! Hatte ich wohl bisher immer Glück, aber wie gesagt, ich hatte den AVR nicht unter extremen Umweltbedingungen betrieben
Hallo, auch ich sag danke für die lehrreichen worte... ich möchte nur eine Tastenfeldabfrage machen und da ich in Bascom programmiere, kam mir der befehl getadc gelegen. ich dachte so könnte ich mir as leben vereinfachen, scheint dann aber nicht so zu sein.. dann werde ich die abfrage doch anders programmieren müssen. MFG Hero
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.