XC8 inline Assembler

[Siro]

Einen schönen guten Morgen,
Ich programmiere mit dem XC8 Compiler und wollte was in Assembler einfügen:

asm("movlw 255");
asm("movwf FSR0L");
asm("delay_a:");
asm("decf FSR0L,F");
asm("btfss STATUS,Z"); hier liegt wohl irgend ein Problem vor ?
asm("goto delay_a");

Der Inline Assembler kennt aber die Statusflags C,Z,....nicht...

Hab schon ne Stunde gegoogelt und auch in der XC8 Anleitung gestöbert.
Keine Ahnung wo das Problem liegt.
Direkt in Assembler hab ich das zig tausendfach gemacht.

Kommt davon wenn man auf "C" umsteigt.....selber schuld......

Siro

[Siro]

Habe jetzt den Code geändert, dann brauche ich das Statusbit Z nicht abfragen.

asm("decfsz FSR0L,f");
asm("goto delay_a");

aber irgendwie muss man ja auch auf die Statusbits zugreifen können...aber wie ?


warum ich Assembler benötige ?
Eine definierte Laufzeit, das geht nicht in "C" sondern nur in Assembler und die Timer sind alle vergeben....

[shedepe]

Doofe Frage. Hast du dem Compiler gesagt, dass du Inline Assembler verwenden willst? Wenn ich mich nicht täusche muss man das bei den meistens Toolchains explizit aktivieren.

[witkatz]

Eine definierte Laufzeit, das geht nicht in "C" sondern nur in Assembler und die Timer sind alle vergeben....

für eine definierte Wartezeit von x Zyklen würde ich die Funktion _delay(x) verwenden.

_delay(1020);

ist mMn lesbarer als

#asm    
    movlw 255
    movwf FSR0L
delay_a:
    decf FSR0L,F
    btfss STATUS,2 
    goto delay_a
#endasm

Und dann gibts noch die zeitbezogenen __delay_us(x) und __delay_ms(x) für die man lediglich _XTAL_FREQ definieren muss.

[Siro]

Guten Abend,
erstmal Danke für euro Infos.

@shedepe
Bei dem XC8 Compiler muss man "eigentlich" nichts extra einstellen, hab mir das nochmal genau angesehen.

@witkatz
so wollte ich das eigentlich haben, dann habe ich irgendwo gelesen, dass man jede Zeile separat als asm (" "); schreiben soll.

ich habe jetzt deine Variante probiert: siehe Screenshoot:


irgendwie mag er das nicht:

unable to resolve identifier movlw
unable to resolve identifier movwf
unable to resolve identifier delay_a unexpected token
unable to resolve identifier decfsz
unable to resolve identifier delay_a
unable to resolve identifier nop

unexpected token }


Jetzt das erstaunliche, er hat trotzdem ein Compilat erstellt.....
ich glaub ich muss die ganze IDE neu installieren, da ist doch was faul.


Habe komplett neu installiert. IDE und Compiler.
Das ändert aber nichts. Sehr merkwürdig.

Aber der Hinweis mit dem __delay_us habe ich grad ausprobiert.
Man muss nur ein define _XTAL_FREQ definieren und dann erzeugt der Compiler selbst den Code für die Warteschleife.
Supi, das wuste ich noch nicht. Ist ja auch viel übersichtlicher. Danke Dir witkatz

[shedepe]

http://ww1.microchip.com/downloads/e...Doc/52053B.pdf
Abschnitt 5.12..3.2
Du hast ein #include <xc.h> in deinem File?.

[witkatz]

Du hast ein #include <xc.h> in deinem File?.

Ich kann nicht für Siro antworten, aber ich habe für meinen oben geposteten Beispielcode die xc.h als einzigen Header eingebunden.
Die Fehlermeldungen im Editor kommen bei mir auch. Es ist wohl das normale Verhalten des Preparsers, so steht es zumindest im MPLAB X IDE User's Guide Chap. 9.7.7
Als Workaround könnte man die Multiline Schreibweise benutzen, allerdings dann ohne die Möglichkeit den Assemblecode zu debuggen

asm("\
    movlw 0x9D;         \
    movwf FSR0L;        \
delay_a:                \
    decfsz FSR0L,F;     \
    goto delay_a;       \
    nop;                \
");

Ich persönlich mag das mischen von C und ASM nicht. Ich habe bis jetzt inline Assembler gemieden und möchte dabei auch bleiben. Wenn ich um Assembler nicht herum kommen sollte, würde ich lieber das ganze Projekt oder zumindest ein Modul komplett in Assembler machen wollen.

[Siro]

So, da bin ich wieder,

Ich habe auch als "einzigne include Datei XC.h" bei mir drin.

Jo, Du hast recht witkatz, da steht was im MPLAB UDE User Guide.....Bei mir Kapitel 7.5.2
Fehler ignorierenm, es wird trotzdem ein Code erzeugt
Okay, dann ist das nicht nur bei mir so....

Die Mischung mit Assembler und C ist ja meist nicht erforderlich.
Ich wuste ja auch nicht, dass es dieses __delay_us Macro gibt.
Ich hab die Taktzyklen selbst berechnet, Naja ich bin mal ehrlich mit dem Simulator angepasst....

Die eigentliche Frage mit den Statusbits abfragen bei der asm("xxx") Abfrage bleibt aber eigentlich noch offen.
Das müste ja auch irgendwie gehen, wenngleich ich das ja jetzt nicht mehr brauche.

[witkatz]

Die eigentliche Frage mit den Statusbits abfragen bei der asm("xxx") Abfrage bleibt aber eigentlich noch offen.

Bei mir funktionierte es mit

asm("btfss STATUS,2");

... weil in dem zu dem PIC dazugehörenden Header pic16fxxx.h der STATUS Register dem inline Assembler per asm("STATUS equ 03h") definiert wird. Dieser Header wird über die xc.h eingebunden und dadrin sind die SFR für den Inline Assembler definiert - aber nicht die Bits. Bei MPASM sind die SFR und die einzelnen Bits in der p16fxxx.inc definiert. Man kann die Definition der Bits für den Inline Assembler ergänzen, dann funktioniert die Zeroflag Abrage auch symbolisch

asm("Z  EQU  0x0002");
//...
asm("   btfss STATUS,Z      ");

Nachtrag:

Eine definierte Laufzeit, das geht nicht in "C" sondern nur in Assembler...

Darauf sollte man sich im Inline Assembler nicht verlassen, der vom XC8 compiliert und - wenn man es ihm nicht verbietet - optimiert wird. Ich wollte mal interessenhalber deine erste Delay-Routine als separates ASM Modul einbinden s.Bild und schwups wird die DECF BTFSS Sequenz zu DECFSZ optimiert. Ich habe mich nur gewundert, warum eine ASM Routine, die vorher mit asm() Anweisungen in C genau 1ms gebraucht hat (Simulation für PIC16F88 ), als ASM Modul um 25% schneller läuft. Gut zu wissen, dass XC8 auch innerhalb von ASM optimiert, aber für deterministische Laufzeiten ist das nicht so gut.

[Siro]

Gut zu wissen, dass XC8 auch innerhalb von ASM optimiert, aber für deterministische Laufzeiten ist das nicht so gut.

Upps, das kann natürlich nach hinten losgehen. Wär nicht das erste Mal, dass mir der C-Compiler "wichtigen Code" wegoptimiert
Auch wenn alle Optimierungen ausgeschaltet werden, sind alle mir bekannten C Compiler der Meinung immer noch was wegzuoptimieren....
Grausam, aber leider nicht zu ändern. Naja ich war noch nie ein "C" Freund und da hat sich bis heute auch nix dran geändert.
"C" ver"C"ehnfacht halt die Entwicklungszeit.

Aber bitte jetzt keine Diskussionen . Das ist ja nur meine persönliche Meinung zu "C"

Hab nochmal vielen Dank für die Info, damit hätte ich sicher nicht gerechnet, dass der Inline Code auch optimiert wird.