Pullup aktivieren in AVR-Assembler

[Lutz S. (lutzs)]

Hallo,

habe neulich ein recht komplexes Programm in Assembler für einen AVR 
gesehen, das mir dennoch sehr elegant erschien. Das hat mir einfach 
gefallen.

Nachdem ich sonst immer in C programmierte wollte ich mich deshalb mal 
näher mit Assembler beschäftigen.

Meine Frage und bestimmt ein einfaches Problem: ich möchte an einem Pin 
den Pullup aktivieren.

Der Code funktioniert, aber ginge das mit Abfrage des bisherigen Status 
auch kürzer? Oder auch: kann man einzelne Bits da draussen ausserhalb 
von R16-R31 auch direkt setzen?

lds r16,PORTB_PIN2CTRL
sbr r16,8 ;Bit 3 für Pullup enable setzen
sts PORTB_PIN2CTRL,r16 ;Pullup aktivieren PB2

Und weiter - Statusabfrage am Pin PB2 und dann abhängig davon einen 
Ausgang setzen oder rücksetzen( als Beispiel, oder eben irgend was 
anderes veranlassen):

lds a, VPORTB_IN ;Eingänge PortB in a laden, a ist hier wieder R16
sbrs a,2 ;skip next, if high
LED_green_on
sbrc a,2 ;skip next, if low
LED_green_off

Geht das besser (und gibt es so was wie 'else')?

Entschuldigt die aus eurer Sicht vielleicht dummen Fragen, Assembler ist 
für mich bisher weitgehend Neuland.

Danke für euren Input.

[Peter D. (peda)]

sbi bzw. cbi

[Falk B. (falk)]

Lutz S. schrieb:
> Entschuldigt die aus eurer Sicht vielleicht dummen Fragen, Assembler ist
> für mich bisher weitgehend Neuland.

Ohje, klingt wie "Das Internet ist für uns alle Neuland" . . .

[Karl M. (Gast)]

Noch ein Tipp zur Schreibweise,

einiges kann eindeutiger schreiben:

; alt
sbr r16,8 ;Bit 3 für Pullup enable setzen

; besser
sbr r16,(1<<3) ;Bit 3 für Pullup enable setzen

Auch verwende ich sehr viele Macros, die die Arbeit im Code erledigen.

Auch kann man über je ein Macro, die Auswertung der Register,
ob IN/ OUT oder LDS/ STS verwendet werden muss, vereinfachen.

Hier sind einige Beispiele aus der LunaAVR Implementierung:

.macro xIn
.if @1<64
in    @0,@1
.else
lds    @0,@1
.endif
.endmacro

.macro xOut
.if @0<64
out    @0,@1
.else
sts    @0,@1
.endif
.endmacro

.macro gCbi
.if @0<32
cbi    @0,@1
.else
xIn    WL,@0
cbr    WL,(1<<@1)
xOut    @0,WL
.endif
.endmacro

.macro gSbi
.if @0<32
sbi    @0,@1
.else
xIn    WL,@0
sbr    WL,(1<<@1)
xOut    @0,WL
.endif
.endmacro

.macro xCbi
.if @0<32
cbi    @0,@1
.else
push  WL
xIn    WL,@0
cbr    WL,(1<<@1)
xOut  @0,WL
pop    WL
.endif
.endmacro

.macro xSbi
.if @0<32
sbi    @0,@1
.else
push  WL
xIn    WL,@0
sbr    WL,(1<<@1)
xOut    @0,WL
pop    WL
.endif
.endmacro

Wir verwenden diese List an internen Registernamen

;standard register names
;low block A
.def  _LA0    = R0
.def  _LA1    = R1
.def  _LA2    = R2
.def  _LA3    = R3
;low block B
.def  _LB0    = R4
.def  _LB1    = R5
.def  _LB2    = R6
.def  _LB3    = R7
;temp block A
.def  _TMP0    = R8
.def  _TMP1    = R9
.def  _TMP2    = R10
.def  _TMP3    = R11
;temp block B
.def  _TMPA    = R12
.def  _TMPB    = R13
.def  _TMPC    = R14
.def  _TMPD    = R15
;high block A
.def  _HA0    = R16
.def  _HA1    = R17
.def  _HA2    = R18
.def  _HA3    = R19
;high block B
.def  _HB0    = R20
.def  _HB1    = R21
.def  _HB2    = R22
.def  _HB3    = R23
;pointers
.def  WL    = R24
.def  WH    = R25
.def  XL    = R26
.def  XH    = R27
.def  YL    = R28
.def  YH    = R29
.def  ZL    = R30
.def  ZH    = R31

[c-hater (Gast)]

Lutz S. schrieb:

> Nachdem ich sonst immer in C programmierte wollte ich mich deshalb mal
> näher mit Assembler beschäftigen.

Tja, das fängt damit an, sich den Sprachumfang reinzuziehen. Wie in 
jeder anderen Sprache auch. Damit solltest du also beginnen. Das Lustige 
an Assembler ist: Der Sprachumfang ist i.d.R. recht klein, also sehr 
schnell vollumfänglich erlernbar.

Schwierig ist nur, ihn sinnvoll zu benutzen. Aber so weit bist du längst 
noch nicht.

> auch kürzer? Oder auch: kann man einzelne Bits da draussen ausserhalb
> von R16-R31 auch direkt setzen?

Diese Frage könntest du dir dann schon selbst beantworten. Naja, 
vielleicht nicht vollständig, aber immerhin könntest du eine sinnvollere 
Frage stellen, einer der man anmerken kann, dass du dich zumindest 
andeutungsweise tatsächlich mit der Materie beschäftigt hast.

> Und weiter - Statusabfrage am Pin PB2 und dann abhängig davon einen
> Ausgang setzen oder rücksetzen( als Beispiel, oder eben irgend was
> anderes veranlassen):
>
> lds a, VPORTB_IN ;Eingänge PortB in a laden
> sbrs a,2 ;skip next, if high
> LED_green_on
> sbrc a,2 ;skip next, if low
> LED_green_off
>
> Geht das besser

Sicher. Und wieder: diese Frage hättest du dir selber beantworten 
können, wenn du wenigstens die Worte der Sprache gelernt hättest...

> (und gibt es so was wie 'else')?

Ja, immer. Da das 'if' im Prinzip immer ein bedingtes 'goto' ist, ist 
das 'else' prinzipbedingt natürlich immer die Stelle, wo nicht 
hingesprungen wird, also die nächste Anweisung...

[Lutz S. (lutzs)]

>> (und gibt es so was wie 'else')?
>
> Ja, immer. Da das 'if' im Prinzip immer ein bedingtes 'goto' ist, ist
> das 'else' prinzipbedingt natürlich immer die Stelle, wo nicht
> hingesprungen wird, also die nächste Anweisung...

Ich dachte bei 'else' an etwas was er dann alternativ ausführt.

Also entweder Zweig A oder Zweig B ausführen, und dann geht es weiter.

[leo (Gast)]

Karl M. schrieb:
> ; besser
> sbr r16,(1<<3) ;Bit 3 für Pullup enable setzen

Und diese unsaeglichen Klammern sind genau wofuer? Seit irgendwann ein 
unbedarfter Programmierer die so hingemalt hat, wird das ewig kopiert, 
in ASM und C.

leo

[c-hater (Gast)]

leo schrieb:

> Und diese unsaeglichen Klammern sind genau wofuer?

Sie bewirken natürlich garnix, hier hätte ich sie sicher auch nicht 
gesetzt.

Trotzdem ist meine Meinung: Immer lieber ein Klammernpaar zu viel als 
eins zu wenig. Macht die Sache oft einfacher lesbar. Man muss nicht auch 
noch beim Lesen des Codes über Operator-Präzedenzen nachdenken. Die 
Klammer stellt absolut klar, was intendiert war.

Sie kostet auch nix zur Runtime, und sie macht sogar oft das 
Compilieren/Assemblieren schneller, weil der Tokenizer früher 
entscheiden kann.

Sprich: nur Volldeppen regen sich wegen eines überflüssigen 
Klammerpaares auf. Typisch sind das dann genau die C-ler, die glauben, 
das Programm mit den wenigstens Tastenanschlägen und Zeilen wäre auch 
das, was am effizientesten liefe...

Nö, es ist nur sicher das, was sich am schlechtesten lesen läßt...

[leo (Gast)]

c-hater schrieb:

> ... Immer lieber ein Klammernpaar zu viel als
> eins zu wenig. Macht die Sache oft einfacher lesbar.

Mehr Klammerung dient nicht unbedingt der Lesbarkeit, zumal sie so klar 
ist wie hier.

> Sie kostet auch nix zur Runtime, und sie macht sogar oft das
> Compilieren/Assemblieren schneller, weil der Tokenizer früher
> entscheiden kann.

Nein. Der Tokenizer muss wieder eine Ebene entfernen. Die Entscheidung 
faellt auf Grund der Prioritaet schon frueher.

> Sprich: nur Volldeppen regen sich wegen eines überflüssigen
> Klammerpaares auf.

Keiner hat sich aufgeregt, der V.. gehoert dir.

> Typisch sind das dann genau die C-ler,

Ich schrieb explizit ASM und C ...

leo

[Karl M. (Gast)]

Hallo Lutz S.,

spannend wäre jetzt zu erfahren, ob die Anregungen Dir weiter helfen.

Zu Klammern, ich schreibe sie gerne und häufig!

Peter Dannegger (peda) verwendete mal folgendes für das Zusammensetzen 
von Bitmasken, was in C.
Ist auch ok!

; peda
ldi r16,1<<0^1<<2^1<<4
; oder
ldi r16,1<<0|1<<2|1<<4

[S. R. (svenska)]

Lutz S. schrieb:
> Geht das besser (und gibt es so was wie 'else')?

Ist nicht AVR-Assembler, aber das Prinzip ist überall gleich.

  CP A, 4    ; vergleiche A und 4
  JP Z, YEAH ; wenn gleich (Zeroflag), springe nach YEAH

  ; hier ist der else-Teil
  ; denn A war nicht gleich 4
  ; also wurde nicht gesprungen

  JP FERTIG
YEAH:

  ; hier ist der if-Teil
  ; denn A war gleich 4
  ; also wurde gesprungen

FERTIG:

  ; hier ist nach dem if
  ; denn das wird nach beiden
  ; Teilen ausgeführt

Ist also recht logisch.

[Lutz S. (lutzs)]

Danke für eure Tips. Lese weiter mit und im Instruction Set Manual.

Im Moment sieht das nun so aus:

.DEF a = r16

#define LED_green_off  sbi VPORTB_OUT,7
#define LED_green_on  cbi VPORTB_OUT,7
#define LED_red_off  sbi VPORTB_OUT,6
#define LED_red_on  cbi VPORTB_OUT,6

sbi VPORTB_DIR,6 ;PB6 ist Ausgang
sbi VPORTB_DIR,7 ;PB7 ist Ausgang

ldi a,1<<3|1<<7
sts PORTB_PIN2CTRL,a ;PB2 Pullup und invers

ldi a,1<<3
sts PORTB_PIN3CTRL,a ;PB3 Pullup

start:
  sbic VPORTB_IN,2
  rjmp green_off
  LED_green_on
  rjmp green_ende
green_off:
  LED_green_off
green_ende:

  sbis VPORTB_IN,3
  rjmp red_off
  LED_red_on
  rjmp red_ende
red_off:
  LED_red_off
red_ende:

  rjmp start

[Karl B. (gustav)]

Hi,
bei den Atmel AVRs lohnte sich einmal ein Blick auf die 
targetspezifischen Include-Files.
Da wird genau auf Dein Problem hingewiesen.

;* DESCRIPTION
;* File Name         : "2323def.inc"
;* Title             : Register/Bit Definitions for the AT90S2323
;* Please observe the difference in using the bit names with 
instructions
;* such as "sbr"/"cbr" (set/clear bit in register) and "sbrs"/"sbrc"
;* (skip if bit in register set/cleared). The following example 
illustrates
;* this:
;*
;* in    r16,PORTB             ;read PORTB latch
;* sbr   r16,(1<<PB6)+(1<<PB5) ;set PB6 and PB5 (use masks, not bit#)
;* out   PORTB,r16             ;output to PORTB
;*
;* in    r16,TIFR              ;read the Timer Interrupt Flag Register
;* sbrc  r16,TOV0              ;test the overflow flag (use bit#)
;* rjmp  TOV0_is_set           ;jump if set
;* ...                         ;otherwise do something else

Und "Memory Mapped" Register können nur über "Umwege" beschrieben 
werden.
Welche das sind, ist auch targetspezifisch.
Man sieht sofort, dass Portierbarkeit der Progs. u. U. eingeschränkt 
ist.

Dann Zählweise nicht 1...8  sondern 0...7 bei 8-Bit Breite
Also sbi r16, 0   ; setzt Bit 0 in Register r16
Du kannst auch für das direkte Bit-Setzen folgendes machen.
ldi r16, 0b00000001
macht man aber nicht, weil r16 für arithmetische Operationen bereits 
reserviert sein könnte und Rechenergebnise der letzten Operation 
enthält, die im Verlauf des Programms später wieder gebraucht werden, so 
dass man dies Register auf den Stapel "rettet".
Und hinterher wieder zurückholt. So lautete der Workaround oben besser:
push r16
ldi r16, 0b00000001
pop r16

Für die Dauer des Befehlsausführung wird dann Bit 0 von r16 auf 1 
gesetzt.

Das direkte Bit-Setzen ist da codesparender.

Praktisches Beispiel, wie man einen definierten Impuls generiert:

Enable:

nop
sbi  impuls, 0  ;Enable auf "high" setzen
nop      ;Impulsdauer mindestens
nop      ;0,5 Mikrosekunden laut Datenblatt
nop      ;lieber ein paar "nops" mehr
nop      ;spendieren
nop
nop
nop
cbi  impuls, 0  ;Enable auf "low" zurücksetzen
nop
ret


Das ist zum Beispiel der Enable-Impuls für ein LCD nach Hitachi-Spec.

ciao
gustav

[Lutz S. (lutzs)]

Hallo Karl,

habe hier die tn3217def.inc in Verwendung, da wird das leider nicht mehr 
so ausführlich erläutert.

Danke auch an dich für deine Tips.

[S. R. (svenska)]

Außerdem lernt man viel, indem man sich guten Code von Anderen anschaut. 
Gerade bei Assembler ist das sehr nützlich.

Es gibt z.B. ein paar Codeschnipsel, mit denen ein Videosignal erzeugt 
wird. Da ist viel Arbeit reingeflossen, der Code ist entsprechend stark 
optimiert.

Du kannst auch einfach ein paar C-Schnipsel durch den Compiler schieben 
und dir die Ergebnisse anschauen. Auch das ist sehr lehrreich.

Natürlich immer die Instruction Reference neben der Tastatur, damit sich 
das nachvollziehen lässt.

Es bringt nur wenig, sich an schlechtem Code zu orientieren. Um mit 
Assembler überhaupt einen Vorteil zu C zu haben, muss man schon sehr 
guten Code schreiben können.

[Oliver S. (oliverso)]

Karl B. schrieb:
> Und "Memory Mapped" Register können nur über "Umwege" beschrieben
> werden. Welche das sind, ist auch targetspezifisch.

Bei AVRs ist das allerdings letztendlich einfach, denn da sind 
grundsätzlich alle Register Memory-mapped.

Den Inhalt dieses Dokuments muß man einfach kennen, wenn man AVRs in 
Assembler programmieren will:

 http://ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf

Oliver

[c-hater (Gast)]

Oliver S. schrieb:

> Bei AVRs ist das allerdings letztendlich einfach, denn da sind
> grundsätzlich alle Register Memory-mapped.

Nein. Die MCU-Register sind bei den ATXMega nicht memory-mapped zu 
erreichen. Und damit auch nicht bei den ganz neuen Tinys und Mega0, denn 
die haben den XMega-Core.

Und bezüglich der SFIORs ist es natürlich ziemlich kontraproduktiv, sie 
langsam über den SRAM-Space anzusprechen, wenn man sie auch schnell über 
den SFIOR-Space ansprechen kann.

Für In/Out ist das aber überhaupt kein Problem, mit zwei kleinen Makros 
kann man den Assembler die Arbeit erledigen lassen, nachzuschlagen, ob 
das Register nur im SFIOR-Space erreichbar ist oder nicht. Solche Makros 
wurden hier im Forum schon mehrfach veröffentlicht.

Man sollte allerdings in diese Makros gleich Warnungen einbauen. Auch 
wenn es funktional keinen Unterschied macht, wie genau auf das Register 
zugegriffen wird, in zeitkritischen Routinen kann natürlich der eine 
Takt Unterschied sehr wohl den Unterschied zwischen geht und geht nicht 
ausmachen...

Schwieriger ist das allerdings für sbic/sbis/sbi/cbi. Da gibt es leider 
keine ähnlich einfache Makro-Lösung, weil für die Ausweichvariante immer 
ein MCU-Register als Hilfe benötigt wird.

[Karl B. (gustav)]

Oliver S. schrieb:
> Bei AVRs ist das allerdings letztendlich einfach, denn da sind
> grundsätzlich alle Register Memory-mapped.

Hi, wurde schon gesagt, nicht ganz richtig.
Noch ein praktisches Beispiel, was ich meinte.
Der Timer-Init wird bei verschiedenen Targets anders ausgeführt.
Prog. ist nicht 1:1 portierbar.

ciao
gustav