Daten via UART an PC

[justus (Gast)]

Hallo zusammen

Ich bin wieder mal der Ochs am Berg und finde den entscheidenden Hint
nicht.
Beiliegendes Programm habe ich zusammengestellt und geändert aus
Beispielen und laufendem Code für den mega169. Es soll die Zeichenkette
"Test" wiederholt an den PC geschickt werden. Leider bis jetzt ohne
Erfolg. Kann jemand weiterhelfen?
Die Einstellungen am PC: Com2, 9600, 8, N, 1 im Hyperterminal von
Windows.

Justus

[René König (Gast)]

1) Es ist eine gute Idee, den Stackpointer zu initialisieren. Gerade
auch, weil Du rcall verwendest.

2) Die IO Register erreichst Du nicht mit lds/ sts, sondern mit in/
out. Mit ersteren erreichst Du das RAM.

3) In Deinem Unterprogramm 'serout' verwendest Du ldi, um die die
Konstante in r17 zu holen. Hier bleibt Dein Programm stehen, da in
UCSRA mit 0xC0 Bit 5 immer gelöscht ist. (Schau Dir dafür mal sbis an.)

[justus (Gast)]

Stackpointer hab ich nun initialisiert;
ldi temp, low(RAMEND)  ;Stackpointer initialisieren
out SPR0, temp
ldi temp, high(RAMEND)
out SPR1, temp

Allerdings schaffe ich es nicht, die I/O Register UBRR via OUT zu
beschriben. Sie liegen ausserhalb des mit OUT beschribbaren
Adressraumes  (<64 od 0x40); Auszug aus dem Definitionsfile:
.equ  UBRRH     = 0xC5
.equ  UBRRL     = 0xC4
Gibt es da einen andern Befehl?? Weiter steht im Manual des 169er
jedesmal der Befehl STS für das Beschreiben der Register UBRRH, UBRRL
(beim Beispiel UART).

Den dritten Kommentar versteh ich nicht. Es ist mir klar, dass das Bit
1 werden muss damit das nächste Zeichen gesendet wird. Solange jedoch
das erste Zeichen nicht weg ist, wird dieses Bit wohl bei 0 stehen
bleiben. Ausserdem kann der Befehl SBIS nur für die ersten 32 Register
verwendet werden. Anbei wiederum der Auszuf aus der Definitionsdatei:
.equ  UCSRA     = 0xC0

Gruss Justus

[René König (Gast)]

> Sie liegen ausserhalb des mit OUT beschribbaren Adressraumes

Das ist richtig. Das hätte ich eigentlich auch sehen müssen, da ich
selber 0xC0 für UCSRA festgestellt habe. Mein Kommentar 2 war absoluter
Dünnpfiff. Bei den Dingern, die ich bislang in der Mangel hatte, habe
ich den UART immer über in/ out erreichen können (da hätte  für lds/
sts noch 0x20 auf die Konstante addiert werden müssen). Da bin ich gar
nicht auf die Idee gekommen, dass das bei Deinem Derivat anders sein
könnte. Ich hoffe, Du lässt das als Ausrede gelten.

Und natürlich kommst Du deswegen auch mit sbis nicht weiter. Die
Verwendung von ldi ist an dieser Stelle aber trotzdem falsch. Du willst
ja nicht die Adresse in r17 laden, sondern den Inhalt der Adresse. Du
musst lds anstelle von ldi verwenden.

Übrigens verwendet Atmel aus reiner Gewohnheit ebenfalls einfach sbis
im Sample auf Seite 163 im Datenblatt. Das dürfte dann aber eigentlich
auch nicht funktionieren ...

[justus (Gast)]

Stimmt, funktioniert auch nicht. Der Code zu keinem assemblier-Fehler
führt ist folgender:
   ldi r17, UCSRA
   sbrs r17, 5        ;Warten, bis UDR für das nächste Byte bereit ist
   rjmp serout
   sts UDR, temp
   ret

Deine andern Tipps werde ich (so mein Sohn will) heute Abend
ausprobieren.

Justus

[justus (Gast)]

Ich habe das Programm nun angepasst... leider noch ohne Erfolg. Ich
hatte auch noch Fehler im Stackpointer, der nun jedoch, so scheint es
wenigstens behoben ist.
Was mir unklar ist, ist dass bei der Initialisierung des Registers
UCSRC
gleichzeitig auch wieder das Register UBRRH mit 6 beschrieben, was dazu
führt dass die Bitrate verstellt wird. Das begreif ich nicht, Kann mir
jemand einen Hint geben wo ich noch weitersuchen könnte?

Gruss Justus

[mthomas (Gast)]

ldi r17, UCSRA sieht nicht gut aus. Ehrer lds ....
Es geht wohl noch um den Butterfly als Zielplatform...
auf http://www.siwawi.arubi.uni-kl.de/avr_projects/
nach "UART-echo" suchen. Das ist ein simples Programm, das alle
Zeichen, die via UART empfangen werden wieder zurueckschickt. Es ist
C-Code (avr-gcc). Aber der Code sollte, da man die Funktion
OSCAL_calibtration erstmal weglassen kann, leicht auf Assembler
"umzustricken" sein. Beachtenswertes bei Stackpointer-Init und
Unterschied sts/out lds/in wurde ja schon durchgekaut
HTH, Martin

[justus (Gast)]

Hallo Martin

Vielen Dank für den Hinweis. Alles lief auf Anhieb (mit direktem
kompilieren Deines? Codes mit gcc). Nun bin ich beruhigt, dass nicht
etwas futsch ist... möglicherweise ist es sinnvoller, ich realisiere
das Ganze in C statt in Assembler. Es läuft übrigens auch ohne
Kalibrierung.

Gruss Justus