Hallo, ich hab mir das evolution board von pollin geholt, soweit bin ich damit auch ganz zufrieden. nur ich bekomme es einfach nicht hin eine uart mit einem terminal prog zu realisieren. hat es von euch schon mal jemand versucht gruß xeus
Du sollst nicht unbedingt eine gerade Anzahl an MegaHerz haben. z.b: 16 Mhz, 8Mhz ... Schau mal in das Datenblatt zu deinem AVR, da sollten die Frequenzen aufgelistet sein.
bei dem board ist ein ext. quarz von 8 mhz dabei, mit dem müsste es doch eigentlich funzen. hat keiner ne idee von euch
ja, aber wie ist das gemint mit dem quarz, wenn da 8 mhz drauf sind müsste es doch eigentlich auch mit 8 mhz funktionieren. habs auc schon mit dem int. 1mhz versucht, klappt leider auch nicht
Hallo xeus, ok, Du hast einen 8 MHz-Quarz auf dem Board. Welche Baudrate hast Du denn eingestellt. Und mit welcher Programmiersprache programmierst Du? Gruß Gerd
Die Quarzfrequenz sollte nach dem Teilen möglichst genau die Frequenz egeben, die Du am PC eingestellt hat, also ohne Fehlerrate, also müßte Deine Quarz schon ein wenig krummhertzig sein, z.B. 7,3728 MHz.
ich programmiere mit avr bascom, hab schon mit 4800, 9600 versucht, aber mit keier klappt es. das komische ist, dass er nicht mal bitfolgen sendet. normalerweise, müsste er doch auch bei falscher baudrate bitfolgen senden, oder? gruß xeus
Hallo xeus, schau' mal im Bascom unter Options->Compiler->Communication nach. Da muß neben der gewünschten Baudrate auch die Taktfrequenz (8MHz) eingetragen werden. Basom rechnet Dir dann den Fehler aus. Bei 8 Mhz kannst Du Übertragungsraten bis 38400 Baud nehmen, der Fehler liegt bei 0,16 %. Wichtig ist auch, daß Du in den Fuse-Bits die richtige Taktquelle wählst. Nur weil Du außen 8 MHz stecken hast, muß der Controller nicht auf 8 Mhz laufen. Vielleicht läuft er auf internen 1 MHz. Gruß Gerd
das ist mir schon klar, komisch ist nur, das mein m8 der mit 1mhz läuft auch mit 4800 läuft. warum klappt das selbe nicht mit einem m16?
Der interne RC-Oszillator ist halt nicht so genau. Ich glaube mich dunkel an bis zu 10 Prozent Fehler zu erinnern. Kann mich aber auch täuschen. Gruß Gerd
ja, aber müsste ich nicht selbst mit einer fehlerhaften einstellung einen bitschrott bekommen. wenn ich z.b mit dem m8 eine falsche baudrate einstell erhalte ich bitmüll. gruß xeus
tja, leider hat sich im Schaltplan ein kleiner Fehler eingeschlichen. Tx und Rx Leitung am UART wurden vertausch, so das der RS232 Pegelwandler blockiert. Das bedeutet Pin 10 und 12 müssen am Pegelwandler vertauscht werden. Dann läufts. Achtung: Ohne gesetzte CLOCK Bits läuft der ATmega nur mit 1MHz. Wer kennt die richtige Einstellung für 8Mhz?
Angehängte Dateien:
-
LOCK_FUSE_BITS.jpg
24 KB
Hallo, ich benutze yaap und habe folgende Konfiguration mit einem externen Quarz.
Wer will denn 8MHz für USART nutzen? Nehmt einen Baudratenquarz! Dann funktioniert RS232 auch ohne Fehler. ...
also hannes, laut atmel datenblätter kann der Atmega16 einen externen Quarz bis zu 16 Mhz vertragen und daraus die Standard UART Datenraten erzeugen. Der Punkt ist aber, dass der UART TX Ausgang auf den RX Ausgang des Pegelwandlers gelegt ist. Das hier ist aber die richtige Konfiguration: Atmel => Pegelwandler => RS232 TX(out) => Tx(in) Tx(out) => Tx RX(in) <= Rx(out) Rx(in) <= Rx Leider wurde dies zumindest auf meiner Platine vertauscht und sah so aus: Atmel => Pegelwandler => RS232 Tx(out) => Rx(out) Tx(out) => Tx Rx(in) <= Tx(in) Rx(in) <= Rx Und da leider nichts funktioniert, wenn Ausgang mit Ausgang und Eingang mit Eingang verbunden ist, dann hilft auch kein Baudratenquarz. P.S. Nach dem Vertauschen der Tx und Rx Leitung zwischen Pegelwandler und Atmega16 lief alles perfekt.
Ich habe das Board nicht, kenne daher die Schaltung auch nicht. Ich wollte nur darauf hinweisen, dass man keine "glatten" Quarze (glatte Zahlen wie 4MHz, 8MHz...) für den AVR nimmt, wenn man die serielle Schnittstelle nutzen möchte. Dazu gibt es sogenannte "Baudratenquarze" mit (scheinbar) krummen Frequenzen. Schau dir mal die Baudratentabellen im Datenblatt genauer an, dann weißt du was ich meine. Nur mit diesen Baudratenquarzen werden auch längere Telegramme sicher übertragen. Mit 3,6864MHz, 7,3728MHz oder 14,7456 hast du bedeutend weniger Fehler als mit 4,0MHz, 8.0MHz oder 16,0MHz. Gruß... ...HanneS...
@leif: Was verwendest du für ein Kabel zum Verbinden, ein 1:1 oder Nullmodemkabel?
bin mir jetzt selber nicht so sicher. Muß aber erst zu Hause nachschauen. Der Fehler liegt aber darin, dass das Tx signal am Pegelwandler invertiert werden muss. Leider liegt dieses Signal auf einen Inverter Ausgang und da der Atmega16 auf dieser Leitung sendet, kann nichts durch den Pegelwandler durchgehen. Hier hat man den Fehler schon erkannt: http://www.roboternetz.de/phpBB2/viewtopic.php?t=12567&postdays=0&postorder=asc&start=88 leider tauscht man die Leitungen direkt am Controller und hat dadurch etwas mehr Aufwand.
@hannes, guter tipp. Ich habe das Board erst 2 Tage und wollte die RS232 Schnittstelle nur zum Debuggen benutzen, da ich bisher noch kein JTag besitze. Werd dann demnächst mal nen krummen Quarz auflöten.
Hi Am 8MHz Qurz liegt es bestimmt nicht. Wie Gerd ausgerechnet hat liegt der Baudratenfehler bei 8MHz und 38400 Baud bei 0,16%. Atmel lässt für die Verbindung von 2 AVRs Toleranzen von 2,5 bis 1% (in Abhängigkeit von der Bitzahl) zu. Bisher hatte ich bei der Verbindung AVR(4MHz Quarz, 4/8 MHz interner RC-Oszillator nie Probleme. Einziger 'Störfall' war bisher ein PIC. Die 'Baudratenquarze' sind nur notwendig, wenn zwischen Baudrate und Quarzfrequenz ein bestimmtes Verhältnis unterschritten wird. MfG HG
hallo, ich be auch den fehler mit rx und tx ausgebessert, zudem hab ich auch gleich die kondensator-quarz kombination gegen einen rc-oszilator getauscht. und zack schon läuft mein m16 mit gigantischen 20mhz und eine baudrate von 19200 ist auch kein problem mehr gruß xeus ps: ich finde es eine unverfrohrenheit von pollin, auf ihrer homepage nichteinmal auf den fehler hinzuweisen
Oi ein RC Oszilator auf 20MHz, das hört sich aber nicht alzu Frequenzstabiel an :) Naja solange es läuft....
Ich glaub das mit den Baudratenquarzen ist nicht so ganz verstanden worden: Die Baudfrequenz wird von der SystemClock gespeist. Bsp. UART-Clock 115200 Baud System Clock 8000000 Hz (8Mhz) Der Teiler, der nun gebraucht wird um die Systemclock (8Mhz) auf die Baudfrequenz herunter zu teilen berechnet sich wie folgt: UBRRVAL = CLOCK/(BAUD*16)-1 So.: UBRRVAL = 8000000/(115200*16)-1 UBRRVAL = 3,34 ... würde man jetzt einfach abrunden (Wie es zB ein Compiler machen würde, wenn er das UBRRVAL ausrechnet) dann hätte man 3. Lädt man aber UBRR mit dem Wert 3, so Stellt sich eine Baudrate von 125000 Baud ein.. Und das stimmt nicht mehr mit der Gegenseite überein. Folglich stimmen die Timings nich mehr -> Mist. Blöd nur, dass das UBRRVAL Register diesen Wert nicht annimmt, da es nur Werte von 0-255 (bei Megas und Tinys usw.. bis 65535 (UBRRH, UBRRL)) ohne Kommastellen annehmen kann. Und nu? Ganz einfach: BaudratenQuarz: UART-Clock 115200 Baud System Clock 14745600 Hz (14,7456Mhz) UBRRVAL = 14745600/(115200*16)-1 UBRRVAL = 7,00 ! Diese Zahl kann geladen werden und die BaudClock läuft mit genau 115200 Baud PS: Eine Baudrate mit (zu) hohem Fehler heißt nicht, dass wenigstens noch irgendein Datenmüll ankommen MUSS! Es kann sein, dass das Stopframe bedingt durch die Hohe Fehlerrate nicht mehr erkannt wird. Dann wird das komplette UART-Datenpaket einfach weggeworfen -> Ergo: Nix kommt an.
@Simon: Danke für deine Erklärung. Hoffentlich nutzt es etwas. Denn seit Jahren ist es Cool, den Prozessor des PC zu übertakten, das Letzte aus den Rechnern rauszuholen, egal ob dadurch Fehler auftreten oder nicht. Und da steckt man so in dieser Tuning-Manie, dass man sich nicht vorstellen kann, dass es Vorteile haben kann, den Controller mit etwas weniger als der maximalen Taktrate laufen zu lassen. Dafür wird dann aber gerne ein Programmierstil angewendet, bei dem der Controller von einer Delay-Schleife in die andere stolpert und nicht in der Lage ist, mehrere Arbeiten (pseudo-) gleichzeitig zu erledigen... ...
Zitat aus der Beschreibung bei Pollin: "Diese Platine zum Anschluss an den PC ermöglicht die direkte Programmierung der ATmega8535, ATmega16, ATmega32, ATmega8, ATtiny2313, ATtiny12 und ATtiny15." Kenne mich mit den 8051 nicht aus, gehe aber davon aus, dass deren Programmierung anders funktioniert, auch wenn Atmel sowohl die AVR als auch 8051-kompatible herstellt...
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.