Hallo!
Ich habe das UART Tutorial durchgearbeitet, allerdings empfange ich
statt der Zeichenkette "Test!" nur Zeichenmüsli.
# stty 9600 -parenb cs8 -cstopb cread < /dev/ttyS0
# cat /dev/ttyS0
8?ni]8?ni]8?ni]x?!
wGo!tno!tno!tno!tno!tnwtno!tno!tno!tno!tno!tw
wGo!tno!tno!tno!tno!tnOwtno!tno!tno!tno!tno!tw
wGo!tno!tno!tno!tno!tnw
wGo!tno!tno!tno!tno!t~wGo!tno!tno!tno!w
wGo!tno!tno!tno!tno!tnwtno!tno!tno!tno!tno!tw
wGo!tno!tno!tno!tno!tnOwtno!tno!
...
Was mach ich falsch?
Der Controller läuft mit 8 MHz:
.INCLUDE "m16def.inc"
.EQU CLOCK=8000000 ;System Oscillator clock frequency
.EQU BAUD=9600
.EQU UBRRVAL=CLOCK/(16*BAUD)-1 ;Asynchronous Normal Mode (U2X = 0)
@,,,,:
Was ist denn die richtige Baudrate?
Es genügt nicht, einen externen Quarz anzuschließen. Du mußt ihn auch
aktivieren. Tut man das nicht, dann läuft er weiterhin mit dem internen
Oszillator mit 1MHz.
>>OK, ich ab da jetzt mal Testweise .EQU CLOCK=1000000 eingestellt,>>ist aber immernoch Zeichenmüsli :-(
Das bringt gar nix, denn der interne Oszillator hat 3% Abweichung, zu
viel für UART, da hilft nur ein externer Quarz. Also: externen Quarz
anschließen und per Fuses aktivieren, dann läuft's auch (am Besten
einen Baudratenquarz nehmen).
Pete
@Conlost: Wenn die Hardware gar nicht laufen würde, würde er auch gar
nix empfangen (oder nur total Zufälliges Zeug). Die empfangenen Zeichen
lassen aber doch eine gewisse Regelmäßigkeit erkennen, was darauf
hindeutet, dass nur die Takte "verschoben" sind -> falsche Baudrate.
Buchstabensalat ist eher eine Hinweis, dass die Hardware passt, aber
die Baudrate falsch eingestellt ist.
Pete
Ich denk schon das es richtig verdrahtet ist, hab so nen Pollin
Evaluationsbord.
Vielleicht hab ich auch die falschen Paramter für stty? Hat vielleicht
mal jemand die richtigen Parameter für
Bits pro Sekunde: 9600
Datenbits: 8
Parität: Keine
Stoppbits: 1
Protokoll: Kein
für stty zur hand?
Hallo,
habe grade mal auf dem STK500 getestet.
Interner RC-Oszillator 1MHz und es kam Datenmüsli.
Ich habe dann mal die Baudrate auf 600 statt 9600 gestellt,
da ging es dann.
Das heisst, Pete hat recht.
Es grüsst,
Arno
Zwischen XTAL1 und XTAL2 hängt nen Quarz (8 MHz), das hat auch nur diese
2 Beinchen.
Könnte ich das als Taktquelle nehmen? Wenn ja, wie würden die Fusebits
dazu aussehen (nicht das hinterher gar nichts mehr geht)?
Habs mir jetzt anhand der Doku raus gesucht und einfach mal probiert:
--wr_fuse_h=11111111 --wr_fuse_l=0011111111
Diese Einstellungen im Assemblerfile:
.INCLUDE "m16def.inc"
.EQU CLOCK=8000000 ;System Oscillator clock frequency
.EQU BAUD=9600
.EQU UBRRVAL=CLOCK/(16*BAUD)-1 ;Asynchronous Normal Mode (U2X = 0)
Ich bekomm aber immernoch nur Blödsinn, und damit ich diesen Blödsinn
sehe muss ich "stty 9600 raw > /dev/ttyS0" eingeben, sonst seh ich
gar nichts.
Hat noch jemand eine Idee?
.EQU UBRRVAL=CLOCK/(16*BAUD)-1 ;Asynchronous Normal Mode (U2X = 0)
Von daher denk ich mal asyncron. Ich versuche auch nur Daten an den PC
zu senden, empfangen soll der Atmel nichts.
Auf dem Baustein steht:
---------
|5AC1CLM|
|MAX232N|
---------
UMSEL=Synchron/Asynchron
U2X=Schneller UART
auch das senden wird mit synchronem Mode ned funktionieren!!! Mein MAX
passt wenn du 1µF ELKOS(richtig gepolt)verwendest!
An dem MAX hängen (so wie es im Bauplan steht, ist so ein Atmel
Evaluationsboard aus dem Pollin) jeweils 10µF dran. Gepolt sind sie
auch richtig, hab gerade nochmal nachgeschaut.
Was mir gerade noch in den Sinn kommt: Muss ich die Fusebits bei uisp
auch invertieren (so wie bei Ponyprog)?
Ich hab den Übeltäter gefunden: uisp hat die Fusebits nicht korrekt
gesetzt. Egal was ich als Paramter angegeben habe, die Fusebits wurden
immer auf 0x01 gesetzt, sowohl das High- als auch das Lowbyte.
Ich weis nicht ob es an der Linuxdistri lag (Ubuntu 5.10 mit Vanilla
Kernel 2.6.15.4) oder am uisp (über apt aus dem universe installiert).
Hab jetzt extra um zu testen noch Windows auf den PC installiert: Die
serielle funktioniert.
Danke an alle die mir geholfen haben!