Hallo Ich habe bisher fast alle meine Atmel -Projekte mit 4 MHz Taktfrequenz betrieben. Jetzt wollte ich mit einem ATmega16 rumbasteln, aber mit mehr Tempo. Leider musste ich feststellen, das ich bei allen Taktfrequenzen über 4,433 MHz keine RS232-Verbindung mehr hinkriege. Da kommt nur noch Schrott an. Ich habe versucht etwas an dem "UBRRL"-Wert zu justieren, aber ohne Erfolg. Andere Monitor-Software hat auch nichts gebracht. Bis 4,433 MHz kann ich Baudraten bis 19,2k erreichen. Darüber geht auch nichts mehr. Bei höheren Taktfrequenzen funktioniert aber nicht einmal 2400 Baud. Jetzt kommt die Gretchenfrage: Ist das normal, oder funktioniert das mal wieder nur bei mir nicht ? :(
Hans I. schrieb: > Leider musste ich feststellen, das ich bei allen Taktfrequenzen über > 4,433 MHz keine RS232-Verbindung mehr Wieviele hast du denn ausprobiert? > Ich habe versucht etwas an dem "UBRRL"-Wert zu justieren, aber ohne > Erfolg. Das ist nicht verwunderlich. UBRRL ist ja auch nur eine Hälfte des zuständigen Registers UBRR. > Jetzt kommt die Gretchenfrage: > Ist das normal Wenn man's falsch macht, ist es normal, dass es nicht funktioniert.
UBRRH brauche ich so gut wie nie mit Werten >0... Ein Stück Programm mit deiner UART.Init wäre nicht schlecht.
Ich habs mit einem 6,8,10 und 16 MHz Quartz versucht. Ging alles nicht. UBRRL ist schon klar das es nur das Low Byte ist. Da der Wert aber meist unter 255 liegt brauchte ich am High-Byte (UBRRH = 0) ja nichts machen.
Zeig mal bitte deinen Code für, sagen wir mal, 8 MHz, mit dem das dann auch von dir getestet wurde und nicht funktioniert.
Hans I. schrieb: > Ich habs mit einem 6,8,10 und 16 MHz Quartz versucht. Ging alles nicht. Es liegt trotzdem an dir. Ich kann dir garantieren, dass die USART eines Mega16 bei allen genannten Takten wunderbar entsprechend dem Datenblatt funktioniert. Kann es sein, dass du garnicht "auf Quarz" bist? Zeig' mal deine Fuses! Und wie H.Joachim S. anmerkte: Auch das Posten deines Init-Codes für die USART wäre sicher sinnvoll.
Warum sollte er den fehlerhaften Code zeigen? Dann ist doch sofort die Spannung raus.
Hans I. schrieb: > Jetzt kommt die Gretchenfrage: > Ist das normal, oder funktioniert das mal wieder nur bei mir nicht ? :( Funktioniert nur bei dir nicht. Lass dein UART nach der Initialisierung irgendeinen Text senden und guck dir das mit einem LA oder Oszi an. Vorher macht es wenig Sinn, irgendwo dran rum zu probieren.
Angehängte Dateien:
-
Image_1.jpg
75 KB
Ich habe mal 2 Dateien angehängt. Fuse-Bits und meinen Quelltext. Die RS232 Konfiguration nutze ich schon seit jahren und hat bisher immer funktioniert. Aber wie gesagt, bisher bin ich auch immer mit 4 MHz ausgekommen. Vllt mach ichs mir ja doch zu einfach :)
Dietrich L. schrieb: > http://ruemohr.org/~ircjunk/avr/baudcalc/avrbaudcalc-1.0.8.php Vielen Dank für die sehr gelungene Zusammenstellung! Man kann das zwar rechnen - aber so ist es natürlich viel übersichtlicher. Auf jeden Fall lohnt auch ein Blick auf die Spalte "% of error".
Hans I. schrieb: > Ich habe mal 2 Dateien angehängt. Fuse-Bits und meinen Quelltext. Fuses passen, der Fehler steckt im Quelltext, nämlich hier: > ldi temp1,0 [...] > out UBRRH,temp1 Lies' das verdammte Datenblatt. Du kannst beim Mega16 nicht so einfach auf UBRRH zugreifen. Was du tatsächlich tust: du schreibst 0 auf UCSRC.
Wolfgang schrieb: > Lass dein UART nach der Initialisierung irgendeinen Text senden und guck > dir das mit einem LA oder Oszi an. Nicht irgendeinen Text, sondern fortlaufend 0x55 mit 1 Stopbit.
c-hater schrieb: > Lies' das verdammte Datenblatt. Du kannst beim Mega16 nicht so einfach > auf UBRRH zugreifen. Was du tatsächlich tust: du schreibst 0 auf UCSRC. Falsch. Ich hätte es erstmal wieder lesen müssen. So schnell vergisst man... Passt schon.
Hans I. schrieb: > Bis 4,433 MHz kann ich Baudraten bis 19,2k erreichen. Darüber geht auch > nichts mehr. > Bei höheren Taktfrequenzen funktioniert aber nicht einmal 2400 Baud. In der Regel kann jeder uart bis maximale Quarzfrequenz/16, /32 oder /64. Bei glatten Quarzen passen die baudratn oft nicht. Der Fehler sollte <1% sein, über 3 geht nix mehr. Es gibt uart-Quartze, mit vielfachen von 115200*16. Z.B. 22,1184 MHz. Da geht dann jede baudrate wieder. Senden immer, empfangen nur wenn genug Zeit zur Verarbeitung bleibt.
c-hater schrieb: > Passt schon. Aber das nicht: > ldi temp,0b00001000 ;Enable receiver Das enabled den Transmitter, nicht den Receiver.
c-hater schrieb: > Das enabled den Transmitter, nicht den Receiver. Allerdings benutzt du ja auch nur den Transmitter. Also auch nicht das eigentliche Problem. (Allerdings trotzdem durchaus ein Problem: wenn man einen Kommentar hinschreibt, dann sollte der auch passen).
c-hater schrieb: >> ldi temp,0b00001000 ;Enable receiver > > Das enabled den Transmitter, nicht den Receiver. Damit schreibt man 0x08 in temp. Tuen tut das gar nichts.
Ist das ein Steckbrettaufbau? Die sind nicht immer sehr quarzfreundlich. Generell wäre ein Foto vom Aufbau kein Fehler. Vergiss erst einmal RS232. Bau einen Code, der einfach nur einen Ausgang toggelt, mit beispielsweise 1 Hz. Wenn überhaupt nichts blinkt, läuft nichts. Wenn die falsche Frequenz ist, siehst du das.
Dyson schrieb: > Nicht irgendeinen Text, sondern fortlaufend 0x55 mit 1 Stopbit. Auch ideal zum Test ist Ox0f z.b. alle 10ms. Da erkennt man direkt die ungefähre Baudrate beim mitlesen, wenn andere Zeichen erkannt werden. Mit oszi auch im Wechsel mit 0xf0, für ein relativ perfektes Augendiagramm bei Trigger auf Startflanke.
Korinthenkacker schrieb: > Damit schreibt man 0x08 in temp. Tuen tut das gar nichts. Ja, du hast recht. Getan wird dann genau eine Zeile später.
Beitrag #6859014 wurde vom Autor gelöscht.
A. S. schrieb: > Auch ideal zum Test ist Ox0f z.b. alle 10ms. Sorry, Blödsinn. wenn, dann 0xf0, damit zuerst nur Nullen, dann Einsen kommen. Mit dem Startbit sind es aber 5, besser wären 4: Also 0xf8. Dann sind doppelte , vierfache und halbe Frequenz perfekt. Auch der Umgekehrte Weg ist gut: Einen Empfänger kann man Sehr gut testen mit einem Funktionsgenerator. Für einen Uart mit 115k (8 Bit, ohne Parity) gehen Rechteck-Frequenzen von 12,8k (dann wird 0 empfangen) bis 23,04k (dann wird 0x0f empfangen). Man kann damit Empfang sehr einfach ausmessen, wenn man z.B. einen Empfangs/Fehlerzähler auf das gewünschte Zeichen setzt.
(prx) A. K. schrieb: > Vergiss erst einmal RS232. Bau einen Code, der einfach nur einen Ausgang > toggelt, mit beispielsweise 1 Hz. Wenn überhaupt nichts blinkt, läuft > nichts. Wenn die falsche Frequenz ist, siehst du das. Ja, auf lausigen Systemtakt würde ich inzwischen auch tippen (da ich keine offensichtlichen Fehler im Code oder den Fuses finden konnte): Der Quarz ist schlecht angepaßt und schwingt nur wiederwillig mit Schluckaufs. Gerade so an der Grenze zu "schwingt garnicht". Das ist immer fies, das kann beliebige Fehlfunktionen der Peripherie auslösen. Und leider: Das läßt sich mit dem LED-Trick nichtmal zuverlässig nachweisen. Ohne guten Oszi als Messmittel hilft da nur "Probieren", also Variation der Bürde-Kapazitäten. Allerdings hilft dabei wiederum dieses "gerade an der Grenze" wieder. Eine E6-Stufe höher oder tiefer geht mit einiger Wahrscheinlichkeit garnix mehr. Da weiß man dann immerhin schon, in welche Richtung man optimieren muss.
OK. Ich fasse mal zusammen. Bis auf den "Enable Reciever"-Fehler ist der Code nicht schön, aber lauffähig. Am PC wirds ja wohl auch nicht liegen. Und wenn ihr mir alle sagt, "das muss laufen" dann kanns ja nur noch am Aufbau oder am Kabel liegen. Übrigends ein Lochraster-Aufbau mit 2m Kabel. Werd morgen mal mit n Oszi gucken. Oder ich werde zuerst den Quartz gegen einen Quartz-Oszillator tauschen. Hab ja noch ein paar Optionen :)
Hans I. schrieb: > Übrigends ein Lochraster-Aufbau Vergiss die Bilder nicht. Oben und unten. > Werd morgen mal mit n Oszi gucken. Wobei Tastkopf an Quarz einen schönen Heisenberg abgibt. Soll heissen: Da zu messen ist ziemlich problematisch. Es hat auch schon Fälle gegeben, wo es nur so funktionierte. ;-)
:
Bearbeitet durch User
jo schrieb: > Vielen Dank für die sehr gelungene Zusammenstellung! Ja, nicht schlecht. Allerdings hatte bisher das Datenblatt eines jeden Controllers mit UART, mit dem ich gearbeitet habe, eine solche Tabelle! Hab jetzt gerade keine Lust, die diversen Tabellen zu vergleichen...aber besser wär das :-) Gruß Rainer
A. S. schrieb: > wenn, dann 0xf0, damit zuerst nur Nullen, dann Einsen kommen. > > Mit dem Startbit sind es aber 5, besser wären 4: Also 0xf8. Dann sind > doppelte , vierfache und halbe Frequenz perfekt. Irgendwie hast du einen Knoten im Kopf. 0xF0 fortlaufend gesendet: Startbit(0), 4 Nullen, 4 Einsen, Stopbit(1) ergibt einen schönen 1:1 Wechsel mit 1/10 der Baudrate als Frequenz.
Falls kein Oszilloskop vorhanden ist tut es auch ein Logic Analyzer für 10 Euro.
(prx) A. K. schrieb: > Wobei Tastkopf an Quarz einen schönen Heisenberg abgibt. Soll heissen: > Da zu messen ist ziemlich problematisch. Es hat auch schon Fälle > gegeben, wo es nur so funktionierte. ;-) Richtig, man mißt bevorzugt den Phasenjitter an einem abgeleiteteten Takt oder halt an CLKO (was der Mega16 aber nicht hat).
> wenn ihr mir alle sagt, "das muss laufen" ...
Dann schließe ich mich mal an: auf meinem Steckbrett läuft es, z.B.
mit UBRR=51 (9600 Bd bei 8 MHz) oder auch mit 8 (115200 Bd bei 16 MHz,
trotz des Fehlers von 3.5 %).
(die derzeit nicht benutzte Interrupttabelle sollte noch korrigiert
werden)
Dyson schrieb: > Irgendwie hast du einen Knoten im Kopf. 0xF0 fortlaufend gesendet: > Startbit(0), 4 Nullen, 4 Einsen, Stopbit(1) ergibt einen schönen 1:1 > Wechsel mit 1/10 der Baudrate als Frequenz. Fürs Oszi, ja. Für ein Terminalprogramm ist 0xf8 ein bisschen besser, da 0xf0 bei halber Frequenz (z.B. 9k6 statt 19k2) schon Framing-Error wirft. Und bei doppelter/vierfacher Frequenz nicht genau an den Bitflanken wechselt.
A. S. schrieb: > Fürs Oszi, ja. Für ein Terminalprogramm ist 0xf8 ein bisschen besser, da > 0xf0 bei halber Frequenz (z.B. 9k6 statt 19k2) schon Framing-Error > wirft. Ich bezog mich letztlich darauf: Wolfgang schrieb: > Lass dein UART nach der Initialisierung irgendeinen Text senden und guck > dir das mit einem LA oder Oszi an.
A. S. schrieb: > Dyson schrieb: >> Nicht irgendeinen Text, sondern fortlaufend 0x55 mit 1 Stopbit. > > Auch ideal zum Test ist Ox0f z.b. alle 10ms. Da erkennt man direkt die > ungefähre Baudrate beim mitlesen, wenn andere Zeichen erkannt werden. Der Vorteil von fortlaufend gesendetem 0x55 mit 1 Stopbit ist, dass man da gar nichts erkennen muss, sondern ein Frequenzzähler oder ein DSO mit passender Signalauswertung direkt die Baudrate anzeigen kann.
Wolfgang schrieb: > direkt die Baudrate anzeigen kann. sorry, muss heißen "... direkt die Hälfte der Baudrate anzeigen kann."
Angehängte Dateien:
-
IMG_0336.JPG
230 KB -
IMG_0337.JPG
240 KB -
IMG_0338.JPG
240 KB
Hier sind schonmal 3 Bilder von meinem Probeaufbau. Der MAX232 ist wie der Programmieradapter nicht auf der Platine sondern in den Gehäusen die daneben liegen. Und falls jemandem der steckbare Quartz sauer aufstösst, den hab ich nur zum schnelleren durchtesten verschiedener Quartze steckbar gemacht. Was die ganze Messgeschichte angeht, ich hab nur ein 40 Jahre altes Hameg. Da sind meine Mittel recht begrenzt. Bei 4 MHz oder mehr irgendeinen Jitter am Systemtakt zu erkennen kann ich wohl vergessen. Die RS232-Signale kann ich mir aber mal angucken. Morgen :)
AVCC ist die Stromversorgung von Port A und mitnichten optional. Also auch dann beschalten, wenn man den ADC nicht benötigt. Die Kerkos zwischen (A)VCC und GND packt man am besten direkt an die Pinpaare vom Controller. Da bei dir die Steckplatine dazwischen ist, wärs kein Fehler, an beide Pärchen auf dieser Platine je einen 100nF zu stricken.
:
Bearbeitet durch User
Den Oszi mit Tastkopf sollte man nicht an den Quarz klemmen. Wenn man programmieren kann, ist auch schnell mal irgendein Ausgang auf einen messbaren Bruchteil des Systemtakts programmiert - damit zeigt sich der Quarz- (???) oder Systemtakt und schon hat man den Fehler besser eingekreist. Das geht fixer, als hier langatmig zu jammern...
Köbes schrieb: > Den Oszi mit Tastkopf sollte man nicht an den Quarz klemmen. Mit 10:1-Tastkopf passiert da i.a. nicht viel. Verstimmt immer noch ein bisschen, aber kein Abreissen der Oszillation durch den Tastkopf. 100:1 ist noch besser, aber nur selten vorhanden.
FCPU passend zum XTAL eingestellt? Schon komisch, daß das noch niemand der ganzen "Experten" hier gefragt hat...
:
Bearbeitet durch User
H.Joachim S. (crazyhorse) schrieb:
> passiert da i.a. nicht viel.
I. A. ...
Das ist "Prinzip Hoffnung" statt simplem aussagekräftigem Funktionstest,
der auch gleich die tatsächliche Systemfrequenz offenlegt.
Harry L. schrieb: > FCPU passend zum XTAL eingestellt? > > Schon komisch, daß das noch niemand der ganzen "Experten" hier gefragt > hat... Die "Experten" haben erkannt, dass F_CPU in seinem Quelltext nicht verwendet wird und daher irrelevant ist.
Köbes schrieb: > H.Joachim S. (crazyhorse) schrieb: >> passiert da i.a. nicht viel. > > I. A. ... > Das ist "Prinzip Hoffnung" statt simplem aussagekräftigem Funktionstest, Nein, es ist das "Prinzip Erfahrung". Bei 32,768 kHz Quarzen kann es Probleme geben, dort einen Tastkopf anzuschließen. Bei höherfrequenten Quarzen ist dies nicht der Fall. Zudem ist die Frequenzabweichung dabei minimal. Auch ganz ohne Messgerät kann man die interne Taktfrequenz hinreichend genau abschätzen: Eine LED im 1 s Takt blinken lassen und eine Minute lang mit dem Sekundentakt einer Uhr vergleichen. Im Idealfall kann man keine Abweichung der Phasenverschiebung feststellen, aber selbst, wenn pro Minute 61 oder 59 Impulse geblinkt werden, reicht dies für eine "gute" Baudrate aus.
OK. Problem gelöst ! And the winner is : Ich natürlich und (prx). Hab seine Tips beherzigt und AVcc angeschlossen und 2x 100nF kerkos direkt an die IC-Pins meiner Adapterplatine gelötet. Jetzt geht 115,2 Kbps bei 16 MHz Taktfrequenz. Mehr konnte ich nicht erreichen. Bei höheren Baudraten meldet sich mein Uralt-PC mit "Falsche Parameter". War wohl keine gute Idee den halben Controller ohne Stromversorgung einfach in der Luft hängen zu lassen. Also AVcc auch anschliessen wenn man Port A und ADC nicht braucht. Aber auch vielen Dank bei allen anderen die sich hier beteiligt haben.
Hans I. schrieb: > Also AVcc auch anschliessen wenn man Port A und ADC nicht braucht. Schließe AVcc bsser immer an, auch wenn du Port A nicht verwendest. Der Betrieb ohne AVcc ist nicht vorgesehen.
Noch ein Nachtrag. Mit meinem kleinen Testprogramm konnte ich leider nur die Richtung Controller --> PC testen. Das lief auch schon fehlerfrei. Bei weiteren Tests musste ich leider feststellen des die Richtung PC --> Controller immer noch Fehler bringt. Nicht viele, aber ab und zu war mal son Aussetzer dabei. Ich hab jetzt den Quarz gegen einen 16 MHz Quarzoszillator getauscht (Fusebits entsprechend einstellen !). Jetzt läuft die Sache rund. Keine Fehler oder Aussetzer mehr.
Aktiviere mal CKOPT in den fuse-bits. Ab > 8 MHz ist das sinnvoll bzw. notwendig, damit der Quarzoszillator stabil schwingt.
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.