Hi zusammen
ich habe ein Problem mit meiner UART-Kommunikation.
Die Daten meines Boards:
8MHZ Quarz
Atmega8
Verbindung zum PC über Serial-to-USB Converter
Linux Betreibssystem
Zu meinem Problem:
ich habe mir ein Assembler Programm erstellt mit Hilfe des
UART-Tutorials hier von der Website (im Anhang). Das Programm und die
Kommunikation läuft auch soweit. Das Programm empfängt ein Zeichen und
sollte dann einen Port setzen oder löschen. Zum Debuggen sendet es aber
das gleiche Zeichen wieder zurück. Nun ist es aber so, dass nicht immer
die Gleichen Zeichen zurückkommen, wie ich gesendet habe. Für bestimmte
Zeichen funktioniert es (eine Auswahl):
w -> w
r -> r
z -> z
o -> o
Für einen bestimmen Zeichensatz funktioniert es aber nicht (eine
Auswahl):
u -> w
i -> o
d -> f
h -> n
Im Moment habe ich keine Ahnung, an was es liegen könnte. Im Forum wird
häufig eine falsche Baudrate als Grund angegeben. Meiner Meinung nach
sollte sich 9600Baud und 8MHz aber vertragen (Datenblatt!). Weiter ist
es auch komisch, dass immer die gleichen Zeichen falsch ankommen.
Ich habe auch schon ein C Programm erstellt, bei diesem habe ich das
gleiche Problem, dort ist es aber z.T. noch extremer, sprich es kommen
noch mehr Zeichen falsch an.
Danke für eure Hilfe
Gruss Johannes
Hi
> Meiner Meinung nach>sollte sich 9600Baud und 8MHz aber vertragen (Datenblatt!).
Wenn es ein Quarz und nicht der interne RC-Oszillator ist, ja.
MfG Spess
Hi
>High Fuse Bit ist: 11011001>Low Fuse Bit ist: 11101111
Sollen wir die jetzt auseinandedröseln? Ausserdem solltest du wissen, ob
in deiner Schaltung ein Quarz ist.
MfG Spess
Also in meiner Schaltung ist natürlich ein Quarz
(Olimex-Experimentierboard für 28-Pin Atmega8).
CKSEL ist : 1111 (wobei 1 für Programmed)
Ausserdem muss ich noch anfügen, dass die übertragung vom IC zum PC
einwandfrei funktioniert, wenn ich die ganze Zeit 'Test!' übertrage (ein
Beispiel aus dem Uart-Tutorial auf dieser Seite).
LG
uuups, dass kommt vom ständigen, herumprobieren.
Das sollte eigentlich 8000000 sein. Nun ist das nicht das zentrale
Problem. Denn es ist zwar jetzt besser, nicht mehr so viele Buchstaben
kommen falsch an, jedoch immer noch ein paar, z.B. das a wird zum q und
das c wird zum s.
Weiter hatte ich das genau gleiche Problem mit anderen Programmen, bei
welchen die Frequenz richtig war (c und assembler).
Aber danke für diesen Hinweis!
LG Johannes
Mal dir die Bitmuster auf und schaue ob immer ein bestimmtes Bit falsch
ist. Denk dran, bei RS232 kommt das LSB zuerst und das MSB zuletzt.
Dahinter ggf. Parität und 1 oder mehrere Stoppbits. Prüfe, ob du bei PC
und µC Parität und Stoppbits identisch eingestellt hast. Wenn nicht kann
es sein, dass die zum Zeichen gezählt werden.
Du kannst beim µC auch Frameerrors abfragen und eine DebugLED schalten,
wenn ein Fehler passiert ist.
Von der Hardware her ist alles OK? GND nicht vergessen?
Abblockkondensator am TTL-RS232-Pegelwandler, falls solcher verwendet
wird? Wenn TTL-USB-Serial-Adapter - arbeitet der mit gleichem Pegel wie
dein AVR (5V/3.3V Logik)?
Hi
>z.B. das a wird zum q und das c wird zum s.
Das ist definitiv ein Baudraten-Problem. Stoppbit wird als Bit7
empfangen.
Wird vielleicht auch b zu r oder d zu t?
MfG Spess
Hallo Johannes,
überprüfe doch mal bitte wie am µController so auch am PC
die RS232 Einstellungen.
1) Paritätsprüfung
2) Stoppbits
3) Frameformat
Ja und die Zeile USART Double speed
sbi UCSRA, U2X
sollte dass nicht
cbi UCSRA, U2X
heissen??
nachtrag:
ich habe jetzt gerade
sbi UCSRA, U2X
in
cbi UCSRA, U2X
umgewandelt, und es funktioniert einwandfrei.
Danke viel mal für die vielen Antworten.
Ich hätte dazu noch eine Frage: ist U2X standardmässig gesetzt?
LG Johannes
HI
>@spess53: ja das mit dem b und d stimmt.
Erstmal muss ich eine Aussage zurücknehmen: bei diesen Zeichen liegt der
Unterschied nicht in Bit7 sondern in Bit4.
>Von wo weisst du das?
Sieh dir mal eine ASCII-Tabelle an. Dann weißt du es auch.
> Und hast du mir einen Lösungsvorschlag?
Habe gerade gesehen, das du sie gefunden hast.
>Ich hätte dazu noch eine Frage: ist U2X standardmässig gesetzt?
Nein.
MfG Spess
@ Johannes W
ich finde deine Baudratenberechnungen echt spitze.
Diese Zeilen werde ich wohl übernehmen.
An der Stelle wo bei dir das Frameformat festgelegt wird, verliert man
leicht den Überblick.
Ich bevorzuge eine aus meiner Sicht transparentere Schreibweise.
; Frame-Format: 8 Bit
Hi
>Ich bevorzuge eine aus meiner Sicht transparentere Schreibweise.>Ldi temp,
(0<<RXC)|(0<<TXC)|(0<<UDRE)|(0<<FE)|(0<<DOR)|(0<<PE)|(0<<U2X)|(0<<MPCM)
Findest du es wirklich sinnvoll, Bits, die als 'Read Only' deklariert
sind, zu beschreiben?
MfG Spess
spess53 schrieb:
> Findest du es wirklich sinnvoll, Bits, die als 'Read Only' deklariert> sind, zu beschreiben?
Bei einem Mega8 ist es vielleicht nicht so sinnvoll, denn da kann man
die einzelnen UCSRA Flags via SBI/CBI erreichen.
Aber bei einem Mega168 haste keine andere Wahl, da geht nur STS/LDS.
gtf schrieb:
> Bei einem Mega8 ist es vielleicht nicht so sinnvoll, denn da kann man> die einzelnen UCSRA Flags via SBI/CBI erreichen.> Aber bei einem Mega168 haste keine andere Wahl, da geht nur STS/LDS.
Seufz.
Hi
>Aber bei einem Mega168 haste keine andere Wahl, da geht nur STS/LDS.
OK. Das ist in dem Fall unvermeidlich. Allerdings verstehe ich trotzdem
nicht, was an einem '|(0<<FE)' transparent ist'. Ein 'Or' mit Null ist
sinnlos.
MfG Spess
spess53 schrieb:
> OK. Das ist in dem Fall unvermeidlich. Allerdings verstehe ich trotzdem> nicht, was an einem '|(0<<FE)' transparent ist'. Ein 'Or' mit Null ist> sinnlos.
Stimmt!
Ist Gewohnheitssache.
Zuerst kopiere ich die einzelnen Flags aus der PDF(datasheet) ins AVR
Studio
Mache draus den folgenden Salat:
[avrasm]
Ldi temp,
(1<<RXCIE)|(0<<TXCIE)|(0<<UDRIE)|(1<<RXEN)|(1<<TXEN)|(0<<UCSZ2)|(0<<RXB8
)|(0<<TXB8)
out UCSRB, temp
[avrasm]
Und setzte nur die benötigten flags.
Steht mal ein neues Projekt an, so kopiere ich einfach die gesamte Zeile
und ändere nur noch die Einsen und Nullen.
Gute Nacht!
