Inline Assembler

[H.Joachim S. (crazyhorse)]

Bin ja nicht unbedingt ein Freund von, aber diesmal gehts nicht anders, 
jeden Takt zählt.

#asm
      .equ PORTB=0x18
      .equ OCR1B=0x2B
      in _sreg_bak, SREG
      mov _ocr1b_2, _ocr1b_2_gl
      mov _set_pin, _set_pin_gl
      mov _clr_pin, _clr_pin_gl
      in _gp_reg, PORTB
      or _gp_reg, _set_pin
      out PORTB, _gp_reg
      out OCR1B, _ocr1b_1_gl
      mov _clr_pin_bak, _clr_pin
      out SREG, _sreg_bak
#endasm

Nur interessehalber: Wieso kennt der Assembler SREG, aber PORTB bzw 
OCR1B nicht? Mit den beiden .equ klappt es so, wie es soll. In der 
tiny25.h stehen alle 3 drin, aber die wird wohl vom Assembler nicht 
benutzt. Woher aber kennt der Assembler SREG?

[quak (Gast)]

Also ohne zu wissen, was das genau ist, hätte ich eine Idee. Vielleicht 
kann die cpu ihre ports nur indirekt adressieren, also über ein Register

[Floh (Gast)]

H.joachim Seifert schrieb:
> Bin ja nicht unbedingt ein Freund von, aber diesmal gehts nicht anders,
> jeden Takt zählt.

Die mov-Befehle erscheinen mir irgendwie unnötig?

[H.Joachim S. (crazyhorse)]

Nönö, die liegen allesamt im althergebrachten I/O-Bereich.
Compiler ist CodeVision, Assembler avrasm2.

[quak (Gast)]

Wenn du willst, das andere deinen Code lesen, solltest du zumindest ein 
Bisschen Kosmetik anbringen, dh. zB. bedeutungsvolle Namen wählen für 
deine Variablen. Was soll das alles bedeuten?

[H.Joachim S. (crazyhorse)]

Es geht doch gar nicht um den Code, völlig wurscht, was da steht.

Ich will nur wissen (rein akademisch), warum ich dem Assembler sagen 
muss, wo PORTB liegt (0x18), er aber weiss, auf welcher Adresse SREG 
(0x3f) sitzt.

[Toralf W. (willi)]

Die Variablen sind doch eigentlich egal. Er wollte doch wissen, wieso 
die Ports unbekannt sind.
@crazyhorse: kann sein das der Assembler die Gerätedatei braucht, warum 
er allerdings sreg kennt verstehe ich auch nicht. Versuche mal .include 
"m8def.inc" (an den AVR anpassen) am statt dem .equ

Gruß Willi

[MWS (Gast)]

H.joachim Seifert schrieb:
> Bin ja nicht unbedingt ein Freund von,

Merkt man.

> jeden Takt zählt.

Dann würde man, falls PortB unterhalb $20 liegt, besser SBI verwenden, 
denn das ORI ist der einzige Befehl, der das SREG verändert. Ohne das 
ORI kann man sich das Sichern des SREG sparen.

H.joachim Seifert schrieb:
> In der tiny25.h stehen alle 3 drin, aber die wird wohl vom Assembler
> nicht benutzt.

Wird die .h auch inkludiert ?

> Woher aber kennt der Assembler SREG?

Woanders definiert ? Ich kenn' keinen AVR, bei dem SREG nicht an $3F 
liegt.

[H.Joachim S. (crazyhorse)]

MWS schrieb:
> H.joachim Seifert schrieb:
>> Bin ja nicht unbedingt ein Freund von,
>
> Merkt man.
Soso...
>> jeden Takt zählt.
Zumindest muss ich samt Aufruf, Sichern und reti unter 32 Takten 
bleiben, und das klappt direkt in C nicht.

> Dann würde man, falls PortB unterhalb $20 liegt, besser SBI verwenden,
> denn das ORI ist der einzige Befehl, der das SREG verändert. Ohne das
> ORI kann man sich das Sichern des SREG sparen.
_set_bit enthält aber je nach Zustand 0,1,2 oder 3 Portpins, keinesfalls 
schneller als das Sichern des SREG...

> H.joachim Seifert schrieb:
>> In der tiny25.h stehen alle 3 drin, aber die wird wohl vom Assembler
>> nicht benutzt.
>
> Wird die .h auch inkludiert ?
ja sicher.
>> Woher aber kennt der Assembler SREG?
>
> Woanders definiert ? Ich kenn' keinen AVR, bei dem SREG nicht an $3F
> liegt.

Vielleicht ist das die Erklärung. Fest im Assembler eingebaut...

[Johann L. (gjlayde)]

Mal wieder ein typischen Beispiel für Informationsüberflutung:

- um welchen Assembler geht's überhaupt?
- ist ds die ganze Quelle?
- worin wird eingebettet? C? BASIC?
- Welche Entwicklungsumgebung? gcc? Offenbar nicht...

[Einer (Gast)]

SREG ist CPU
PORT ist Peripherie

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

Johann L. schrieb:
> Mal wieder ein typischen Beispiel für Informationsüberflutung:
>
> - um welchen Assembler geht's überhaupt?
> - ist ds die ganze Quelle?
> - worin wird eingebettet? C? BASIC?
> - Welche Entwicklungsumgebung? gcc? Offenbar nicht...

1, 3 und 4 hat er beantwortet: avrasm2, eingebettet in CodeVision
(also C).

Einer schrieb:
> SREG ist CPU
> PORT ist Peripherie

Ja, und?  Beides sind jedoch IO-Register.  SREG, SPL und SPH liegen
beim AVR im IO memory space, sind also keine inhärent dem Assembler
bekannten Register wie r0 ... r31.

[H.Joachim S. (crazyhorse)]

Johann L. schrieb:
> Mal wieder ein typischen Beispiel für Informationsüberflutung:
>
> - um welchen Assembler geht's überhaupt?
steht da, avrasm2
> - ist ds die ganze Quelle?
tut nichts zur Sache
> - worin wird eingebettet? C? BASIC?
steht da, CodeVision
> - Welche Entwicklungsumgebung? gcc? Offenbar nicht...
s.o.

Ist schon interessant, Hauptsache was geschreibselt....

@Einer: Macht irgendwie auch nicht viel Sinn.
MCUCR/MCUSR/OSCAL sind auch CPU, funktionieren ohne .equ nicht.
SPL wiederum geht direkt.

[H.Joachim S. (crazyhorse)]

@Jörg: Danke, genau das ist das Problem.
Naja, eigentlich es ja gar kein Problem, habe mich nur darüber gewundert 
und wollte wissen, warum da ein Unterschied ist. Meiner Meinung nach 
waren die Informationen völlig ausreichend, das "Problem" zu 
beschreiben.

Aber die Beissreflexe funktionieren gut hier :-)