hi8 und lo8 bei gcc-asm

[sep (Gast)]

Hey,

Irgendwie bin ich gerade ein bisschen verwirrt.
Ich habe zwei assembler Befehle mit hi8 und lo8 und bekomme dort jeweils 
eine Fehlermeldung. Folgender Code:

    ldi r18, hi8( F_CPU / 100 / 3 )
    ldi r19, lo8( F_CPU / 100 / 3 ) - 1

 Nun kommt dazu folgende Fehlermeldung.

Error: `)' required
Error: garbage at end of line
Error: `)' required
Error: garbage at end of line

Wenn ich jedoch ein hi8( 0x3000 ) angebe, dann kompiliert er alles 
richtig. F_CPU wird richtig mit übergeben mit 368600UL. Ich habe nun 
schon wie verrückt gegoogelt. Konnte jedoch nichts finden. Also, 
entweder ist bei mir gerade der Wurm drin, oder es ist schon zu spät. 
Wer weiß.
Bei AVR-Studio habe ich es wie folgendermaßen gemacht.

.equ F_CPU = 3686400
.equ CYCLE_HIGH = HIGH( F_CPU / 100 / 3 )
.equ CYCLE_LOW = LOW( F_CPU / 100 / 3 ) - 1

Nun wollte ich es halt nur auf avr-as portieren. Aber irgendwie mag der 
nicht.

Wenn ihr dazu eine Lösung habt, wäre ich euch sehr dankbar!

mfg
sep

[sep (Gast)]

sep schrieb:
> F_CPU wird richtig mit übergeben mit 368600UL
Sry, sind 3686400 macht aber auch keinen großen unterschied.
Was ich mich wundere ist, normalerweise wird das doch durch den 
Präprozessor schon ersetzt. Das sollte es zumindest. Sonst ist es 
sinnlos.

[Andreas B. (Gast)]

Das -1 muss dann noch in die Klammer mit rein. So funktioniert es auf 
jeden Fall bei mir:

#define F_CPU 3686400

    ldi r18, hi8( F_CPU / 100 / 3 )
    ldi r19, lo8( F_CPU / 100 / 3 - 1)

test.o:     file format elf32-avr


Disassembly of section .text:

00000000 <.text>:
   0:  20 e3         ldi  r18, 0x30  ; 48
   2:  3f ef         ldi  r19, 0xFF  ; 255

[sep (Gast)]

Andreas B. schrieb:
> Das -1 muss dann noch in die Klammer mit rein.


Dann geht das auch bei mir.
Was ich auch noch geändert habe ist, das F_CPU nun nich mehr das Suffix 
UL bei mir hat. Dann klappte das auch.

[Jörg W. (dl8dtl) (Moderator)]

sep schrieb:
> Was ich auch noch geändert habe ist, das F_CPU nun nich mehr das Suffix
> UL bei mir hat.

Ja, der Assembler kennt keine Datentypen und daher auch keine Suffixe,
die ja in C nur einen bestimmten Datentypen für die Konstante
erzwingen sollen.

[Rolle (Gast)]

Hallo,

ich weiss ja nicht was du mit dem Wert anstellen willst, aber bedenke 
dass die Zerteilung in ein Low-Byte und ein High-Byte in der ersten 
Zeile ohne die -1 und in der zweiten Zeile mit der -1 zu einem ganz 
anderen Gesamt-Wert führt ( siehe Listing von Andreas 0x30,0xff !!!???)

[Rolle (Gast)]

und zur Übergabe an einen Baudrate-Generater oder 16Bit Timer ungeeignet

Sorry, hab versehentlich absenden gedrückt !!!

[sep (Gast)]

Sry, ich hab das Thema nun fast vergessen gehabt. Ich wollte eigentlich 
nur eine kleine delay Funktion schreiben. Die ich auch recht exakt in 
asm und C einsetzen kann. Da ich damit nun schon einige Zeit fertig bin, 
poste ich die gerne. Zum einen ist dort die kleinste Einheit eine 
hundertstel Sekunde. Zum nächsten ist die nicht ganz takt-genau aber gut 
ausreichend.

.section .text
.global kdelay_cs

kdelay_cs:
                ldi r18, hi8( F_CPU / 100 / 3 )
        loop1:
                ldi r19, lo8( ( F_CPU / 100 / 3 ) - 1 )
        loop2:
                dec r19
                brne loop2

                dec r18
                brne loop1

        dec r24
        brne kdelay_cs

        ret

Jörg Wunsch schrieb:
> Ja, der Assembler kennt keine Datentypen und daher auch keine Suffixe,
> die ja in C nur einen bestimmten Datentypen für die Konstante
> erzwingen sollen.

Aus diesem Grund übergebe ich F_CPU nochmals bei gas. Dann klappt das 
auch. Also, vielen Dank euch.

[Jörg W. (dl8dtl) (Moderator)]

Wenn du dir mal ansiehst, wie die delay loops in <util/delay_basic.h>
implementiert sind, dann geht das auch alles via inline asm direkt in
C.  Der Vorteil ist, dass man dann den C-Compiler dazu missbrauchen
kann, selbst Gleitkommaausdrücke zur Compilezeit aufzulösen, wie das
in <util/delay.h> gemacht wird.

Noch genauer wird es in den aktuellen (gepatchten) Compilerversionen
durch Benutzung von __builtin_avr_delay_cycles().  Der Compiler kann
dann seinen Overhead selbst mit einplanen.