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.
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.
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!
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!
