Unterschied zwischen brne breq

[linuxdxs (Gast)]

Hallo Forum, ich habe ein kleines Problem:
Ich programmiere zur Zeit eine AVR ATMEGE 8535 und weis nicht wehr 
weiter. Ich möchte eine 16-Bit-Zähler realisieren. Wenn ich folgendes UP 
benutze funktioniert alles
rc5_zeit_messung:
  lds tmp2,rc5_dauer_low
  inc tmp2
  sts rc5_dauer_low,tmp2
  breq zeitg_0_ueberlauf1

zeitg_0_ueberlauf2:
  ret

zeitg_0_ueberlauf1:
  lds tmp2,rc5_dauer_high
  inc tmp2
  sts rc5_dauer_high,tmp2
  rjmp zeitg_0_ueberlauf2

Benutze ich dagegen diese UP, funktioniert fast gar nichts mehr
rc5_zeit_messung:
  lds tmp2,rc5_dauer_low
  inc tmp2
  sts rc5_dauer_low,tmp2
  brne zeitg_0_ueberlauf2
  lds tmp2,rc5_dauer_high
  inc tmp2
  sts rc5_dauer_high,tmp2
zeitg_0_ueberlauf2:
  ret

Der einzige Unterschied ist, einmal nehme ich breq und das andere mal 
brne. Kann mir jemand helfen und mir sagen warum es einmal funktioniert 
und das andere mal nicht?

[MarioT (Gast)]

http://www.avr-roboter.de/controller/befehle/beschreibung/beschreibung.html

[Marc B. (belgo)]

Hallo,

die Befehle "breq" -> Springe bei gleich
            "brne" -> Springe bei ungleich

werden nach einem test auf 0 "tst" oder nach einem Vergleich "cp..." 
geschrieben.

In deinem Prog sehe ich solche codezeilen nicht !!!

gruss Marc

[Yalu X. (yalu) (Moderator)]

Die beiden Varianten habe die gleiche Funktion, aber unterschiedliches
Zeitverhalten. Vielleicht liegt da der Hund begraben.

[Michael U. (amiga)]

Hallo,

Marc B. schrieb:
> Hallo,
>
> die Befehle "breq" -> Springe bei gleich
>             "brne" -> Springe bei ungleich
>
> werden nach einem test auf 0 "tst" oder nach einem Vergleich "cp..."
> geschrieben.

Auch, ja...
>
> In deinem Prog sehe ich solche codezeilen nicht !!!

dafür gibt es inc und das beeinflußt Z ebenfalls und ein paar andere 
befehle auch...

Ach ja: wenn Du da platz hast vielleicht auch über

lds XH,rc5_dauer_high
lds XL,rc5_dauer_low
adiw X,1
sts rc5_dauer_high,XH
sts rc5_dauer_high,XL

hätte da dann immer die gleiche Laufzeit.

Geht auch mit anderen Registerpaaren, siehe ASM-Befehle.

Gruß aus Berlin
Michael

[Stefan B. (stefan)]

Bis auf die beiden Taktzyklen des RJMP sollte der Code gleich sein.
Geht das?

rc5_zeit_messung:
  lds   tmp2,rc5_dauer_low
  inc   tmp2
  sts   rc5_dauer_low,tmp2
  brne  zeitg_0_ueberlauf2
  lds   tmp2,rc5_dauer_high
  inc   tmp2
  sts   rc5_dauer_high,tmp2
  NOP
  NOP
zeitg_0_ueberlauf2:
  ret

[Hc Z. (mizch)]

Marc B. schrieb:
> die Befehle "breq" -> Springe bei gleich
>             "brne" -> Springe bei ungleich
>
> werden nach einem test auf 0 "tst" oder nach einem Vergleich "cp..."
> geschrieben.
>
> In deinem Prog sehe ich solche codezeilen nicht !!!

Das ist auch gar nicht nötig:  brne und breq beziehen sich einfach auf 
den letzten Operator, der das Z-Flag verändert, in diesem Fall den inc. 
Ein tst oder cp muss nicht vorangegangen sein.

[Stefan B. (stefan)]

Die unterschiedliche Ausführungszeit für BRQE/BRNE für den zutreffenden 
Fall/nicht zutreffenden Fall könnte man auch noch berücksichtigen. Kann 
mein Beispiel oben leider nicht mehr editieren.

[linuxdxs (Gast)]

Ihr seit ja super schnell, hier noch eine Kleinigkeit. Ich löse alle 100 
uS einen Timer1-Int aus, zähle dann mit vier Zählern, jeweils bis 10, so 
habe kann ich dann ms-, 10ms-, 100ms- und s-weise zählen. Das ist das 
Einzige was in der Routine erledigt wird. Im HP springe ich dann immer 
zu folgende Auswertroutine:

;-------------------------------------------------------

interruptabfrage:
  lds tmp1,interruptflag1

;---------------------------------------------
  bst tmp1,0        
  brtc interruptabfrage20  

;10000/sek------------------------------------
  
;---------------------------------------------
  clt
  bld tmp1,0

interruptabfrage20:
  bst tmp1,1        
  brtc interruptabfrage30
  clt
  bld tmp1,1

;1000/sek-------------------------------------
  rcall displaydatenst
  rcall displayhwsteuerung
         rcall rc5_zeit_messung

;---------------------------------------------
interruptabfrage30:
  bst tmp1,2        
  brtc interruptabfrage40  
  clt
  bld tmp1,2
;100/sek--------------------------------------
  ;rcall zaehleranzeigen
;---------------------------------------------

interruptabfrage40:
  bst tmp1,3        
  brtc interruptabfrage50  
  clt
  bld tmp1,3
;10/sek---------------------------------------
  
;---------------------------------------------


interruptabfrage50:  
  bst tmp1,4        
  brtc interruptabfrage60
  clt
  bld tmp1,4
;1 sek----------------------------------------
  rcall test150
  rcall uhrzeit
  rcall uhranzeigen
;---------------------------------------------

interruptabfrage60:
  sts interruptflag1,tmp1
  ret
;-------------------------------------------------------

Wenn ich jetzt den 16-Bit-Zähler mit brne realisiere funktioniert die 
ganze Geschichte nicht. Mit breq dagegen super.

[spess53 (Gast)]

Hi

>Wenn ich jetzt den 16-Bit-Zähler mit brne realisiere funktioniert die
>ganze Geschichte nicht. Mit breq dagegen super.

Und wie sieht die Interruptroutine aus?

MfG Spess

[linuxdxs (Gast)]

Und hier die Int-Routine

;---------------------------------------------
;Hier wird bei jedem Zeitgeberueberlauf eine
;250 in das Register zurueckgeladen, damit 
;wird eine Frequenz von 10000 Hertz erzeugt.

;---------------------------------------------
;Einsprungprozedur
;Retten der tmporaeren Register tmp1, tmp2
;und SREG
zeitgeber_up:
  push tmp1

;---------------------------------------------
;Zaehler mit 230 laden
  ldi tmp1,230
  out TCNT0,tmp1
  push tmp2
  in tmp1,SREG
  push tmp1
  lds tmp2,interruptflag1
  set
;---------------------------------------------
;10000 mal in der Sekunde 
  bld tmp2,0
  lds tmp1,zeitz4
  inc tmp1
  sts zeitz4,tmp1
  cpi tmp1,10
  brlo zeitgeber_0_ueberlauf_ende
  clr tmp1
  sts zeitz4,tmp1

;---------------------------------------------
;1000 mal in der Sekunde 
  bld tmp2,1
  lds tmp1,zeitz3
  inc tmp1
  sts zeitz3,tmp1
  cpi tmp1,10
  brlo zeitgeber_0_ueberlauf_ende
  clr tmp1
  sts zeitz3,tmp1

;---------------------------------------------
;100 mal in der Sekunde 
  bld tmp2,2
  lds tmp1,zeitz2
  inc tmp1
  sts zeitz2,tmp1
  cpi tmp1,10
  brlo zeitgeber_0_ueberlauf_ende
  clr tmp1
  sts zeitz2,tmp1
;---------------------------------------------
;10 mal in der Sekunde 
  bld tmp2,3
  lds tmp1,zeitz1
  inc tmp1
  sts zeitz1,tmp1
  cpi tmp1,10
  brlo zeitgeber_0_ueberlauf_ende
  clr tmp1
  sts zeitz1,tmp1
  rcall test160
;---------------------------------------------
;1 mal in der Sekunde 
  bld tmp2,4

zeitgeber_0_ueberlauf_ende:
;---------------------------------------------
;Zurueckspeichern der tmporaeren Register SREG,tmp1 und tmp2
  sts interruptflag1,tmp2
  pop tmp1
  out SREG,tmp1
  pop tmp2
  pop tmp1
  reti

[Uwe (Gast)]

Hi!
>Wenn ich jetzt den 16-Bit-Zähler mit brne realisiere funktioniert die
>ganze Geschichte nicht. Mit breq dagegen super.
Ist ja auch normal.
inc lowbyte setzt bei 0(Überlauf) das Z-Flag->breq wird ausgelöst
also wird lowbyte bis 255 gezählt und dann highbyte +1
Wenn du brne benutzt wird bei jedem inc das Highbyte mit erhöht.

Viel Erfolg, Uwe

[linuxdxs (Gast)]

Bei brne und breq mache ich ja verschiedene Programmschritt (siehe 
oben). Kann es sein, daß meine AVR-Version veraltet ist?

[Stefan B. (stefan)]

linuxdxs schrieb:
> Bei brne und breq mache ich ja verschiedene Programmschritt (siehe
> oben). Kann es sein, daß meine AVR-Version veraltet ist?

Unwahrscheinlich, dass sich das so auswirkt. Bist du dem 
unterschiedlichen Zeitverhalten schon nachgegangen?

[linuxdxs (Gast)]

In diesem Falle sollte das Zeitverhalten, so denke ich, doch gar nichts 
ausmachen. Der AVR rennt mit 16 MHz. Im Datenblatt steht für beide 
Befehle 1/2 Clocks. Wie soll ich das unterschieliche Zeitverhalten 
verstehen. Gehe ich richtig in der Annahme, daß bei einer Frequenz von 
16 MHz, der AVR 16000000 1-Clock Befehle in der Sekunde durchführt?

[spess53 (Gast)]

Hi

>Gehe ich richtig in der Annahme, daß bei einer Frequenz von
>16 MHz, der AVR 16000000 1-Clock Befehle in der Sekunde durchführt?

Ja.

MfG Spess

[Karl H. (kbuchegg)]

Vielleicht hab ich Tomaten auf den Augen.
Aber in den beiden zuletzt geposteten Codestpücken kommt kein einziger 
breq, brne vor!

[linuxdxs (Gast)]

Ja, einmal habe ich dir Rotine gesendet, von der, der Zähler aufgerufen 
wird. Der Zweitecodeteil ist dafür verantwortlich, wird durch Int 
angesprungen, daß das Bit gesetzt wird, welches dafür sorgt, dem zuvor 
erwähnten Programm mitzuteilen, das es soweit ist den Zähler 
anzuspringen.

[Peter D. (peda)]

Karl heinz Buchegger schrieb:
> Vielleicht hab ich Tomaten auf den Augen.
> Aber in den beiden zuletzt geposteten Codestpücken kommt kein einziger
> breq, brne vor!

Naja, wie soll man denn sonst auf ne hohe Anzahl von Antworten kommen?

Wenn er sich mal aufgerafft hätte, nen kompletten, realen, getesteten, 
compilierbaren Code als Dateianhang zu posten, wäre die Sache bestimmt 
schon längst gegessen.


Peter

[linuxdxs (Gast)]

Hallo hier bin ich wieder. Also das ganze bis jetzt geschriebene 
Programm. Tut mir leid, habe gedacht, daß es vielleicht ein ganz 
einfaher Fehler wäre, nach dem Motto, hei da war doch was. Ich sende 
morgen in einem Anhang das Programm, wenn es denn noch jemanden 
interessiert.

[linuxdxs (Gast)]

Hallo ich habe es geschafft. Im Anhang eine lauffähige Version meines 
Programmes. Im unteren Teil sieht man folgende auskommendierten Zeilen

  ;brne zeitgeber_0_ueberlauf1
  ;lds tmp2,rc5_dauer_high
  ;inc tmp2
  ;sts rc5_dauer_high,tmp2

wieder einkommendiert. Funktioniert die ganze Sache nicht mehr ganz 
richtig. Ich muß noch dazu sagen, daß die UP test150 und test160 im 
Sekundentakt( oder zumindest gleichmäßig) angesprungen werden müssen, 
und wenn man die Änderung gemacht hat funktioniert das eben zumindest 
mit test150 nicht mehr.

[Peter D. (peda)]

Also ich seh da überhaupt nicht durch, das ist ja ne wilde Hin- und 
Herspringerei.

Mach mal nen großen Strich, darüber alles im Main-Kontext und darunter 
alles im Interrupt.

Was willst Du außerdem mit der ewigen SREG-Pusherei?
Nimm Dir ein Register, z.B. R2, und darin wird SREG einmal zu 
Interruptanfang gesichert und vor dem RETI wieder geladen, aus, fertig.


Peter