ATtiny26 mag rcall nicht

[Achim (Gast)]

Hallo zusammen,

ich habe das Problem, das der Attiny26-16 den rcall Befehl nicht mag, er 
bleibt da immer hängen. Ich benutze AtmelStudio 6.0 und schreibe in asm.
Das Programm läuft ohne Probleme auf dem ATtiny13-20 mit rcall. Wenn ich
die Unterprogramme ins Hauptprogramm hole, läuft auch der ATtiny26.
Die inc. Datei habe ich natürlich umgestellt. Programmieren läst sich 
der ATtiny 26 ohne probleme. Keine Fehlermeldung.

Hoffe es kann mir bei diesem Problem jemand weiterhelfen.

l.g. Achim

[Walter S. (avatar)]

Achim schrieb:
> Hoffe es kann mir bei diesem Problem jemand weiterhelfen.

ohne Programm sicher nicht

[(ungebetener) (Gast)]

Schon mal ins Datenblatt geschaut, ob der rcall im Mikrocode vorhanden 
ist?

[Hannes L. (hannes)]

Walter S. schrieb:
> ohne Programm sicher nicht

Doch, der Tiny13 initialisiert seinen Stackpointer per Hardware beim 
Reset, beim Tiny26 muss man den Stackpointer von Hand initialisieren.

Achim schrieb:
> Wenn ich
> die Unterprogramme ins Hauptprogramm hole, läuft auch der ATtiny26.

Eben, das deutet darauf hin, dass der Stackpointer nicht initialisiert 
ist...

...

[Achim (Gast)]

Den Befehl gibt es, geht auch wenn ich ihn nur ein mal aufrufe, aber 
beim zweiten mal aus einem billigen Blikprogramm mit zwei LED bleib er 
stehen.

.include "tn26def.inc"

rjmp     Anfang

Anfang:
   ldi     r16,0xff
   out     ddra,r16
   ldi     r16,0x18
   out     ddrb,r16

Schleife:
   ldi     r16,0x10
   out     portb,r16
;Warte:
      ldi     r17,255
   Warte1:
      ldi     r18,255
      Warte2:
       dec     r18
         brne    Warte2
       dec     r17
       brne    Warte1
;ret     ;Rücksprung
   ;rcall   Warte
   ldi     r16,0x0
   out     portb,r16
;Pause:
      ldi     r17,255
   Pause1:
      ldi     r18,255
      Pause2:
       dec     r18
         brne    Pause2
       dec     r17
       brne    Pause1
;ret     ;Rücksprung
   ;rcall   Pause

   ldi     r16,0x8
   out     portb,r16
;Warte:
      ldi     r17,255
   Warte3:
      ldi     r18,255
      Warte4:
       dec     r18
         brne    Warte4
       dec     r17
       brne    Warte3
;ret     ;Rücksprung
   ;rcall   Warte
   ldi     r16,0x0
   out     portb,r16
;Pause:
      ldi     r17,255
   Pause3:
      ldi     r18,255
      Pause4:
       dec     r18
         brne    Pause4
       dec     r17
       brne    Pause3
;ret     ;Rücksprung
   ;rcall   Pause
rjmp     Schleife

[Achim (Gast)]

Wie initaliesiert man einen Stckpionter?

[Spess53 (Gast)]

Hi

Hannes hatte Recht:

>Eben, das deutet darauf hin, dass der Stackpointer nicht initialisiert
>ist...

MfG Spess

[Achim (Gast)]

Danke, und wie mache ich das mit dem Stackpointer?

[Hannes L. (hannes)]

Achim schrieb:
> Wie initaliesiert man einen Stckpionter?

Man setzt SPL und ggf. SPH auf RAMEND.

...

[Spess53 (Gast)]

Hi

>Wie initaliesiert man einen Stckpionter?

Für den ATTiny26:

ldi r16,Low(RAMEND)
out SPL,r16

MfG spess

[Achim (Gast)]

Hallo Hannes, könnten Sie mir das bitte als asm vorschreiben, da ich 
nicht weiß, was SPL, SPH und Ramend ist. Ich übe erst seit zwei Wochen 
mit dem ATtiny13, doch da geht es super. Mir haben nur die ein und 
Ausgänge nicht gereicht.

l.g. Achim

[Achim (Gast)]

Danke Spess53, werde ich mal so probieren. Das ganze soll mal eine 
Schrittmotorsteuerung werden, wenns fertig ist. Mit 3 ATtiny13 geht es 
schon.

l.g. Achim

[Spess53 (Gast)]

Hi

Korrektur:

out SPL,r16 ->out SP,r16

S.57 in

http://www.atmel.com/Images/doc1477.pdf

MfG Spess

[Hannes L. (hannes)]

Achim schrieb:
> könnten Sie mir das bitte als asm vorschreiben,

Hat Spess bereits gemacht.

> da ich nicht weiß, was SPL, SPH und Ramend ist.

Dann könnte man diese Begriffe als Suchbegriffe im Datenblatt-PDF 
benutzen.

...

[Achim (Gast)]

Werde es auf jeden fall nachlesen, will ja wissen was die Befehle 
machen.
Ich danke euch beiden für eure Hilfe.

PS: Bin Modellbauer, Eisenbahn, Spur Z, 46Jahre.

[Achim (Gast)]

So läuft das Programm optimal.

.include "tn26def.inc"

rjmp     Anfang

Anfang:
   ldi     r16,low(Ramend)     ;Einfügen für rcall
   out     sp,r16              ;Einfügen für rcall
   ldi     r16,0x18
   out     ddrb,r16

Schleife:
   ldi     r16,0x10
   out     portb,r16
   rcall   Warte
   ldi     r16,0x0
   out     portb,r16
   rcall   Warte
   ldi     r16,0x8
   out     portb,r16
   rcall   Warte
   ldi     r16,0x0
   out     portb,r16
   rcall   Warte
rjmp     Schleife

Warte:
      ldi     r17,255
   Warte1:
      ldi     r18,255
      Warte2:
       dec     r18
         brne    Warte2
       dec     r17
       brne    Warte1
ret

Danke für die hilfe.

[Hannes L. (hannes)]

Achim schrieb:
> Bin Modellbauer, Eisenbahn, Spur Z,

Ich mag's ein bissel größer, beschränke mich aber mehr auf die 
Elektronik und Elektrik, mit dem Bauen von Modellen habe ich es nicht 
so...
http://www.hanneslux.de/ Da findest Du vielleicht ein paar nützliche 
Tipps betreffs Einstieg in AVR-Assembler.

> 46Jahre.

Das war ein schönes Alter, ist aber schon verdammt lange her... ;-)

...

[Rolf H. (flash01)]

he...was soll ich denn erst sagen mit meine 78 Jahre!
Spur H0 Fleischmann mit Roco kombiniert.
Anlage voll elektronisch ausgerüstet mit uralten ATARI in GFA-Basic.
Zwei Tiny2313 steuern einen Märklin-Kran und Container-Kran von Brawa.

Interessant, was Achim da vorzeigt.

Grüße

Rolf

[Rolf H. (flash01)]

Hallo Achim,
ich habe mir nochmal Deinen Quelltext angeschaut, und da ist mir
was merkwürdiges aufgefallen.

im Anfang

ldi    r16,0x18   ;0b0001 1000
out    ddrb,r16   ;also PORTB,PB4 + PB3 = Output


in der Schleife kommt nach dem zweiten rcall

ldi    r16,0x8    ;das wäre 0b1000 0000
out    portb,r16

aber Du hast doch im Anfang im Datenrichtungs-Register PB7
garnicht als Output gesetzt, oder?

Evtl. kann auch ich einen Denkfehler haben!

Grüße

Rolf

[Karl H. (kbuchegg)]

Rolf H. schrieb:

> ldi    r16,0x8    ;das wäre 0b1000 0000

No.
Genau lesen. Da ist eine führende 0 nicht geschrieben worden.

  0x8   ist dasselbe wie
  0x08


Und gerade bei Hex-Zahlen (oder auch Binärzahlen) die eine starke 
Affinität zur Bitdarstellung haben, ist es unklug, führende 0-en 
wegzulassen. Führt auf lange Sicht praktisch immer zu derartigen 
Missverständnissen. An dieser Stelle ist es besser die führenden 0-en zu 
schreiben und so wieder in das 8-Bit Schema zu kommen, welches zentral 
für die Arbeit auf Bitebene ist.
Nicht alles, was technisch erlaubt ist, ist programmiertaktisch 
sinnvoll.

[Helmut L. (helmi1)]

Rolf H. schrieb:
> ldi    r16,0x8    ;das wäre 0b1000 0000
> out    portb,r16

Ne Rolf,

ldi    r16,0x8    ;ist 0b0000 1000

und damit Ok.

[Karl H. (kbuchegg)]

Noch besser wäre es allerdings, das ganze so zu schreiben

  ldi    r16, (1<<PB4) | (1<<PB3)
  out    ddrb,r16


bzw.

  ldi    r16, (1<<PB4)
  out    portb,r16


Denn jetzt stehen die Bitnamen direkt dort und kein Mensch muss mehr 
überlegen, welche Bits sich eigentlich hinter 0x18 bzw. 0x8 verstecken.

[Helmut L. (helmi1)]

Karl Heinz Buchegger schrieb:
> Noch besser wäre es allerdings, das ganze so zu schreiben
>
>   ldi    r16, (1<<PB4) | (1<<PB3)
>   out    ddrb,r16
>
>
> bzw.
>
>   ldi    r16, (1<<PB4)
>   out    portb,r16

Und noch besser ist es direkt sprechende Namen zu verwenden.

    ldi    r16, SIGNAL1

[Karl H. (kbuchegg)]

Helmut Lenzen schrieb:

> Und noch besser ist es direkt sprechende Namen zu verwenden.
>
>     ldi    r16, SIGNAL1

Absolut.

Und die Moral von der Geschichte:
Man kann alleine durch unterschiedliche Schreibweisen steuern, wie gut 
oder schlecht ein Code zu lesen bzw. zu verstehen ist. Und das sogar mit 
relativ wenig Aufwand, der einen riesen Unterschied ausmachen kann.

[Rolf H. (flash01)]

Karl Heinz Buchegger schrieb:
> ldi    r16, (1<<PB4)
>
>   out    portb,r16


Hast Recht Karl Heinz Buchegger, das werde ich mir mal angewöhnen.

Wieder was gelernt!

Grüße

Rolf

[Rolf H. (flash01)]

Karl Heinz Buchegger schrieb:
>> Und noch besser ist es direkt sprechende Namen zu verwenden.
>
>>
>
>>     ldi    r16, SIGNAL1


dann muß ich aber doch am Anfang PB4 als SIGNAL1 definieren.
Macht man das mit .equ   PB4=SIGNAL

[Karl H. (kbuchegg)]

Rolf H. schrieb:
> Karl Heinz Buchegger schrieb:
>>> Und noch besser ist es direkt sprechende Namen zu verwenden.
>>
>>>
>>
>>>     ldi    r16, SIGNAL1
>
>
> dann muß ich aber doch am Anfang PB4 als SIGNAL1 definieren.

Ja und?
Spätestens wenn die LED wegen Hardware Problemen vom Pin PB4 auf PB2 
'umziehen' muss, bist du froh drüber, wenn du nur an einer Stelle die 
neue Belegung einträgst und nicht quer durch das ganze Programm hirschen 
und alle relevanten Hex-Zahlen finden und anpassen musst.

> Macht man das mit .equ   PB4=SIGNAL

fast
a) anders rum. In den meisten Programmiersprachen steht immer links
   vom = das Ergebnis und rechts davon, wie  man zu diesem Ergebnis
   kommt.
b) so wie das verwendet wird, muss da stehen

.equ     SIGNAL1 = (1<<PB4)

Nur dann ist

   ldi   r16, (1<<PB4)

und

   ldi   r16, SIGNAL1

auch gleichwertig.

[Rolf H. (flash01)]

Karl Heinz Buchegger schrieb:
> ldi    r16, (1<<PB4)
>
>   out    portb,r16

richtig wäre es aber wenn:

ldi   r16,0x8      ;0x08 = 0b0000 1000
out   portb,r16


ldi    r16, (1<<PB3)  ;oder hab ich wieder nen Denkfehler?

Grüße

Rolf

[Karl H. (kbuchegg)]

Rolf H. schrieb:
> Karl Heinz Buchegger schrieb:
>> ldi    r16, (1<<PB4)
>>
>>   out    portb,r16
>
> richtig wäre es aber wenn:
>
> ldi   r16,0x8      ;0x08 = 0b0000 1000
> out   portb,r16
>
>
> ldi    r16, (1<<PB3)  ;oder hab ich wieder nen Denkfehler?

Ne. stimmt schon.
Ich hab jetzt nicht auf die Pin-Nummern geachtet.

Vergleich mal mit

.include "tn26def.inc"

.equ     LED_PORT = PORTB
.equ     LED_DDR  = DDRB

.equ     LEFT_LED  = (1<<PB4)
.equ     RIGHT_LED = (1<<PB3)

   rjmp     Anfang

Anfang:
   ldi     r16,low(Ramend)     
   out     sp,r16              

   ldi     r16, LEFT_LED | RIGHT_LED
   out     LED_DDR, r16

Main:
   ldi     r16, LEFT_LED
   out     LED_PORT, r16
   rcall   Warte
   ldi     r16, 0x0
   out     LED_PORT, r16
   rcall   Warte
   ldi     r16, RIGHT_LED
   out     LED_PORT, r16
   rcall   Warte
   ldi     r16, 0x0
   out     LED_PORT, r16
   rcall   Warte
   rjmp    Main

Warte:
   ldi     r17,255
Warte1:
   ldi     r18,255
Warte2:
   dec     r18
   brne    Warte2
   dec     r17
   brne    Warte1
   ret

Spielt es jetzt wirklich noch eine große Rolle, wo die LDE angeschlossen 
ist?
Nicht wirklich. Wenn die eine LED (sagen wir mal die rechte) nicht an 
PB3 angeschlossen ist, sondern an PB2, dann änder ich einfach

  ...
.equ     RIGHT_LED = (1<<PB2)
  ...

und fertig. Den Rest der Programmanpassung macht der Assembler.

Und das ist noch lange nicht alles, was man in diesem Programm 
verbessern kann. Zb. sollten einem die 'Komplett'-Zugriffe auf den Port 
ein Dorn im Auge sein. Mittels

   ldi     r16, LEFT_LED
   out     LED_PORT, r16

verändert man ja nicht nur den einen Pin, sondern alle anderen Pins 
gleich mit! Solange man nur 1 oder 2 LED an einem Port hat, mag das ja 
noch angehen. Aber wenn du 3 LED, 2 Summer, und 3 Taster am Port hängen, 
dann wirds aufwändig, das immer alles im Kopf zu behalten, welcher Pin 
jetzt gerade wie stehen muss und welchen Wert man daher an das 
Port-Register zuweisen muss, damit wieder alles stimmt.
Genau aus dem Grund gibt es die SBI und CBI Instruktionen, mit denen man 
tatsächlich nur 1 Bit und nicht mehr manipuliert.

.include "tn26def.inc"

.equ     LED_PORT = PORTB
.equ     LED_DDR  = DDRB

.equ     LEFT_LED  = PB4
.equ     RIGHT_LED = PB3

   rjmp     Anfang

Anfang:
   ldi     r16,low(Ramend)     
   out     sp,r16              

   ldi     r16, (1<<LEFT_LED) | (1<<RIGHT_LED)
   out     LED_DDR, r16

Main:
   sbi     LED_PORT, LEFT_LED
   rcall   Warte
   cbi     LED_PORT, LEFT_LED
   rcall   Warte

   sbi     LED_PORT, RIGHT_LED
   rcall   Warte
   cbi     LED_PORT, RIGHT_LED
   rcall   Warte

   rjmp    Main

Warte:
   ldi     r17,255
Warte1:
   ldi     r18,255
Warte2:
   dec     r18
   brne    Warte2
   dec     r17
   brne    Warte1
   ret

Aber: All das steht ja auch mehr oder weniger im
AVR-Tutorial
Wenn auch nicht in den Feinheiten von Anfang an.