Hallo! Ich versuche seit einigen Tagen über die UART Zeichen zum PC zu senden. Es werden auch Zeichen empfangen - aber die falschen! µC: Atmega16 Board: STK500 Ich hab die Checkliste (http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART) schon mehrfach durchgearbeitet und das Problem damit leider nicht beheben können. Ich benutze einen externen Quarz mit 1,8432 MHz, der auch wirklich verwendet wird. Mein Programm sollte die Zeichen der ASCII-Tabelle aufsteigend beginnend mit 0x00 (NUL) senden. Es werden aber andere Zeichen empfangen. Ich kann bei diesen auch kein System (wie etwa ne Verschiebung um einen bestimmten Wert) erkennen. Die Zeichen werden jeweils im Abstand von 1,085 s gesendet. Im gleichen Takt fungiert die LED-Leiste als Vorwärtszähler. Dies passt auch, also pro Zählschritt wird genau ein Zeichen gesendet. Beim Senden nur eines bestimmten Zeichens ist das Problem das gleiche. Statt einem 'B' wird z. B. stets ein '/' empfangen. Mein Quellcode ist im Anhang. Für Hilfe bin ich dankbar.
Andrea D. schrieb: > Ich benutze einen externen Quarz mit 1,8432 MHz, der auch wirklich > verwendet wird. Wie hast du das getestet?
Und wenn du in UBRRL mal fest 11 reinschreibst? Gehts dann?
Karl heinz Buchegger schrieb: > Andrea D. schrieb: > >> Ich benutze einen externen Quarz mit 1,8432 MHz, der auch wirklich >> verwendet wird. > > Wie hast du das getestet? Wenn ich den Quarz rausziehe, bleibt der Controller stehen. Das mit dem festen Wert in UBRRL probier ich morgen früh. Meinst du den dezimalen Wert 11, den binären oder den hexadezimalen? Im Zweifel probier ich alle drei Möglichkeiten aus. Danke schon mal für die Antworten. Bis morgen, Andrea
Andrea D. schrieb: > Karl heinz Buchegger schrieb: >> Andrea D. schrieb: >> >>> Ich benutze einen externen Quarz mit 1,8432 MHz, der auch wirklich >>> verwendet wird. >> >> Wie hast du das getestet? > > Wenn ich den Quarz rausziehe, bleibt der Controller stehen. OK. Das ist Beweis genug :-) > Das mit dem festen Wert in UBRRL probier ich morgen früh. Meinst du den > dezimalen Wert 11, den binären oder den hexadezimalen? Im Zweifel > probier ich alle drei Möglichkeiten aus. So wie es aus der Compiler Berechnung auch rauskommen würde, wenn .... ja wenn die #define F_CPU 1843200UL wirksam werden. Die können zb durch die Proejkt Einstellungen in den Project Options überschrieben sein. Siehst du beim Compiliervorgang diesen Text F_CPU war noch nicht definiert, wird nun nachgeholt mit 1843200 Hz wenn nicht, dann gibt es in den Projekt Einstellungen bei der Taktfrequenz einen Eintrag, der dieses #define nicht wirksam werden lässt. Das ist ein unangenehmer Fehler, daher gehen viele wieder davon ab, diese Sequenz mit einem #ifdef zu kapseln. Das soll ruhig ein Fehler sein und der Programmierer soll das ruhig merken, dass sich hier 2 Definitionen für F_CPU beissen. Der umgekehrte Fall ist nämlich noch viel unangenehmer.
Hab nun mal UBRRL manuell auf 11 gesetzt und auch herausgefunden, dass der dezimale Wert 11 gemeint ist. Das Ergebnis ist das gleiche. Auch wenn ich UBRRH (natürlich vor UBRRL), ebenfalls manuell, auf 0 setze. @Karl Heinz: Ja ich erhalte genau diese Fehlermeldung und mir ist auch bewusst, dass ich sie erhalten möchte, um zu wissen, dass kein anderer Wert definiert ist. Außerdem habe ich mal die Frequenz des Quarzes mit dem Oszi überprüft. Einmal anhand der LED 0, die im 1,085-s-Takt blinken sollte und einmal habe ich eine LED ohne Timer blinken lassen. Ich komme im ersten Fall auf 1,09 s (genauer kann ich nicht messen) und im 2. Fall auf 1,8308 MHz. Das bedeutet eine Abweichung von nur 0,33% und das ist verdammt gut. Bin also leider immer noch nicht weiter.
Mit Oszi in der Werkstatt kannst du doch die Leitung TX (AVR) - RX (PC) prima abhorchen. Und zwar auf der Strecke PC-Pegelwandler und auf der Strecke Pegelwandler-AVR. Abblockkondensator am Pegelwandler hast du? Dann siehst du 1. die Bitzeiten 2. die Framelänge Start+Daten+Parity+Stopp 3. die Bitzustände Ergo alles was das Herz begehrt. Ich würde dazu bei einem analogen Oszi ohne Speicher immer das gleiche Zeichen senden und auf die erste Flanke triggern (Startbit). Die Timebase dann lang genug so dass ein Frame auf den Schirm passt. Die Wiederholrate für das Senden hoch genug setzen, damit es ein sichtbares Bild gibt. Bei einem DSO mit single shot Modus ist das einfacher. Wenn das Triggern auf die erste Flanke nicht geht, dann einen zweiten Pin programmieren, der vor UDR = c; gesetzt wird und den zum Triggern benutzen. Abschalten dieses Pins nach _delay_ms je nach Baudrate. Näheres zum Frame: RS232
ADD:
> Wenn das Triggern auf die erste Flanke nicht geht...
Damit meine ich, wenn folgende Flanken im Frame die Anzeige nachtriggern
und damit nicht der komplette Frame dargestellt wird.
Sag Bescheid, wenn du Anleitung/Hilfe brauchst, um die Messung mit dem Oszi zu dokumentieren (z.B. um sie hier zu zeigen) und auszuwerten.
Ändere mal deine Init so ab
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Kopier dir den Code von hier raus und benutze ihn 1:1
Pegelwandler? - Ähm... ja und schon ist die Ursache gefunden. War ich doch davon ausgegangen, dass die serielle Schnittstelle des PC mit der gleichen Logik und den gleichen Pegeln arbeitet wie die Ausgänge des Mirkocontrollers. - Dem ist natürlich nicht so, wie ich eigentlich hätte wissen können. Nach erneutem Nachlesen in der Beschreibung des STK500 hab ich nun auch endlich gefunden, wie ich die 2. serielle Schnittstelle mit den entsprechenden Controller-Ausgängen verbinde. Hatte zuvor mit einer eigenen Steckerverbindung die entsprechenden Port-Pins mit der seriellen Schnittstelle des PC verbunden. - Ein dummer Fehler. Aber ich hatte schon geahnt, dass ein dummer Fehler hinter meinem Problem steckt. Wie dem auch sei, vielen, vielen Dank für eure Hilfe!
Kabel gefunden - und es funktioniert endlich richtig. :)
Dann hattest du aber Dussel, dass du mit dem AVR keine Empfangsexperimente gemacht hast. Die typ. -12V bis 20 mA auf der PC-TX Leitung im Ruhezustand mag der AVR gar nicht an seinem RXD-Beinchen!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.