Forum: Mikrocontroller und Digitale Elektronik Buch AVR von Günter Schmitt durcharbeiten


von Bernd_Stein (Gast)


Lesenswert?

Hallo zusammen,

ich besitze schon die Bücher "AVR-Mikrocontroller-Praxis" 1999
                             "AVR-RISC Mikrocontroller  " 2003

und nun "Mikrocomputertechnik mit Controllern der Atmel 
AVR-RISC-Familie"
in der 4.ten Auflage 2008. Das Lernpaket Mikrocontroller habe ich durch.

Bei meinen eigenen Programmierungen halfen mir die ersten beiden Bücher 
nur
zum Teil, da sie schon ziemlich alt sind. Ich nutzte sie als 
Nachschlage-
werke.
Nun bin ich zu der Einsicht gekommen, das nur nachschlagen mich nicht 
weiterbringt. Zwar habe ich schon Erfahrungen mit dem MC68HC11 
gesammelt,
aber z.B. die Befehle sbi, sbr, sbis, sbrs bzw. cbi, cbr, sbic, sbrc
machten mich Wahnsinnig. Auch weil der AVR-Studio Simulator in der
Version 4.10 fehlerhaft war.

Beitrag "Portpin wird automatisch gelöscht im AVR-Studio 4.10"

Nun möchte ich das zu letzt genannte Buch mit Eurer Hilfe durch 
arbeiten.
Und zwar dachte ich mir das Folgendermaßen :

Alle Fragen beziehen sich nur auf dieses Buch und auch nur auf die
4te Auflage.
Es wird die Seitenzahl angegeben auf die sich die Frage
bezieht. Evtl. kann man noch ein Stück vom Orginaltext einfügen.
Den kann man vielleicht aus der folgenden WWW-Seite kopieren kann.

http://books.google.de/books?id=AI_HVUE0xYEC&pg=PA404&lpg=PA404&dq=at90s2313+sbi&source=bl&ots=Q_OQlfAY2Z&sig=MNcHMHf-7HfdceEva8SQDzgTzEw&hl=de&ei=vT7mSeK2GtfisAbc59GjCw&sa=X&oi=book_result&ct=result&resnum=6#v=onepage&q&f=false

Nun gut, hier die erste Frage :

Seite 21
Das Carrybit wird zwar verändert,....

Ich habe jetzt schon einige Versuche im AVR-Studio Simulator 
durchgeführt aber habe noch nicht bemerkt das das Carrybit verändert 
wurde ohne das dies Richtig wäre.
Hat jemand von Euch vielleicht ein einleuchtendes Beispiel hierzu ?

Bis dann
Bernd_Stein

von Karl H. (kbuchegg)


Lesenswert?

Bernd_Stein schrieb:

> Ich habe jetzt schon einige Versuche im AVR-Studio Simulator
> durchgeführt aber habe noch nicht bemerkt das das Carrybit verändert
> wurde ohne das dies Richtig wäre.
> Hat jemand von Euch vielleicht ein einleuchtendes Beispiel hierzu ?

Zeig doch erst mal dein Beispiel.

Und bitte bezieh dich nicht ausschliesslich nur auf irgendein Buch. 
Beschreibe kurz das Umfeld, in dem deine Frage existiert. Gib noch 
zusätzlichen Kontext an, alles was dir notwendig erscheint.

PS: Es ist nicht ungewöhnlich, dass einem dieses Zusammenstellen von 
Informationen für Dritte die Erleuchtung bringt!
Es gab mal eine Zeit, in der Studenten an der MIT ihre 
Programmierprobleme einem Teddybären erzählen mussten (Sekretärin hat 
darüber gewacht) ehe sie zum Praktikumsbetreuer vorgelassen wurden. Die 
Legende sagt, dass danach ungefähr 80% wieder abgezogen sind und gar 
keine perönliche Betreuung mehr gebraucht haben.

von MarioT (Gast)


Lesenswert?

Lese das mal durch.
http://www.avr-roboter.de/controller/befehle/beschreibung/beschreibung.html

C: Das C-Flag wird gesetzt, wenn im Ergebnis ein Überlauf von Bit 8 
erfolgte, andernfalls wird es gelöscht.
Schicke mal den Code den Du hast zum Testen und nicht verstehst.

von Bernd_Stein (Gast)


Lesenswert?

Nun ja,

ich wollte halt das die Leute genau wissen worum es geht ohne das ich 
viele Worte bzw. Buchstaben verlieren muß.
Dummerweise habe ich gleich bei der ersten Frage einen Fehler gemacht 
und bekomme natürlich prompt auch eine verkehrte Antwort.

 ldi  r16, 0b01111111  ;127 bzw. $7F
 subi r16,-0b00000001  ;  1 bzw. $01 hier wird durch (-1) 1 addiert !

Also richtig ist :

Warum wird das Carry-Flag gesetzt ?

Es wird doch nicht der 8-Bit Wertebereich überschritten.

Der Paralleladdierer auf Seite 14 oder die Zeichnungen
auf Seite 16 bzw. 18 helfen mir da leider nicht weiter.

Ich möchte keine Werbung für irgend ein Buch oder Autor machen.
Noch möchte ich irgendwelche Leute aus dieser Diskusion hier
ausschließen.
Deshalb auch der Link für die Leute die das Buch nicht besitzen.
Ich habe auch nicht alle möglichen Boards, Programmer, Programme, 
Mikrocontroller und kann deshalb einigen Treads auch nicht folgen.

Ich möchte nur möglichst genau beschreiben was ich meine ohne viele 
Worte zu verlieren. Und ein Bild sagt nun mal mehr als tausend Worte.
Abgesehen davon, wie lange ich wohl brauchen würde um den 
Paralleladdierer
hier als Zeichnung hinzubekommen.

MfG
Bernd_Stein

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

Bernd_Stein schrieb:
> ich wollte halt das die Leute genau wissen worum es geht ohne das ich
> viele Worte bzw. Buchstaben verlieren muß.

Dummerweise lässt einen Google bei seiner Buchansicht nicht alle Seiten 
lesen. Seite 21 fehlt bei mir zum Beispiel. Nur 19 und 23 werden 
gezeigt.
Wird also nichts mit Deinem Vorhaben.

von Karl H. (kbuchegg)


Lesenswert?

Bernd_Stein schrieb:

>  ldi  r16, 0b01111111  ;127 bzw. $7F
>  subi r16,-0b00000001  ;  1 bzw. $01 hier wird durch (-1) 1 addiert !

Weil du hier offensichtlich auf vorzeichenbehaftete Arithmetik aus bist.
Das Bitmuster für -1 ist aber   0b11111111

> Also richtig ist :
>
> Warum wird das Carry-Flag gesetzt ?


C: Rd7 • K7 +K7 • R7 +R7 • Rd7

Set if the absolute value of K is larger than the absolute value of Rd; 
cleared otherwise.

Grundsätzlich:
Damit eine Kaskadierung von Subtraktionen auf zb 16 Bit möglich ist. In 
diesem Fall ist das Carry bei einer Subtraktion keine Indiz für einen 
Überlauf, sondern ein Indiz, dass man sich von der nächsthöheren Stelle 
eine 1 geborgt hat.

So wie in:   91 - 8

    1 - 8 macht 3 und dazu hab ich mir von der Stelle daneben eine 1 
geborgt. Also muss man von der 9 auch noch 1 abziehen. Diese geborgte 1 
ist das Carry-Flag, welches bei 1 - 8 entstanden ist.

von Bernd_Stein (Gast)


Lesenswert?

Christian H. schrieb:
> Dummerweise lässt einen Google bei seiner Buchansicht nicht alle Seiten
> lesen. Seite 21 fehlt bei mir zum Beispiel. Nur 19 und 23 werden
> gezeigt.
> Wird also nichts mit Deinem Vorhaben.
>
Leider hast Du ein wenig recht. Jeder der das Buch nicht hat oder nicht 
in der 4ten Auflage dürfte Probleme haben hier zu folgen.

So ist es aber auch, wenn man ein bestimmtes Board, Software,
Mikrocontroller oder sonst etwas nicht hat.
Schade das dies Vorhaben erstens vom Moderator nicht ganz akzeptiert 
wird und zweitens nicht für jeden zugänglich (Wegen des fehlenden 
Buches).

Bis dann
Bernd_Stein

von Karl H. (kbuchegg)


Lesenswert?

Bernd_Stein schrieb:

> Schade das dies Vorhaben erstens vom Moderator nicht ganz akzeptiert
> wird

Es ist ganz einfach:
Wenn du Fragen hast, dann stelle die Frage hier.
Wenn du dabei auf etwas externes verlinken musst, gut, dann tu das. Aber 
eine Frage, die im wesentlichen nur aus einem Link besteht, werden wir 
hier ganz sicher nicht akzeptieren.
Du bist es, der die Frage hat. Also gib dir auch ein wenig Mühe die 
Frage in deinen Worten zu formulieren.

Wir geben uns ja auch Mühe die Antwort möglichst als ganze deutsche 
Sätze zu formulieren und schmeissen dir nicht einfach ein paar Brocken 
hin.

In deinem konkreten Fall, falls du es noch nicht gemerkt hast, liegt die 
Antwort auf deine Frage darin, dass du nicht addierst, sondern 
subtrahierst. Und da gelten dann ein klein wenig andere Regeln für das 
Carry Bit.

von Oliver (Gast)


Lesenswert?

Bernd_Stein schrieb:
> Nun bin ich zu der Einsicht gekommen, das nur nachschlagen mich nicht
> weiterbringt. Zwar habe ich schon Erfahrungen mit dem MC68HC11
> gesammelt,
>
> aber z.B. die Befehle sbi, sbr, sbis, sbrs bzw. cbi, cbr, sbic, sbrc
> machten mich Wahnsinnig. Auch weil der AVR-Studio Simulator in der
> Version 4.10 fehlerhaft war.

"War" ist aber nicht mehr aktuell. Und mal ehrlich, du hast 3 (!!!) 
Bücher zum Thema, dazu einen funktionierenden Simulator, und dazu das 
ganze Internet zum durchlesen. Das sollte doch hinzubekommen sein.

Oliver

von Karl H. (kbuchegg)


Lesenswert?

Oliver schrieb:
> Bernd_Stein schrieb:
>> Nun bin ich zu der Einsicht gekommen, das nur nachschlagen mich nicht
>> weiterbringt. Zwar habe ich schon Erfahrungen mit dem MC68HC11
>> gesammelt,
>>
>> aber z.B. die Befehle sbi, sbr, sbis, sbrs bzw. cbi, cbr, sbic, sbrc
>> machten mich Wahnsinnig. Auch weil der AVR-Studio Simulator in der
>> Version 4.10 fehlerhaft war.
>
> "War" ist aber nicht mehr aktuell. Und mal ehrlich, du hast 3 (!!!)
> Bücher zum Thema, dazu einen funktionierenden Simulator, und dazu das
> ganze Internet zum durchlesen. Das sollte doch hinzubekommen sein.

Und .. er hat auch noch die Befehlsreferenz über F1

von Peter D. (peda)


Lesenswert?

Keiner hat Lust, sich erstmal umständlich 100 Dokumente zusammenklauben 
zu müssen.

Wenn Du Fragen hast, lies die Postingregeln und richte Dich einfach 
danach:

Nutze die Formatierung, um Quelltext einzufügen.
Nutze Copy&Paste dazu, d.h. Quelltext immer exakt, niemals aus dem Kopf 
nachempfinden.
Dito für Fehlermeldungen.

Und dann schreib einfach Deine Frage dazu (leidlich gute Rechtschreibung 
ist von Vorteil).


Peter

von Bernd_Stein (Gast)


Lesenswert?

Karl heinz Buchegger schrieb:
> In deinem konkreten Fall, falls du es noch nicht gemerkt hast, liegt die
> Antwort auf deine Frage darin, dass du nicht addierst, sondern
> subtrahierst. Und da gelten dann ein klein wenig andere Regeln für das
> Carry Bit.
>
>  ldi  r16, 0b01111111  ;127 bzw. $7F
>  subi r16,-0b00000001  ;  1 bzw. $01 hier wird durch (-1) 1 addiert !
>
> Weil du hier offensichtlich auf vorzeichenbehaftete Arithmetik aus bist.

Das ist richtig, es geht um vorzeichenbehaftete Zahlen in diesem 
Abschnitt des Buches.

Aber ich wollte zu 127 bzw. $7F eins hinzu addieren.
Und das geht wie ich bisher verstanden habe, weil es kein (adi)
gibt mit subi -(Wert).
Mir ist klar das das N-Flag gesetzt wird => $80 Bit7 gesetzt.
Auch das V-Flag, weil ich jetzt vom positiven Bereich durch addieren
einer positiven Zahl (+1) in den negativen Bereich gelangt bin.

               Warum wird das Carry-Flag gesetzt ?

http://www.mikrocontroller.net/articles/AVR-Tutorial:_Vergleiche#Carry_.28C.29

> C: Rd7  K7 +K7 • R7 +R7 • Rd7
>
> Set if the absolute value of K is larger than the absolute value of Rd;
> cleared otherwise.

Carry = 1 wenn (/Rd7 und K7) oder (K7 und R7) oder (R7 und /Rd7)

so habe ich das mal übersetzt und korrigiert, da beim kopieren aus dem
AVR-Instuction-Set die negationen nicht mit übernommen wurden für den 
Befehl SUBI.

Rd = Destination (Ziel) also r16

K7 = Kontstante Bit 7

R7 = Result Bit 7 also wieder r16 ???

Um dies zu verstehen fehlt mir noch die Erkenntnis wo sich R7 zuordnen 
läßt (Result).

Ist dies ein internes Hilfsregister auf das nicht zugegriffen werden 
kann,
welches nur das Statusregister (SREG) beeinflußt,
wie ich dies aus Seite 20 interpretiere ?

Bis dann
Bernd_Stein

von Karl H. (kbuchegg)


Lesenswert?

Bernd_Stein schrieb:

> Aber ich wollte zu 127 bzw. $7F eins hinzu addieren.
> Und das geht wie ich bisher verstanden habe, weil es kein (adi)
> gibt mit subi -(Wert).

Richtig.
Trotzdem kannst du aber die Bedeutung des Carry Flags nicht einfach 1:1 
von der Addition zur Subtraktion übernehmen.

Bei einer Addition zeigt das Carry an, dass ein Überlauf entstand und 
daher im nächst höheren Byte (bei 16 Bit Arithmetik) daher noch 1 
addiert werden muss.

Bei einer Subtraktion zeigt das Carry an, dass von der nächst höheren 
Stelle 'geborgt' werden musste und man daher vom nächst höheren Byte 
(bei 16 Bit Arithmetik) daher noch 1 sbtrahieren muss.

Im Endeffekt kommt (bei 16 Bit Arithmetik) es alles aufs richtige raus. 
Aber aus verschiedenen logischen Gründen.

(Wenn man so will, zeigt das Carry bei einer Subtraktion einen Unterlauf 
an, in Analogie zu einem Überlauf bei einer Addition)

von Pete K. (pete77)


Lesenswert?

Ich würde den Lernaufwand in die Sprache C investieren.

von spess53 (Gast)


Lesenswert?

Hi

>Warum wird das Carry-Flag gesetzt ?

Das Carry-Flag wird unabhängig von irgendwelchen Vorzeichenbetrachtungen 
gesetzt. Aus Sicht des Carryflags lautet deine Rechnung:

    $7F - $FF = $80

Und da du eine grössere Zahl von einer kleineren abziehst bekommst du 
einen Übertrag und das Carryflag wird gesetzt.

MfG Spess

von MarioT (Gast)


Lesenswert?

Pete K. schrieb:
> Ich würde den Lernaufwand in die Sprache C investieren.

Wie will man mit "C" einen AVR "richtig" Programmieren wenn man 
Assembler nicht kann?

von Karl H. (kbuchegg)


Lesenswert?

Na ja.
Ums Carry Bit brauchst du dich nicht kümmern.
Es schadet nichts, wenn man weiß was es damit auf sich hat. Aber die 
Behandlung des Carry (und noch einiger anderer Low-Level Dinge) fällt in 
die Domäne des Compilers und ist nichts was einem Programmierer 
Kopfzerbrechen machen sollte. Solange man bei C bleibt.

Was nicht heißt, das ich dieses Wissen für nicht sinnvoll halte.

von Oliver (Gast)


Lesenswert?

Bernd_Stein schrieb:
> Um dies zu verstehen fehlt mir noch die Erkenntnis wo sich R7 zuordnen
> läßt (Result).

Auf Seite 2 des Instruction Set Maunals von Atmel steht:
1
Rd: Destination (and source) register in the Register File
2
Rr: Source register in the Register File
3
R: Result after instruction is executed

Oliver

von Bernd_Stein (Gast)


Lesenswert?

spess53 schrieb:
> Hi
>
>>Warum wird das Carry-Flag gesetzt ?
>
> Das Carry-Flag wird unabhängig von irgendwelchen Vorzeichenbetrachtungen
> gesetzt. Aus Sicht des Carryflags lautet deine Rechnung:
>
>     $7F - $FF = $80
>
> Und da du eine grössere Zahl von einer kleineren abziehst bekommst du
> einen Übertrag und das Carryflag wird gesetzt.
>
> MfG Spess

Schade das ich hier nicht das Bild des Paralleladdieres von Seite 14 zur 
Verfügung habe.
Also das Rechenwerk bzw. ALU führt ja eine Subtraktion auf eine Addition 
zurück. Die Anweisung -Wert für den Assembler erzeugt ja nur das
Zweierkomplement des Wertes, was ja die negative Entsprechung des Wertes 
ist. Z.B. :

 ldi  r16,-1  ;lädt r16 mit dem Wert $FF = -1

Mit dem Befehl

 subi r16,-1 ;

führe ich doch auch nur eine Addition mit dem Zweierkomplement durch,
oder etwa nicht ?

von Stefan E. (sternst)


Lesenswert?

Bernd_Stein schrieb:
> Mit dem Befehl
>
>  subi r16,-1 ;
>
> führe ich doch auch nur eine Addition mit dem Zweierkomplement durch,
> oder etwa nicht ?

Nein, es wird genau das gemacht, was da steht, nämlich -1 (also ff) 
subtrahiert. Und dabei entsteht ein Überlauf. Dass -1 zu subtrahieren 
auf einer logischen Ebene das gleiche ist, wie 1 zu addieren 
interessiert das Carry-Bit nicht. Das reagiert nur auf das, was 
tatsächlich passiert.

von Karl H. (kbuchegg)


Lesenswert?

Bernd_Stein schrieb:

> Mit dem Befehl
>
>  subi r16,-1 ;
>
> führe ich doch auch nur eine Addition mit dem Zweierkomplement durch,
> oder etwa nicht ?

Aber kein Mensch sagt, dass die Behandlung des Carry Bits bei Addition 
und Subtraktion gleich ist.

Im Quellcode steht subi
Also wird auch subtrahiert.
Also werden die im Datenblatt angegebenen Regeln zur Bildung des Carry 
BIts benutzt. Und zwar die bei subi angegebenen!

Was intern in der CPU abgeht, wenn sie einen subi ausführt, ist 
vielleicht 'nice to know', aber letztendlich zählt das was im Datenblatt 
bei genau diesem Befehl als Auswirkungen geschrieben steht.

von spess53 (Gast)


Lesenswert?

Hi

Du solltest das Instruction-Set richtig lesen. Zum Carry-Flag bei 'subi' 
steht:

Set if the absolute value of K is larger than the absolute value of Rd; 
cleared otherwise.

Fertig und aus.

Lass dir mal absolute *value* auf der Zunge zergehen

MfG Spess

von Bernd_Stein (Gast)


Lesenswert?

spess53 schrieb:
> Hi
>
> Du solltest das Instruction-Set richtig lesen. Zum Carry-Flag bei 'subi'
> steht:
>
> Set if the absolute value of K is larger than the absolute value of Rd;
> cleared otherwise.
>
> Fertig und aus.
>
> Lass dir mal absolute value auf der Zunge zergehen
>
> MfG Spess


Ja, genau und das möchte ich Hardwaremäßig an Hand des Paralleladdieres 
von Seite 14 verstehen, warum dies geschieht, das das Carry-Flag gesetzt 
wird.

MfG
Bernd_Stein

von spess53 (Gast)


Lesenswert?

Hi

>Ja, genau und das möchte ich Hardwaremäßig an Hand des Paralleladdieres
>von Seite 14 verstehen, warum dies geschieht, das das Carry-Flag gesetzt
>wird.

Du hast es hier aber mit einer Subtraktion von 2 Bytes zu tun. Aus dem

subi r16,-1 macht der Assembler subi r16,$FF und genau das wird 
gerechnet.

MfG Spess

von Karl H. (kbuchegg)


Lesenswert?

Bernd_Stein schrieb:

> Ja, genau und das möchte ich Hardwaremäßig an Hand des Paralleladdieres
> von Seite 14 verstehen, warum dies geschieht, das das Carry-Flag gesetzt
> wird.

Die entsprechende Logik ist dort nicht eingezeichnet. Dort geht es 
ausschliesslich um Addition. (Und nein, auch wenn logisch gesehen 
Subtraktion als Additionsersatz benutzt werden kann, so passiert im 
Inneren höchst wahrscheinlich etwas anderes. Erkennbar an der 
Beschreibung wie die Flags auf die Befehle reagieren)

Das ist ein Prinzipschema, wie es so ganz sicher nicht im AVR 
implementiert ist.
Wollte man die komplette Logik, so wie sie realisiert ist, im Buch 
abbilden, so wären das ein paar hundert Seiten nur Diagramme.

von MarioT (Gast)


Lesenswert?

spess53 schrieb:
> subi r16,-1 macht der Assembler subi r16,$FF und genau das wird
> gerechnet.

Ich hab mal ne Frage, wozu braucht man das: "subi r16,-1" ?
(Ist wirklich ehrlich gemeint)

Bernd_Stein,
Du darfst nicht so sehr davon ausgehen was Du schreibst, sondern was der 
Assembler draus macht und in den Flash schreibt.

von Karl H. (kbuchegg)


Lesenswert?

MarioT schrieb:
> spess53 schrieb:
>> subi r16,-1 macht der Assembler subi r16,$FF und genau das wird
>> gerechnet.
>
> Ich hab mal ne Frage, wozu braucht man das: "subi r16,-1" ?
> (Ist wirklich ehrlich gemeint)

Die AVR haben keinen addi
Aber man kann natürlich auch -1 abziehen (oder irgendeinen anderen Wert)

   i = j + k    <-->   i = j - (-k)

> Du darfst nicht so sehr davon ausgehen was Du schreibst,
> sondern was der Assembler draus macht und in den Flash schreibt.

Na ja, das ist im Falle des AVR Assembler schon dasselbe.
Aber er macht den Fehler ein Prinzipschaltbild mit dem was real im 
Prozessor implementiert ist zu verwechseln. Prinzipschaltbilder sind 
notgedrungen abgespeckt und konzentrieren sich auf einen Aspekt. In dem 
Fall eben Addition. Er hat aber keine Addition und daher gilt das 
Prinzipschaltbild nicht mehr in allen Details.

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Karl heinz Buchegger schrieb:
> MarioT schrieb:
>>
>> Ich hab mal ne Frage, wozu braucht man das: "subi r16,-1" ?
>> (Ist wirklich ehrlich gemeint)
>
> Die AVR haben keinen addi
> Aber man kann natürlich auch -1 abziehen (oder irgendeinen anderen Wert)
>
>    i = j + k    <-->   i = j - (-k)

Ursprünglich war wohl ein addi und ein adci im AVR-Instruktionssatz 
vorgesehen. Aber da es subi/sbci gibt, ist ein Befehlspaar überflüssig 
und belegt nur Platz auf dem Silizium und in der Opcode-Tabelle, der 
sinnvoller für was anderes genutzt werden kann.

AVR eintstand teilweise im Codesign mit Compilerbauern, er sollte darauf 
ausgelegt werden, daß Compiler möglichst effizienten Code erzeugen 
können. Und einem Compiler ist es egal, ob er +1 oder -(-1) 
hinzuschreiben hat. Comfort für Assembler-Programmierer steht da nicht 
ganz oben auf der Liste...

Warum die beiden Immediate-Additionen rausgeflogen sind und nicht die 
Immediate-Subtraktionen, darüber kann man spekulieren. Vielleicht weil 
die Logik der sub-Befehle genauso ist wie die der cmp-Befehle. Einziger 
Unterschied ist, daß die compares nur die Flags verändern und kein 
Ergebnis schreiben. Und leider fehlt ein sinnvolles cpci (compare with 
carry immediate) :-(

von MarioT (Gast)


Lesenswert?

Karl heinz Buchegger schrieb:
> Die AVR haben keinen addi

Ist schon klar. Ich würde es aber eher so "subi r16,$FF" machen

Karl heinz Buchegger schrieb:
> Na ja, das ist im Falle des AVR Assembler schon dasselbe.

Ok hast ja recht. Ich meinte das der Assemler keine negative Zahl("-1") 
schreibt sondern nach "11111111" umwandelt(ist natürlich quatsc, weil 
beides das gleiche ist). Noch besser ist natürlich, wenn man davon 
ausgeht, das es negative Zahlen gar nicht gibt.

von spess53 (Gast)


Lesenswert?

Hi

>Ich meinte das der Assemler keine negative Zahl("-1")
>schreibt sondern nach "11111111" umwandelt

Das Ganze hat eigentlich mehr mit der Lesbarkeit des Programms zu tun.

MfG Spess

von Bernd_Stein (Gast)


Lesenswert?

Karl heinz Buchegger schrieb:
>> Ja, genau und das möchte ich Hardwaremäßig an Hand des Paralleladdieres
>> von Seite 14 verstehen, warum dies geschieht, das das Carry-Flag gesetzt
>> wird.
>
> Die entsprechende Logik ist dort nicht eingezeichnet. Dort geht es
> ausschliesslich um Addition.

Das sehe ich nicht so.

Erstens  in Klammern (Minuend) und (Subtrahend negiert).
Zweitens Steuerbit S = 0 addieren, S =1 subtrahieren
auf der nachfolgen Seite zu lesen.

Nur wenn ich die Volladdierer (VA) durch die AND, EXOR, und OR Schaltung
aufgelöst aufzeichne und dies durchspiele komme ich nicht zum richtigen 
Ergebnis.

Für die Additon ist alles in Ordnung.

Bis dann
Bernd_Stein

von Simon K. (simon) Benutzerseite


Lesenswert?

Johann L. schrieb:
> AVR eintstand teilweise im Codesign mit Compilerbauern, er sollte darauf
> ausgelegt werden, daß Compiler möglichst effizienten Code erzeugen
> können. Und einem Compiler ist es egal, ob er +1 oder -(-1)
> hinzuschreiben hat. Comfort für Assembler-Programmierer steht da nicht
> ganz oben auf der Liste...

Wobei Assembler Programmierer in deinem Sinne der Assemblerprogrammierer 
vor 50 Jahren ist, der Hex-Codes eintippt ;-)

Selbst ein Makro Assembler könnte ein ADDI r, k Befehl einführen, das 
einfach nur ein Makro ist für SUBI r, -k. Wobei man immer noch das 
Problem hätte mit der kleinen, nennen wir es Inkonsistenz mit dem Carry 
Bit.

von spess53 (Gast)


Lesenswert?

Hi

>Nur wenn ich die Volladdierer (VA) durch die AND, EXOR, und OR Schaltung
>aufgelöst aufzeichne und dies durchspiele komme ich nicht zum richtigen
>Ergebnis.

Mit dem Adder aus dem Buch passt es übrigens auch.


                       0111 1111    $7F
                      +0000 0000   /$FF
               /Ca    +        1
                ----------------
                    0  1000 0000
               /Cy  1

ergibt $80 und Cy=1

MfG Spess

von Bernd_Stein (Gast)


Lesenswert?

spess53 schrieb:
>>Nur wenn ich die Volladdierer (VA) durch die AND, EXOR, und OR Schaltung
>>aufgelöst aufzeichne und dies durchspiele komme ich nicht zum richtigen
>>Ergebnis.
   _________________________________
  |                                  |
  SB          a   b                  |  C_alt     C_alt = Carry-Flag_alt
  |           |   |                  |    |
  |           |___|_________         |    |
  |           |   |____     |        |    |       SB = 0 addieren
  |           |   |    |    |        |    |       SB = 1 subtrahieren
  |    {HA}  [ AND ]  [ EXOR ]      [ EXOR ]
  |             |         |    _________|
  |             |         |___|____     |
  |             |         |   |    |    |
  |             |        [ AND ]  [ EXOR ]  {HA}  HA = Halbaddierer
  |             |           |         |
  |             |     ______|         |
  |             |    |                | SB = 1 => Subtraktionsbit
  |            [  OR  ]               |  a = 0 => 1.Summand bzw.
  |                |                  |           (Minuend)
  |____________    |                  |
               |   |                  |  b = 1 => 2.Summand bzw.
             [ EXOR ]                 |           (Subtrahend negiert)
                 |                    |
                 |                    |         C_neu = Carry-Flag_neu
               C_neu                Summe

                 1                    1

Jetzt passt es.
Habe den Text auf Seite 15 Fehlinterpretiert. Habe Ca immer negiert.
Auch das gepunktete Rechteck um Ca herum deutet darauf hin,
deshalb hatte ich es nicht verstanden.

Bis demnächst
Bernd_Stein

von spess53 (Gast)


Lesenswert?

Hi

Glaubst du ehrlich das das dir weiterhilft? Oder willst du einen 
Controller nachbauen?

>Bei meinen eigenen Programmierungen halfen mir die ersten beiden Bücher
>nur zum Teil, da sie schon ziemlich alt sind. Ich nutzte sie als
>Nachschlagewerke.

Wenn du schon programmiert hast, was soll dann der Scheiss. Irgendwie 
habe ich das Gefühl, das du dir selbst massiv im Weg stehst.

MfG Spess

von PeterH (Gast)


Lesenswert?

Schau bei Deinen AVR Programmierungen zuallererst in die Instruction-Set 
Doku, da steht ohne jeden Schnörkel  drin was Du ganz konkret machst 
bzw. machen kannst. Ich glaub wirklich (und so hab ichs auch gelernt) 
das Einfachste und Hilfreichste ist wenn Du wirklich ganz unten 
anfängst. Alles andere lenkt zunächst nur ab (gerade auch bei höherem 
Abstraktionslevel) wenn dieses Grundwissen fehlt.

von Bernd_Stein (Gast)


Lesenswert?

Noch was Wichtiges.

Beim Bild vom 2-Bit Addierer / Subtrahierer
ist b beim subtrahieren (b = Subtrahend) zu negieren.

Bis demnächst
Bernd_Stein

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Hallo zusammen,

es ist wirklich schade das in diesem Buch so verdammt spärlich auf die 
Bedingungsbits ( Flags ) im Statusregister ( SREG ) eingegangen wird.

Ich beschäftige mich gerade eingehend mit dem Halfcarry-Flag,
was sich genauso verhalten dürfte wie das Carry-Flag. Nur halt mit dem 
Bit3.

Beim NEG-Befehl steht foldendes :

Rd <= $00 - Rd

H = P3 + /Rd3

Jetzt habe ich folgendes progrämmchen im ATMEL-Studio 7.0.1188 laufen 
lassen und wunderte mich, das das Halfcarry-Flag nicht gesetzt wurde, 
obwohl Rd ja = $00 ist, was ich mal als /Rd interpretiere.
1
;
2
;.INCLUDE "m8def.inc"        ;AVR-Definitionsdatei einbinden
3
.CSEG                       ;was ab hier folgt kommt in den FLASH-Speicher
4
.ORG $0000              ;Programm beginnt an der FLASH-Adresse 0x0000.CSEG 
5
6
.INCLUDE "Header_A400_BS.inc" ;Einbinden der Controllerspezifischen 
7
                              ;Definitionsdatei, sowie weitere Definitionen und
8
                              ;Wertezuweisungen
9
                               
10
_RESET:                     ;Hier beginnt der µC nach einem Reset mit seiner Arbeit
11
 rjmp _START             ;Springe zum Programmbeginn
12
13
_START: 
14
15
 clr    al                  ;Arbeitsregister-Low Null setzen...
16
 neg    al                  ;... und das Zweierkomplement davon bilden
17
 
18
 rjmp   _START
19
    
20
.EXIT                       ;Ende des Quelltextes

Wo ist mein Gedankenfehler ?


Bernd_Stein

von Falk B. (falk)


Lesenswert?

@Bernd Stein (bernd_stein)

>es ist wirklich schade das in diesem Buch so verdammt spärlich auf die
>Bedingungsbits ( Flags ) im Statusregister ( SREG ) eingegangen wird.

Bist du aus einer Zeitmaschine gefallen? Der Thread ist SIEBEN Jahre 
alt.

>Ich beschäftige mich gerade eingehend mit dem Halfcarry-Flag,

Seit SIEBEN Jahren? OMG!

von Stefan F. (Gast)


Lesenswert?

> es ist wirklich schade das in diesem Buch so verdammt spärlich auf die
> Bedingungsbits ( Flags ) im Statusregister ( SREG ) eingegangen wird.

Wir schreiben inzwischen das Jahr 2017 - das Buch ist 9 Jahre alt!

Wer verlässliche Informationen zu Befehlssätzen sucht, sollte sich die 
Literatur des Herstellers zulegen. Im Fall von AVR's das hier:

http://www.atmel.com/images/Atmel-0856-AVR-Instruction-Set-Manual.pdf

Da steht klar drin:

Diese Operation Subtrahiert den Wert des Registers von $00. Das H Fag 
wird gesetzt, wenn dabei von Bit 3 geborgt wird.

Mein sohn lernt gerade ind er 4. Schulklasse das schriftliche 
Subtrahieren von großen Zahlen. Wenn ich mal die Regeln, die er dort 
lernt auf das Binärsystem anwende, dann muss man sich von Bit 3 eine 1 
borgen, wenn rechts davon irgend ein Bit gesetzt war.

Zumindest der Simulator des Atmel Studio 4.19 tut das auch genau so.
1
#include "tn13def.inc"
2
3
            ldi r16,0b000001000
4
            neg r16
5
6
            ldi r16,0b000000100
7
            neg r16
8
9
            ldi r16,0b000000010
10
            neg r16
11
12
            ldi r16,0b000000001
13
            neg r16
14
15
            ldi r16,0b000001111
16
            neg r16
17
18
ende:
19
            rjmp ende

Nun zu deinem Code:

> clr   al
> neg   al

Das ergibt die Operation 0 - 0. Da muss man nichts borgen, als kein 
Half-Carry Flag.

Wir sind also immer noch dabei, die Subtraktion zu lernen, wie vor 7 
Jahren - meinst du das ernst?

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Stefan U. schrieb:
> Wir sind also immer noch dabei, die Subtraktion zu lernen, wie vor 7
> Jahren - meinst du das ernst?
>
Nein.
Das der µC in Wirklilchkeit gar keine Subtraktion kennt, sondern nur die 
Addition mit dem Zweierkomplement, habe ich mir die ganzen Jahre über 
gemerkt und weiß es sogar auch anzuwenden :-)

Mein Problem lag in dem Verständnis des von dir verlinktem
" Instruction Set Manual ". Dein Beitrag hat mir in der Hinsicht etwas 
mehr die Augen geöffnet, so daß ich mich nicht nur auf diese Sache 
versteifen sollte H = P3 + /Rd3, sondern auch nach dem dortigen Text 
richten muß => Set if there was a borrow from Bit3; cleared otherwise.

Allerdings bin ich mit dieser Aussage nicht ganz einverstanden. Kann 
natürlich daran liegen, das ich das Englische falsch interpretiere und 
habe mir deshalb aus allem was ich hierzu gelesen habe, einen eigenen 
Satz zum Halfcarry-Flag zusammengezimmert :

Das Halfcarry-Flag wird gesetzt, wenn das Low-Nibble ( Bit3..0 ) 
überläuft, es also zu einem Übertrag zum High-Nibble kommt, oder bei 
einer Subtraktion der Wert des Low-Nibble größer ist, als der des 
High-Nibble, es also zu einem Borgen kommt.

Hab da jedoch noch eine Frage : " Was soll P3 bedeuten " ?


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

> Das der µC in Wirklilchkeit gar keine Subtraktion kenn...
> Was soll P3 bedeuten?

Wer ist "der" Mikrocontroller und wo hast du etwas über "P3" gelesen?

Die 8bit AVR Mikrocontroller, um die es in dem von mir zittierten 
Datenblatt geht und auf das ich Bezug nahm, können durchaus subtrahieren 
(SUB Befehl). Und P3 kommt in dem gesamten Dokument nirgends vor.

Kann es sein, dass du die Dokumentationen mehrerer Mikrocontroller 
durcheinander gewürfelt hast?

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Stefan U. schrieb:
> Die 8bit AVR Mikrocontroller, um die es in dem von mir zittierten
> Datenblatt geht und auf das ich Bezug nahm, können durchaus subtrahieren
> (SUB Befehl). Und P3 kommt in dem gesamten Dokument nirgends vor.
>
Wenn du nicht über 7000 Beträge bisher geschrieben hättest und ich nicht 
der Meinung wäre, daß du etwas von der Materie verstehst, hätte ich 
nicht geantwortet.
Nun, da ein Bild ja bekanntlich mehr sagt als tausend Worte, habe ich 
dies mal angefügt.

Die ALU ( Arithmetic and Logic Unit ) bzw. das Rechenwerk kann ja noch 
nicht einmal im eigentlichen Sinne addieren, aber logische Verknüpfungen 
druchführen schon. Darauf baut ja die Addition auf.

Siehe : Beitrag "Re: Buch AVR von Günter Schmitt durcharbeiten"

oder die Seiten 13 bis 15 in dem zur Diskussion stehendem Buch.


Bernd_Stein

: Bearbeitet durch User
von Alexander S. (alesi)


Lesenswert?

Bernd S. schrieb:
> Mein Problem lag in dem Verständnis des von dir verlinktem
> " Instruction Set Manual ". Dein Beitrag hat mir in der Hinsicht etwas
> mehr die Augen geöffnet, so daß ich mich nicht nur auf diese Sache
> versteifen sollte H = P3 + /Rd3, sondern auch nach dem dortigen Text
> richten muß => Set if there was a borrow from Bit3; cleared otherwise.

Bernd S. schrieb:
> Hab da jedoch noch eine Frage : " Was soll P3 bedeuten " ?

Stefan U. schrieb:
> Und P3 kommt in dem gesamten Dokument nirgends vor.

Auf S. 129 unter 84.2. Status Register (SREG) and Boolean Formula
in http://www.atmel.com/images/Atmel-0856-AVR-Instruction-Set-Manual.pdf
steht tatsächlich
  H  Ρ3 + /Rd3
  Set if there was a borrow from bit 3; cleared otherwise.

Ich denke das ist ein Tippfehler und soll R3 + /Rd3 heißen.

/Rd3 steht für Rd3 mit Oberstrich.

von Stefan F. (Gast)


Lesenswert?

Interessant, ich hatte eben in meine lokale Kopie des Manuals geschaut, 
und da steht in Kapitel 84.2 "H: R3 + /RD3"

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Ich muss meinen " selbstgezimmerten " Text zum Halfcarry-Flag bezüglich 
der Subtraktion noch einmal korrigieren, da er anscheinend so nicht 
stimmt. Es heißt nun für mich :

" Das Halfcarry-Flag wird gesetzt, wenn das Low-Nibble ( Bit3..0 )
überläuft, es also zu einem Übertrag zum High-Nibble kommt.
Bei der Subtraktion ist es zu invertieren. "

Wenn ich nämlich das folgende programm Handschriftlich nach der Devise :

" Der µC subtrahiert den Subtrahenden, indem er das Zweikomplement des 
Subtrahenden addiert " durchgehe, trifft dieser Satz zu.
1
_MAIN:
2
 ldi    r16,100   ;0110 0100
3
 subi   r16,50    ;0011 0010 Handschriftlich H = 1
4
5
 ldi    r16,100   ;0100 0100
6
 subi   r16,100   ;0100 0100 Handschriftlich H = 1
7
8
 ldi    r16,100   ;0100 0100
9
 subi   r16,200   ;1100 1000 Handschriftlich H = 0
10
11
 rjmp   _MAIN
12
;
13
;Ende des Hauptprogramms (falls keine Endlosschleife im Hauptprogramm)
14
;
15
_END:
16
 nop
17
 rjmp  _END        ;Endlosschleife
18
19
20
.EXIT          ;Ende des Quelltextes

Obwohl im letzem Beispiel ( 100 weniger 200 ), der Low-Nibble Wert 
nicht größer ist, wird das H-Flag vom µC gesetzt.


Bernd_Stein

von Route_66 H. (route_66)


Lesenswert?

Ich hoffe noch so alt zu werden, bis du die nächste Frage zum Zero-Flag 
stellst.

von Modellflieger (Gast)


Lesenswert?

Wie geil ist  das denn?
Sieben Jahre vor dem Rechner und den Büchern gesessen und jetzt wieder 
eine Frage.

Bernd programmierst Du eigentlich irgendetwas mit AVR oder sitzt Du nur 
vor dem Simulator und suchsts Schreibfehler im Datenblatt?

von Dieter F. (Gast)


Lesenswert?

Mit Vorzeichen kann ein Byte nur -128 bis +127 darstellen. -200 gibt es 
nicht (in einem Byte).

Beitrag #4953600 wurde vom Autor gelöscht.
von Dieter F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Das Halfcarry-Flag wird gesetzt, wenn das Low-Nibble ( Bit3..0 )
> überläuft, es also zu einem Übertrag zum High-Nibble kommt, oder bei
> einer Subtraktion der Wert des Low-Nibble größer ist, als der des
> High-Nibble, es also zu einem Borgen kommt.

Scharf wäre es gewesen, wenn Du die entsprechenden Artikel mal gelesen 
hättest (in den vergangenen 7 Jahren):

Das Haupteinsatzgebiet ist der Bereich der BCD Arithmetik, bei der 
jeweils 4 Bits eine Stelle einer Dezimalzahl repräsentieren.

https://www.mikrocontroller.net/articles/AVR-Tutorial:_Vergleiche#Half_Carry_.28H.29

von Markus K. (markus-)


Lesenswert?

Bernd S. schrieb:
> Die ALU ( Arithmetic and Logic Unit ) bzw. das Rechenwerk kann ja noch
> nicht einmal im eigentlichen Sinne addieren, aber logische Verknüpfungen
> druchführen schon. Darauf baut ja die Addition auf.

Was ist denn eine Addition "im eigentlichen Sinne"? Wird eine Addition 
in einem Prozessor nicht immer durch logische Verknüpfungen gemacht? Ist 
denn nicht sogar der ganze Prozessor eine große Ansammlung an 
Logikgattern?

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Dieter F. schrieb:
> Mit Vorzeichen kann ein Byte nur -128 bis +127 darstellen. -200 gibt es
> nicht (in einem Byte).
>
Oh danke für diesen Hinweis. Habe ich auch völlig übersehen. Es geht mir 
eigentlich darum, im Vorfeld oder zumindest beim handschriftlichem 
Druchspielen zu erkennen, wann das H-Flag gesetzt wird oder nicht.

Habe mich jetzt mal eingehender mit der BCD-Arithmetik beschäftigt, 
finde aber immer nur 4-Bit und nirgends 8-Bit Aufgaben die 
handschriftlich zeigen wie es funktioniert. Habe mir diesbezüglich 
selber gepackte BCD-Aufgaben gestellt und dachte schon, das ich 
verstanden hätte wie es geht, aber dann...

 97d   1001 0111 $97
+16d  +0001 0110 $16
----  ----------
       1010 1101 Pseudotetrade    2x
      +0110 0110 Dezimalkorrektur 2x
      ----------
113d  C0001H0011 $113 passt alles wunderbar !!!


 99d   1001 1001 $99
+99d  +1001 1001 $99
----  ----------
      C0011H0010 Halfcarry gesetzt => Dezimalkorrektur anwenden
      +0110 0110 bei beiden Nibbles ?
      ----------
198d   1001 1000 $98

In der BCD-Arithmetik bei der Addition heißt es ja, wenn es ein Übertrag 
zu Bit4, also in die 5.Stelle gibt (H-Flag gesetzt ), so ist eine 
Dezimalkorrektur durchzuführen.

Jetzt stellte sich mir die Frage, ob dies nur beim Low-Nibble zu machen 
ist oder bei beiden. Wenn ich dies bei beiden machte kam ich dem 
Ergebnis schon sehr nahe, aber das Carryflag wurde nicht gesetz.
Es kommt als Ergebnis also nur 98 heraus und nicht die gewünschten 198.

Was läuft hier falsch und wo kann ich so etwas üben ?


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Falsch läuft hier, dass du alle CPU's der Welt in eine Schublade stecken 
willst.

Wenn ein hersteller will, dass baut er Dir auch ein Carry Flash, dass 
nur bei der Addition und Überlauf von Bit 2 nach 3 gesetzt wird.

Du solltest Dich mal von deiner Vorstellung trennen, daß alle CPU's 
gleich funktionieren. Sie sind nicht die Inkarnation der 
Schul-Mathematik. Jede CPU hat irgendo ihre Sonderlocken.

von Light up the magic in every little part (Gast)


Lesenswert?

Stefan U. schrieb:
> Jede CPU hat irgendo ihre Sonderlocken.

Das macht die Programmierung haarig.

von Dieter F. (Gast)


Lesenswert?

Bernd S. schrieb:
> 99d   1001 1001 $99
> +99d  +1001 1001 $99
> ----  ----------
>       C0011H0010 Halfcarry gesetzt => Dezimalkorrektur anwenden
>       +0110 0110 bei beiden Nibbles ?
>       ----------
> 198d   1001 1000 $98

  99d        1001 1001 $99
 +99d       +1001 1001 $99
 ----       ----------
            C0011H0010 Halfcarry gesetzt => Dezimalkorrektur anwenden
            +0110 0110 bei beiden Nibbles ? -> ja, natürlich
            ----------
198d    0001 1001 1000 $198

-> passt. Das geht dann natürlich nur bei mehr als 8 Bit BCD - mit 8 Bit 
BCD kannst Du als Zahl nur max. 99 abbilden. Logisch - oder?

Übrigens:

https://kowa.hs-augsburg.de/medium/text/lehre/2009wise/csa/VCAI-03-zahlen.pdf

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Dieter F. schrieb:
> -> passt. Das geht dann natürlich nur bei mehr als 8 Bit BCD - mit 8 Bit
> BCD kannst Du als Zahl nur max. 99 abbilden. Logisch - oder?
>
Wie du siehst, kann man bei geschickter Carryflag-Auswertung auch bis 
198 darstellen.

Der Link hat einen unwichtigen Fehler, aber danke, daran konnte ich 
sehen wie so etwas bei mehr als 4-Bit gehandhabt wird. Folgendes 
Beispiel zeigt auch schön wie das H-Flag bei der Addition von BCD-Zahlen 
gebraucht wird. Nämlich dann, wenn es einen Übertrag gibt und dadurch 
angezeigt wird, das eine Dezimalkorrektur nötig ist.

 3619d   0011 0110 0001 1001
+5438d  +0101 0100 0011 1000
------  --------------------
         1000 1010 0101H0001  H=1 und Pseudotetrade
        +0000 0110 0000 0110  Dezimalkorrektur
        --------------------
 9057d   1001H0000 0101 0111  Ergebnis ( H-Flag jetzt uninteressant )


Bernd_Stein

von Dieter F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Wie du siehst, kann man bei geschickter Carryflag-Auswertung auch bis
> 198 darstellen.

Nö, nur erkennen. Darstellen und weiterverwenden ist etwas anderes.

Bernd S. schrieb:
> 9057d   1001H0000 0101 0111  Ergebnis ( H-Flag jetzt uninteressant )

Und wie kommt dann die 1 dahin?

100 1 H0000 0101 0111

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Dieter F. schrieb:
> Und wie kommt dann die 1 dahin?
>
> 100 1 H0000 0101 0111
>
Schön zu sehen, das es mir allein nicht immer so geht, das ich mich 
ständig vertue.

Ich bin immer noch der Meinung, das man mit einem Byte bei geschickter 
Carryflag-Auswertung, drei Siebensegmentanzeigen, dahingehend nutzen 
kann, um zwei zweistellige positive gepackte BCD-Zahlen nach einer 
Addition bis zum Wert 198 richtig darauf anzuzeigen.

Allerdings könnte ich dies nur mit einem funktionierendem Programm bzw. 
mit zugehöriger Hardware beweisen. Dazu fehlt mir leider die Motivation, 
da dieser BCD-Kram ja nur äußerst selten genutzt wird und so wie ich 
gelesen habe aus der Finazwelt kommt, um Rundungsfehler auszuschließen.


Bernd_Stein

von Dieter F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Ich bin immer noch der Meinung, das man mit einem Byte bei geschickter
> Carryflag-Auswertung, drei Siebensegmentanzeigen, dahingehend nutzen
> kann, um zwei zweistellige positive gepackte BCD-Zahlen nach einer
> Addition bis zum Wert 198 richtig darauf anzuzeigen.

Was hat das Byte mit den Siebensegment-Anzeigen zu tun? Wenn Du nicht 
gerade BCD sondern integer (ohne Vorzeichen) rechnest kannst Du 
natürlich den Wert 198 in einem Byte ablegen und dann irgendwo und 
irgendwie anzeigen.
Das hat nichts mit dem Carryflag zu tun - welches nicht einem speziellen 
Byte zugeordnet ist sondern nur als Ergebnis eines Programmschrittes zu 
Beginn des Folgeschrittes sicher zur Verfügung steht.

Zum Sinn von BCD kann ich nur Wikipedia zitieren: "BCD-Arithmetik stammt 
aus Zeiten, in denen man den Aufwand der Wandlung zwischen interner 
Repräsentation und externer Darstellung gering halten wollte.".
Das halte ich auch für sinnvoll - wenn man Zahlen nur speichern und 
wieder ausgeben will, warum soll man sie dann jeweils aufwändig 
umrechnen (z.B. in/aus Fließkomma-Zahlen). SAP-ERP-Systeme arbeiten 
heute noch damit.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Das Thema Halfcarry-Flag soll nun sein Ende finden.
Ich merke mir hierzu :

Das Halfcarry-Flag wird zum einen gesetzt, wenn die Addition der 
Low-Nibble Summanden ( Bit3..0 ) einen Übertrag in das High-Nibble 
erzeugt, also der Wert 15 der Summe überschritten wird.

Zum anderen, wenn der Low-Nibble-Wert des Subtrahenden größer ist,
als der Low-Nibble-Wert des Minuenden. Es also zu einem Borgen kommt.


Um diese knapp gehaltenen Terme im AVR-Instrution Set Manual zum 
H-Flag zu verstehen, habe ich mal alle Befehle herausgesucht, die das 
H-Flag beeinflussen. Damit dann alle vier Möglichkeiten mit den beiden 
Bits Rd3 und Rr3 bzw. K3 vorgenommen und nun erklären sich auch solche 
Sachen bei der Addition wie :

H =  Rd3&Rr3  +  Rr3&/R3  +  /R3&Rd3

oder bei der Subtraktion :

H = /Rd3&Rr3  +  Rr3&R3   +  R3&/Rd3

oder dem NEG-Befehl :

H = /Rd3      +  R3

      |      |      |      |SBCI  |      |
      |ADC   |SBC   |CPC   |SUBI  |$00-Rd|
      |ADD   |SUB   |CP    |CPI   |NEG   |
   Rd3| 1010 | 1010 | 1010 | 1010 | 1010 |
K3;Rr3| 1100 | 1100 | 1100 | 1100 | 1100 |
    R3| 0110 | 0110 | 0110 | 0110 | 0110 |
     H| 1000 | 0100 | 0100 | 0100 | 0111 |
        #       #      #      #      ###

Wenn man die Spalten nimmt, wo der Lattenzaun drunter ist und die Zeilen 
hierzu Senkrecht betrachtet, findet man die obigen Terme wieder,
an denen man sieht wann das H-Flag gesetzt wird.


Bernd_Stein

von Dieter F. (Gast)


Lesenswert?

Bernd S. schrieb:
> habe ich mal alle Befehle herausgesucht

Das hättest Du auch einfach haben können:

http://www.avr-asm-tutorial.net/avr_de/beginner/commands.html


Aber schön, dass jetzt für Dich alles erklärbar ist - dann kannst Du den 
Thread ja schließen lassen.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Auf der Seite 62 bzw. 74 steht:

" ...Der Anfangswert wird aus dem Systemtakt berechnet, der als Symbol 
TAKT im Hauptprogramm definiert sein muss. Ein Zahlenüberlauf bei 
Frequenzen größer 16,38MHz wird durch die bedingte Assemblierung 
abgefangen.

1
.IF (TAKT/250) > 65535         ;Anfangswert fuer max. 16MHz
2
.ERROR "Fehler: TAKT > 16MHz "
3
.ELSE
4
 ldi XL,LOW (TAKT/250)         ; 8MHz / 250 = 32000
5
 ldi XH,HIGH(TAKT/250)         ; 32000*5*1/8 MHz = 20ms
6
.ENDIF

Abgesehen davon, dass sich wohl ein Fehler in dem Kommentarteil mit den 
8MHz Beispiel eingeschlichen hat, frage ich mich

1. Warum gerade 16,38MHz, wenn ein 16MHz verbaut ist?
   Evtl. weil man mit einem 16,384MHz Quarz genauere Baudraten 
generieren kann ?

und

2. Warum nicht durch z.B. 245 geteilt wird, was 65306,122 ergeben würde 
( auf 16MHz bezogen ).


Bernd_Stein

: Bearbeitet durch User
von Karl B. (gustav)


Lesenswert?

Hi,
Seite 524 ff.
Verzeichnis der Programmbeispiele
Dafür gab es 'mal sogar eine kostenlose CD als Beigabe.
Beispiel:
einbcd Eingabe von vier BCD Stellen nach R17:R16 C=1 Fehler

ciao
gustav

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Karl B. schrieb:
> Hi,
> Seite 524 ff.
> Verzeichnis der Programmbeispiele
> Dafür gab es 'mal sogar eine kostenlose CD als Beigabe.
> Beispiel:
> einbcd Eingabe von vier BCD Stellen nach R17:R16 C=1 Fehler
>
> ciao
> gustav
>
Habe ich mir kurz angesehen. Was willst du mir damit genau sagen ?
Bezieht sich ja anscheinend nicht auf meine vorherigen Fragen von heute.

Die CD habe ich leider nicht, denke es ist auch besser die Programme 
abzutippen, um die Syntax zu erlernen ;-)


Bernd_Stein

von Cyblord -. (cyblord)


Lesenswert?

Ich warte auf den Tag wenn du auf STM32 umsteigst. Das könnte dich 
locker 1000 Jahre beschäftigen.

von Markus K. (markus-)


Lesenswert?

Bernd S. schrieb:
> Warum gerade 16,38MHz, wenn ein 16MHz verbaut ist?

Das ist das Limit, das man nicht überschreiten darf. D.h. Du kannst an 
der Stelle erstmal keinen 17MHz Quarz benutzen. 16MHz sind aber ok.

Es geht eigentlich um folgendes:
Das Ergebnis der Division wird in 2 Bytes gespeichert. Da kann man aber 
nicht beliebig große Zahlen reintun. Das Limit für 16 Bit ohne 
Vorzeichen sind 65535. Das bedeutet, dass
Takt / 250 = maximal 65535

Das kann man jetzt Rückwärts rechnen:
65535 * 250 = 16383750
Das ist also der höchste Takt, bei dem das Ganze noch funktioniert.

von Karl B. (gustav)


Lesenswert?

Bernd S. schrieb:
> Was willst du mir damit genau sagen ?

Hi,
der Autor sagt doch auf Seite 170, dass das Programm "einbcd" abbricht.
"...Die Eingabe wird bei der ersten Nicht-Ziffer oder bei einem Überlauf 
abgebrochen..."

ciao
gustav

von spess53 (Gast)


Lesenswert?

Hi

>der Autor sagt doch auf Seite 170, dass das Programm "einbcd" abbricht.
>"...Die Eingabe wird bei der ersten Nicht-Ziffer oder bei einem Überlauf
>abgebrochen..."

Hast du mal auf das Datum des Beitrags, auf den du geantwortet hast 
gesehen?

MfG Spess

von Karl B. (gustav)


Lesenswert?

spess53 schrieb:
> Hast du mal auf das Datum des Beitrags, auf den du geantwortet hast
> gesehen?

Bernd S. schrieb:
> Bezieht sich ja anscheinend nicht auf meine vorherigen Fragen von heute.

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Bernd S. schrieb:
> Die CD habe ich leider nicht, denke es ist auch besser die Programme
> abzutippen, um die Syntax zu erlernen ;-)

Hi,
auf der CD ist noch eine Ergänzung.

ciao
gustav

: Bearbeitet durch User
von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Karl B. schrieb:
> Hi,
> der Autor sagt doch auf Seite 170, dass das Programm "einbcd" abbricht.
> "...Die Eingabe wird bei der ersten Nicht-Ziffer oder bei einem Überlauf
> abgebrochen..."
>
Danke für die zusätzlichen Informationen.
Mir ist klar, das der Assembler die Assemblierung abbricht,
wenn der TAKT > 16.383750 ist.

Karl B. schrieb:
> Hi,
> auf der CD ist noch eine Ergänzung.
>
Hm -? Ich habe die 4. Auflage.
Verstehe jedoch leider immer noch nicht den Zusammenhang, den du mir 
klarmachen willst.


Markus K. schrieb:
>> Warum gerade 16,38MHz, wenn ein 16MHz verbaut ist?
>
> Das ist das Limit, das man nicht überschreiten darf. D.h. Du kannst an
> der Stelle erstmal keinen 17MHz Quarz benutzen. 16MHz sind aber ok.
>
> Es geht eigentlich um folgendes:
> Das Ergebnis der Division wird in 2 Bytes gespeichert. Da kann man aber
> nicht beliebig große Zahlen reintun. Das Limit für 16 Bit ohne
> Vorzeichen sind 65535. Das bedeutet, dass
> Takt / 250 = maximal 65535
>
> Das kann man jetzt Rückwärts rechnen:
> 65535 * 250 = 16383750
> Das ist also der höchste Takt, bei dem das Ganze noch funktioniert.
>
Das liest sich sehr stimmig.
Es gibt Tatsächlich einen 16.384MHz Quarz, aber beim ATmega8, sowie beim 
ATmega16 ist in den Electrical Characteristics unter *External Clock 
Drive*, maximal 16MHz angegeben. Habe zwar schon gehört, das man diese 
auch übertakten kann, denke aber nicht das dies der Autor meint, da der 
Assembler ja abbrechen würde, wenn man die 16.384000 eingibt.

.IF (TAKT/245) > 65535 wäre da eigentlich passender gewesen ( 
16.056075MHz ), wenn es dem Autor Prof. Dipl.-Ing. darum ginge ;-)

Das Einzige was mir auffällt ist, das 16e6 / 250 eine Ganzzahl ergibt ( 
64000 ), was in Assembler immer von Vorteil ist.


Bernd_Stein

: Bearbeitet durch User
von Markus K. (markus-)


Lesenswert?

Bernd S. schrieb:
> Es gibt Tatsächlich einen 16.384MHz Quarz, aber beim ATmega8, sowie beim
> ATmega16 ist in den Electrical Characteristics unter *External Clock
> Drive*, maximal 16MHz angegeben.

Es könnte ja möglicherweise irgendwann mal Varianten geben, die 
schneller laufen. Allerdings sind diese beiden Controller schon alt, da 
wird sich wohl nichts mehr tun, aber z.B. der Mega88 läuft mit 20MHz.

> .IF (TAKT/245) > 65535 wäre da eigentlich passender gewesen (
> 16.056075MHz ), wenn es dem Autor Prof. Dipl.-Ing. darum ginge ;-)

Wenn man das Übertakten verhindern möchte, dann würde man ja wohl eher 
sowas schreiben:
.IF TAKT > 16000000

von Dirk B. (Gast)


Lesenswert?

Bernd S. schrieb:

>  ldi XL,LOW (TAKT/250)         ; 8MHz / 250 = 32000
>  ldi XH,HIGH(TAKT/250)         ; 32000*5*1/8 MHz = 20ms
> Abgesehen davon, dass sich wohl ein Fehler in dem Kommentarteil mit den
> 8MHz Beispiel eingeschlichen hat,...
... und großzügiges absehen vor einfachem nachrechnen schützt:
32000*5= 160000
(160000)/(8000000000 [1/s] )= 20s/1000=20ms
was:
> 2. Warum nicht durch z.B. 245 geteilt wird, was 65306,122 ergeben würde
> ( auf 16MHz bezogen ).
erklären könnte, da am Beispiel
 8MHz / 245 = 32653
 32653*5*1/8 MHz = 20,41ms
einfach nachrechenbar wäre, dass 245 sich schlecht eignet um mit dem 
Code 20ms zu messen.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Es scheint, das die 250 ( TAKT/250 ) gewählt wurden, um einen Kompromiss 
zu finden, um zwei Fliegen mit einer Klatsche zu erschlagen.
Einerseits, um ein Überlaufen eines 16-Bit-Wertes zu verhindern, wenn 
die Quarzfrequenz versehentlich zu hoch gewählt wurde und Andrerseits, 
um eine 16-Bit Ganzzahl aus den 8MHz ( 32000 ) oder 16MHz ( 64000 ) zu 
genererieren, mit der man z.B. einigermaßen exakte Zeiten mittels 
Warteschleifen erzeugen kann.
Versehentlich deshalb, weil der ATmega 8 & 16 bis maximal 16Mhz 
freigegeben sind und man mit Beispielsweise einem 16,367000MHz Quarz den 
µC bereits übertakten würde, aber die bedingte Assemblierung
( .IF (TAKT/250) > 65535 .ERROR "Fehler: TAKT > 16MHz " ) dies nicht 
abfangen würde.

Danke an Alle die zu dieser Erkenntnis beigetragen haben.


Bernd_Stein

: Bearbeitet durch User
von Dirk B. (Gast)


Lesenswert?

Bernd S. schrieb:
> Es scheint, das die 250 ( TAKT/250 ) gewählt wurden, um einen Kompromiss
> zu finden, um zwei Fliegen mit einer Klatsche zu erschlagen.
[..]
> Danke an Alle die zu dieser Erkenntnis beigetragen haben.
>
> Bernd_Stein

Allerdings steht im Kommentar, dass die 250 gewählt wurden, um 5 
(Takte) so oft zu wiederholen bis 20ms vergangen sind. Wenn du 
zusätzlich zu "dieser" Erkenntnis über den Schein auch das Programm für 
32MHz tauglich machen willst, dann kannst du einfach in der Schleife 5 
nop einfügen damit diese 10 statt 5 Takte je Durchlauf braucht und die 
250 durch 125 ersetzen.

edit: natürlich 250 durch 500 ersetzen

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Kennt jemand die Bücher von Herbert Bernstein zu den 
AVR-Mikrocontrollern, im Detail dieses ?

Mikrocontroller in der Elektronik:
Mikrocontroller programmieren und in der Praxis einsetzten.

Ich habe dieses und finde da wimmelt es nur von Fehlern und 
Fehldeutungen.
Es wird immer von einem Akkumulator geschrieben, aber die AVR's haben 
dieses Relikt gar nicht.

Deshalb würde ich mir dieses Nachfolger Buch auch nie Neu kaufen.

Mikrocontroller: Grundlagen der Hard- und Software der Mikrocontroller 
ATtiny2313, ATtiny26 und ATmega32

Dummerweise kriegt man es auch nicht gebraucht.

Was haltet ihr von diesem Autor ?


Bernd_Stein

von Dirk B. (Gast)


Lesenswert?

Bernd S. schrieb:
> Mikrocontroller in der Elektronik:
> Mikrocontroller programmieren und in der Praxis einsetzten.
> > Ich habe dieses und finde da wimmelt es nur von Fehlern und
> Fehldeutungen.
dann dürfte für dich ein Grundkurs wie ein Buch mit unbeweglichen 
Buchstaben zu verarbeiten ist die sinnvollere Alternative sein. Dein 
Kollege, der auch unter dem Label "Bernd Stein" Texte bei µC.net 
produziert, hat schon zwei fremde Menschen verdächtigt zu "dieser 
Erkenntnis" (wie der Produzent seine schrille Phantasie bezeichnet hat) 
beigetragen zu haben, ohne dass er einen_ _einzigen verdächtigen Text 
nennen konnte.
Ohne die Chance ganze Sätze lesen zu können und bspw. Kommentare in 
einem Quelltext bewusst wahrzunehmen fangen Bücher wohl sehr schnell zu 
wimmeln an.

> Es wird immer von einem Akkumulator geschrieben, aber die AVR's haben
> dieses Relikt gar nicht.
Das kannst du natürlich nicht wissen, aber übliche AVR's rechnen nicht 
im Hauptspeicher und haben 32 dieser Relikte und die meisten Befehle 
wirken auf max. einem dieser 32 Akkumulatoren.
Wenn du einen barrierefreien Zugang zu dem bereits geschrieben Text aus 
dem Buch hättest und nicht ein wiederholtes schreiben fühlen müsstest, 
dann könntest du einzelne feststehende Sätze die du nicht verstehst 
einfach zitieren.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

1
3.1.1  Akkumulator-Maschine
2
Die Akkumulator-Architektur ist das Organisationsprinzip vieler einfacher früher Rechner aber auch vieler Mikrocontroller (z.B. Motorola 6809). Sie zeichnet sich durch einen Akkumulator (ggf. auch zwei Akkumulatoren) als zentrales Register aus. Rechenergebnisse werden in diesem Register 
3
”akkumuliert“ (daher der Name). Rechenoperationen beziehen sich auf einen Operanden und implizit den Akkumulator. In der Befehlscodierung ist somit bereits die Information enthalten welches Register als Quelle und ggf. Ziel zur Operation genutzt wird...

UND
1
3.1.3  Registersatz-Maschine
2
Die  Registersatz-Architektur  basiert  auf  mehreren, üblicherweise  16  oder  32  gleichberechtigten  Universalregistern.  Abbildung  3.3  zeigt  die  allgemeine  Struktur  einer Registersatz-Maschine. Mindestens ein Operand wird aus einem der internen Prozessorregister bezogen, wobei dieses Register im Befehl explizit angegeben werden muss.
3
4
Überhaupt kennen Registersatz-Architekturen nur explizite Operanden, entweder Register oder Speicheradressen. Dass die Registersatz-Maschine - wie der Name schon sagt - auf einem Satz von Registern basiert, liefert einige Vorteile. Register sind schneller als RAM-Speicher. Dadurch dass  die  Register  als  Variablenspeicher  verwendet  werden,  kann  der  Speicherverkehr verringert und so die Programmausführung beschleunigt werden (da Register flexibler und schneller sind als Speicher). Letztlich wird im Gegensatz zur Verwendung von Speichervariablen auch die Codierung kompakter, da Register mit weniger Bits adressierbar sind als Speicherstellen...

Quelle :

https://prof.beuth-hochschule.de/fileadmin/prof/svoss/MOP/Skripte/Skript_MOP_WS16.pdf

Wenn man mir auf meine beiden einfachen Fragen antworten würde, wäre mir 
mehr geholfen.


In diesem Sinne,

Bernd_Stein

von Dirk B. (Gast)


Lesenswert?

Bernd S. schrieb:
> Wenn man mir auf meine beiden einfachen Fragen antworten würde, wäre mir
> mehr geholfen.
deine beiden einfachen Fragen
Bernd S. schrieb:
> Kennt jemand die Bücher von Herbert Bernstein zu den
> AVR-Mikrocontrollern, im Detail dieses ?
Bernd S. schrieb:
> Was haltet ihr von diesem Autor ?
dürften deine Hilflosigkeit einen Satz bzgl. µC eigenständig zu nennen 
verdeutlichen, aber wenn du wirklich nur emotionale Hilfe benötigst und 
dir Sachinformationen so derartig Angst machen, sodass du nur stumpf 
Texte kopieren kannst, dann  hast du wohl eine starke Gemeinsamkeit mit 
dem Bernd S. der dazu gezwungen war fremde Menschen zu verdächtigen 
anstatt dass er auch nur einen einzigen Satz eigenverantwortlich 
schreiben könnte.

Ohne die Möglichkeit eigenständig einen Satz zu beantworten wird es dir 
vermutlich wie dem Kauz vor einigen Wochen gehen, der stumpf zu blöd war 
einen Kommentar im Quelltext zu lesen und deswegen im Buch einen Fehler 
vermutet hat. obwohl der nachleslich nicht existiert Der Junge konnte 
auch nicht aus eigener Kraft zitieren und wird wohl auf fremde Hilfe 
angewiesen bleiben.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Dirk B. schrieb:
> Ohne die Möglichkeit eigenständig einen Satz zu beantworten wird es dir
> vermutlich wie dem Kauz vor einigen Wochen gehen,...
>
Ist dir schon mal aufgefallen, das du selbst ein eigenartiger Vogel 
bist,
der sich anscheinend nur selbst gerne zwitschern hört, als mal zuzuhören 
und darauf hin los zu trillern ?

Bernd_Stein, leider bei den Zitaten immer nur als Bernd S. schrieb : 
dargestellt.

von Stefan F. (Gast)


Lesenswert?

> Kennt jemand die Bücher von Herbert Bernstein zu den
> AVR-Mikrocontrollern, im Detail dieses ?
> Mikrocontroller in der Elektronik:
> Mikrocontroller programmieren und in der Praxis einsetzten.
Nein

> Was haltet ihr von diesem Autor ?
Dazu habe ich keine Meinung

Ich schlage allerdings dringend vor, dies in einem separaten neuen 
Thread mit passendem Titel zu diskutieren.

In einer Leseprobe habe ich diese Sätze gefunden:

"Hier befindet sich der POP-Befehl ... Das Datenbyte mit der Adresse
<Stackpointer+1>wirdindasersteRegisterdesPaaresgeladen. Wird das 
Registerpaar PSW spezifiziert, ersetzt das Byte, das durch den 
Stackpointer adressiert wird, die Bedienungsbits und das Byte, das durch 
den Stackpointer + 1 adressiert wird, den Akkumulator."

"wird  der  Befehl „ldi  acc0, $04“  ausgeführt. Der Akkumulator  hat 
den Wert 00000100 geladen."

"Mit  dem  Befehl „clr  acc0“ wird das Register bzw. der Akkumulator ge
löscht. Danach kommt der Befehl „out TCCR0B, acc0“ und der Inhalt des 
Akkumulators wird in das Timer-Register übernommen."

"Auch  für  Programmverzweigungen  und  Schleifen  in  einem 
Mikrocontrollerprogramm  gibt  es  spezielle  Befehle. 
Programmverzweigungen  werden  mithilfe  sogenannter  Branchanweisungen 
realisiert.  Wenn  der  Inhalt  des  Akkumulators  oder
eines vom Anwender definierbaren Registers den Wert Null annimmt, wird 
die Verzweigung eingeleitet (Branch on equal). Auf Wunsch kann auch 
verzweigt werden, wenn der Inhalt verschieden von Null ist (Branch not 
equal). Die Entscheidung, ob der Akkumulator bzw. das Register den Wert 
Null enthält, leitet der Mikrocontroller vom Statusregister ab."

"Mit „mov acc0, button“ wird der Zustand der bei den Schalter in den 
Akkumulator geschrieben und dann mit „andi acc0, $03“ mit
UND verknüpft. Dann folgt mit „cpi acc0, $02“ ein Löschen des Bits im 
I/O-Register."

usw. Das zieht sich offensichtlich durch das gesamte Buch durch.
Wenn ich nach "attiny2313 acc0" google, finde ich nur dieses eine Buch.

Ich frage mich, mit welchem Compiler bzw. welchen Register-Definitionen 
er seine Programme getestet hat.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Stefanus F. schrieb:
> Dann folgt mit „cpi acc0, $02“ ein Löschen des Bits im
> I/O-Register.
>
Das sind auch so die Sachen, die mich verwirren. Entweder bezieht er 
sich auf die Programmteile die nach dieser Passage folgen oder ich weiß 
auch nicht wie er auf solch eine Beschreibung kommt.
Habe auch gelesen das er schreibt das die INC und DEC-Befehle das 
H-Carryflag beeinflussen würden. Und dies im "alten" wie auch im 
"neueren" Buch.
Trotzdem würde ich dieses Buch gerne mal vollständig zu einem 
Gebrauchtpreis haben wollen, da es eines der wenigen Bücher ist, die 
sich mit den AVR's in Assembler herumschlagen.


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Ich würde ja eher einen Bogen um Franzis Produkte machen, wenn ich etwas 
lernen möchte.

von Dirk B. (Gast)


Lesenswert?

Bernd S. schrieb:
> Dirk B. schrieb:
>> Ohne die Möglichkeit eigenständig einen Satz zu beantworten wird es dir
>> vermutlich wie dem Kauz vor einigen Wochen gehen,...[ der stumpf zu blöd war 
einen Kommentar im Quelltext zu lesen und deswegen im Buch einen Fehler
vermutet hat. ]

> Ist dir schon mal aufgefallen, das du selbst ein eigenartiger Vogel
> bist,
> der sich anscheinend nur selbst gerne zwitschern hört, als mal zuzuhören
> und darauf hin los zu trillern ?
Nein die Geräusche von denen du berichtest stammen sicherlich aus deiner 
Umgebung. Du hast als Unmündiger sicherlich nicht die Erlaubnis 
eigenständig auf einen Text zu antworten und ein einziges Wort zu 
verstehen. Dein Leiden  bei "den" Zitaten immer nur als "Bernd S." 
dargestellt(sic!) zu werden ist sicherlich für dich adäquat.

Ohne einen barrierefreien Zugang zu Texten bleibt für dich nur die Hilfe 
fremder Menschen in Anspruch zu nehmen und zu beklagen der Autor des 
Buches hätte einen Fehler gemacht weil er die Möglichkeit eigenständig 
ein nop zu programmieren um eine Schleifendurchlauf von 5 auf 6 Takte zu 
verlängern bei den Lesern angenommen hat.

Wenn du lesen könntest dann könntest du zukünftig auch lernen ein nop zu 
programmieren, aber so bleiben dir nur deine Geräusche.

von Stefan F. (Gast)


Lesenswert?

Was ist nur los mit euch?

von Dirk B. (Gast)


Lesenswert?

Stefanus F. schrieb:
> Was ist nur los mit euch?
es gibt gelegentlich so etwas wie Traditionalisten die Defeat-Devicen 
etwas kritisch gegenüberstehen und solche Unterstellungen man hätte zu 
einer wirren Vorstellung etwas beigetragen nicht mögen.
Der Junge kann sicherlich nichts dafür dass er noch nicht aus eigener 
Kraft ein nop programmieren kann und damit die 16MHz bewältigen könnte, 
aber deswegen stumpfsinnig zu behaupten im Kommentar wäre der Fehler ist 
doch schon etwas unappetitlich. Was auch immer der Namens- 
Darstellungsbedürftige für eine genaue Hilfe benötigt, ohne 
Lesefähigkeit werden für ihn alle Bücher/Text Gewusel und Geräusche 
bleiben sobald er versucht etwas sachlich zu 'lernen'.

Das Buch dürfte sich eher an Fortgeschrittene richten, die bereits ein 
nop o.ä. programmieren können ohne auf fremde  Hilfe angewiesen zu sein, 
aber darüber hinaus könnte es sehr sehr individuelle 'Passungen' bzgl. 
Stil und Art der möglichen Ziele geben, sodass sich kaum eine seriöse 
gut/schlecht Aussage machen lässt. Der Kurs um zumindest Bogen machen zu 
lernen dürfte wohl zum erfolgreichen Selbstverkindlichungstudium 
dazugehören ;-)

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Habe das Programm " Verkettete Liste " von Seite 118 ( k2p11.asm ) mal 
durch den Atmel Studio Simulator laufen lassen. Habe bei *sbic PIND,7* 
einen Breakpoint gesetzt und dann erst bemerkt, das ich den PIND noch 
gar nicht simuliert habe ( PIND7 gesetzt ). Wenn ich dies dann 
nachträglich mache, wird der Nachfolgende Befehl ( rjmp _loop1 ) 
dennoch übersprungen.

Klar könnte ich den Breakpoint einen Befehl eher setzen ( *sts  LOW 
(kopfz),xl* ), aber wenn ich das mache, wird dieser für mich auch 
richtigerweise erst beim anklicken von Step Into ausgeführt und nicht 
wie bei *sbic PIND,7* der schon ausgeführt wird, bevor ich Step Into 
anklicke.

Gibt es hierfür eine Erklärung ?


Bernd_Stein

von BlaBla (Gast)


Lesenswert?

Bernd S. schrieb:
> Kennt jemand die Bücher von Herbert Bernstein zu den
> AVR-Mikrocontrollern, im Detail dieses ?
>
> Mikrocontroller in der Elektronik:
> Mikrocontroller programmieren und in der Praxis einsetzten.

Ja, ich kenne das Buch und habe es zu 2/3 gelesen. Meine Meinung dazu: 
es war eines der schlimmsten Bücher die ich jemals gelesen haben. Völlig 
daneben. Er erklärt nur selten was der Code bewirken soll, sondern im 
Stil: "löscht das Register... speichert in das Register... inkrementiere 
das Register..." alles ohne hintergründige Erklärung.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

BlaBla schrieb:
> Er erklärt nur selten was der Code bewirken soll, sondern im
> Stil: "löscht das Register... speichert in das Register... inkrementiere
> das Register..." alles ohne hintergründige Erklärung.
>
Ja, diesen Eindruck bekomme ich auch immer mehr. Zudem wie schon erwähnt 
sind für mich einige Fehler auch in dem " neueren " Buch ( zusätzlich 
ATmega32 ) übernommen worden. Mal sehen, wann ich etwas wirklich 
nützliches aus diesem Buch ziehen kann.

Bernd_Stein

von spess53 (Gast)


Lesenswert?

Hi

>Klar könnte ich den Breakpoint einen Befehl eher setzen ( *sts  LOW
>(kopfz),xl* ), aber wenn ich das mache, wird dieser für mich auch
>richtigerweise erst beim anklicken von Step Into ausgeführt und nicht
>wie bei *sbic PIND,7* der schon ausgeführt wird, bevor ich Step Into
>anklicke.

Muss man diese Aussage jetzt verstehen?

Setze doch einfach mal ein nop ein:

_loop1:  nop
         sbic PIND,1
         rjmp _loop1
         ...

und setze den Breakpoint auf "_loop1:  nop".
Dann PIND7 setzen oder löschen und sehen, was passiert.

MfG Spess

von Dirk B. (Gast)


Lesenswert?

spess53 schrieb:

> Setze doch einfach mal ein nop ein:
das dürfte Bernd Stein nach dessen vorigen Berichten vermutlich 
überfordern, da für Bernd S. "einige Fehler auch in dem " neueren " Buch 
( zusätzlich ATmega32 ) übernommen worden" die sich durch solche 
aufwändigen Maßnahmen 'beheben' ließen.

von Karl B. (gustav)


Lesenswert?

Hi,
das macht der Simulator.
Bei mir wird eine Reihe von rcalls nur der Reihe nach abgearbeitet, wenn
zwischen jedem rcall noch ein nop eingefügt wurde.
also statt
rcall portinit
rcall timerinit
rcall lcdinit

rcall portinit
nop
rcall timerinit
nop
rcall lcdinit

usw. usf.

Dann kann der Simulator keine Interruptereignisse wie INTO 
Flankentriggerung darstellen afaik. Jedenfalls wüsste ich nicht, wie das 
gehen sollte. Die Zeitschleifen bringen den Simulator regelmäßig zum 
Absturz. Stack overflow.

Im Simulator schaue ich mir die Käsekästchen an. Die Registerbits etc. 
etc.
Da wird das sehr anschaulich.

ciao
gustav

von spess53 (Gast)


Lesenswert?

Hi

>das macht der Simulator.
>Bei mir wird eine Reihe von rcalls nur der Reihe nach abgearbeitet, wenn
>zwischen jedem rcall noch ein nop eingefügt wurde.

????

MfG Spess

von Dieter F. (Gast)


Lesenswert?

spess53 schrieb:
> ????

So wie ich es kenne braucht der Simulator 1 Befehl, bis eine Änderung 
(z. B. an einem Port) wirksam wird (Farbumschlag des "Bits" von rot nach 
blau).

von Stefan F. (Gast)


Lesenswert?

Da gibt es noch einen ähnlichen "Haken" beim Lesen von Pins mit echter 
Hardware. Und zwar liest man immer den Pegel ein, der einen Takt vorher 
anlag.

Beispiel: Es soll getestet werden, ob zwei I/O Pins miteinander 
verbunden sind.
1
                _____
2
PB0 o------------   --------o PB1
3
Ausgang                       Eingang mit Pull-Up

So geht es daher nicht:
1
PORTB &= ~(1<<PB0);
2
if (PINB && (1<<PB1) == 0)
3
{
4
   PORTB |= (1<<PB0);
5
   if (PINB && (1<<PB1) > 0)
6
   {
7
      PORTB &= ~(1<<PB0);
8
      if (PINB && (1<<PB1) == 0)
9
      {
10
          printf("der Taster ist gerdückt.");
11
      }
12
   }
13
}

Man muss hinter die Ausgabe auf das PORT Register jeweils ein NOP 
einfügen.

von spess53 (Gast)


Lesenswert?

Hi

Das der Simulator kein 100%iges Abbild des realen AVRs ist sollte jedem 
klar sein. Aber irgendwelche imaginären NOP-Einfügungen würde ich ihm 
trotzdem nicht andichten,

MfG Spess

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

spess53 schrieb:
> Hi
>
>>Klar könnte ich den Breakpoint einen Befehl eher setzen ( *sts  LOW
>>(kopfz),xl* ), aber wenn ich das mache, wird dieser für mich auch
>>richtigerweise erst beim anklicken von Step Into ausgeführt und nicht
>>wie bei *sbic PIND,7* der schon ausgeführt wird, bevor ich Step Into
>>anklicke.
>
> Muss man diese Aussage jetzt verstehen?
>
Der Gelbe Pfeil sagt :"This is the next Statement that will be 
executed...".

Den Rest bin ich zu faul zu tippen und kann ihn auch ohne zu googeln gar 
nicht richtig übersetzen. Auf jeden Fall sagt mir dieser Satz, das der 
Befehl erst ausgeführt wird, wenn ich z.B. den Einzelschritt ( Step Into 
) ausführe.

>
> Setze doch einfach mal ein nop ein:
>
> _loop1:  nop
>          sbic PIND,1
>          rjmp _loop1
>          ...
>
> und setze den Breakpoint auf "_loop1:  nop".
> Dann PIND7 setzen oder löschen und sehen, was passiert.
>
Blöderweise das gleiche.
Also, ich starte mit dem grünen Play-Pfeil ( Start Debugging ), lande 
dann beim nop-Befehl ( Breakpoint ). Nun setze ich PIND7, klicke Step 
Into, lande beim Skip-Befehl, klicke Step Into und lande 
fälschlicherweise beim in-Befehl.

Frage mich natürlich warum ?

Nutze das ATMEL-Studio 7 Version 7.0.1645

Ach, habe dummerweise im Programm beim herumexperimentieren in Zeile 55 
( mov xh,xh ) geschrieben, muss richtigerweise *mov yh,xh* heißen.


Bernd_Stein

: Bearbeitet durch User
von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Karl B. schrieb:
> Hi,
> das macht der Simulator.
> Bei mir wird eine Reihe von rcalls nur der Reihe nach abgearbeitet, wenn
> zwischen jedem rcall noch ein nop eingefügt wurde.
> also statt
> rcall portinit
> rcall timerinit
> rcall lcdinit
>
Was passiert, wenn du es so läßt ?
Häng doch mal das Programm an, würd es auch gerne mal durch den Simu 
laufen lassen, dann versteh ich sicherlich besser, was du uns sagen 
willst.

Dieter F. schrieb:
> So wie ich es kenne braucht der Simulator 1 Befehl, bis eine Änderung
> (z. B. an einem Port) wirksam wird (Farbumschlag des "Bits" von rot nach
> blau).
>
Heißt dies, das ich 2x NOP einfügen muss, denn nach einem NOP lande ich 
ja bereits beim skip-Befehl, der dann leider falsch ausgeführt wird.

Beitrag "Re: Buch AVR von Günter Schmitt durcharbeiten"

Stefanus F. schrieb:
> Beispiel: Es soll getestet werden, ob zwei I/O Pins miteinander
> verbunden sind.
>
Für mich bitte in AVR-ASM, sonst kann ich das Programm schon mal gar 
nicht richtig interpretieren, da es mir in AVR-ASM schon schwer genug 
fällt.

spess53 schrieb:
> Hi
>
> Das der Simulator kein 100%iges Abbild des realen AVRs ist sollte jedem
> klar sein.
>
Ja schon, aber bei so einfachen INPUT / OUTPUT-Sachen erwarte ich das 
schon. Wenn nicht, dann ist da für mich noch ein Bug vorhanden.


Bernd_Stein

von Spess535hi (Gast)


Lesenswert?

Hi

Ich habe das bei mir getestet. Bei mir reagiert der Simulator egal, ob 
mit oder ohne dem nop richtig auf den Inhalt von PIND7 .

Mfg Spess

von Stefan F. (Gast)


Lesenswert?

Da gibt es noch einen ähnlichen "Haken" beim Lesen von Pins mit echter
Hardware. Und zwar liest man immer den Pegel ein, der einen Takt vorher
anlag. Beispiel: Es soll getestet werden, ob zwei I/O Pins miteinander
verbunden sind.

> Für mich bitte in AVR-ASM

Kann ich nicht auswendig, aber der folgende Pseudo-code sollte auch für 
Dich verständlich sein:
1
                _____
2
PB0 o------------   --------o PB1
3
Ausgang                       Eingang mit Pull-Up

So geht es daher nicht:
1
setze PB0 auf LOW
2
wenn PB1 = LOW ist, dann:
3
{
4
   setze PB0 auf HIGH
5
   wenn PB1 = HIGH ist, dann:
6
   {
7
      setze PB0 auf LOW
8
      wenn PB1 = LOW ist, dann:
9
      {
10
          melde: "der Taster ist gerdückt."
11
      }
12
   }
13
}

Man muss hinter die Ausgabe auf das PORT Register jeweils ein NOP
einfügen.

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Spess535hi schrieb:
> Ich habe das bei mir getestet. Bei mir reagiert der Simulator egal, ob
> mit oder ohne dem nop richtig auf den Inhalt von PIND7 .
>
> Mfg Spess

Yep,
habe vielleicht den falschen Haken gesetzt bei der Auswahl des 
Simulators.

ciao
gustav

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Karl B. schrieb:
> Spess535hi schrieb:
>> Ich habe das bei mir getestet. Bei mir reagiert der Simulator egal, ob
>> mit oder ohne dem nop richtig auf den Inhalt von PIND7 .
>>
>> Mfg Spess
>
> Yep,
> habe vielleicht den falschen Haken gesetzt bei der Auswahl des
> Simulators.
>
> ciao
> gustav
>
Pardon,
ich denke er hat mich gemeint. Spess scheint sich wohl einen Spaß mit 
mir zu machen, denn ich vermute ( Im Zusammenhang mit deinem Post ), das 
das Problem wohl daran liegt, das ich nicht die für 
Assemblerprogrammierung " beliebte " Version 4.xx des AVR-Studios nutze 
und ihr mir bewust oder unbewust, dieses klar machen wollt.

Ich habe wohl den AVR-Simulator 2 eingestellt. Weiß jedoch nicht, wie 
ich dies jetzt ändern kann. Erinnere mich leider auch nicht, ob ich bei 
der Projekterstellung dies expliziet gewählt hatte.

Stefanus F. schrieb:
> Kann ich nicht auswendig, aber der folgende Pseudo-code sollte auch für
> Dich verständlich sein:
>
Da es ja kein 1:1 AVR-ASM-Code ist, kann ich nicht genau erkennen, was 
dort Schritt für Schritt passiert. Vermute jedoch das dies alles korrekt 
so geschieht und im Zusammenhang der Synchronisation der Peripherie 
mit dem Systemtakt zu erklären ist.
Dies wird in Günter Schmitt seinem Buch unter Kapitel 4.3 ( Die 
Parallelschnittstellen ) auf der Seite 287 und 288 erwähnt.
Im Detail verstehe ich es jedoch auch noch nicht, da kein Diagramm oder 
ähnliches vorhanden ist.


Bernd_Stein

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Bernd S. schrieb:
> Spess scheint sich wohl einen Spaß mit
> mir zu machen, denn ich vermute ( Im Zusammenhang mit deinem Post ), das
> das Problem wohl daran liegt, das ich nicht die für
> Assemblerprogrammierung " beliebte " Version 4.xx des AVR-Studios nutze
> und ihr mir bewust oder unbewust, dieses klar machen wollt.
>
OK, danach sieht es jetzt nicht mehr aus. Habe die Version 4.19 Build 
370 des AVR-Studio's benutzt. Ich hatte das Glück nie mit einem NOP 
auszukommen ;-)
Deshalb hatte ich weiter geforscht und auch in Trampert's Buch Seite 307 
Kapitel 14.5 Die I/O-Module des Simulators diesen Satz gefunden :

" Die PORTS werden in der gleiche Weise sumuliert, wie sie sich im 
realen Controller verhalten würden. Auch die Verzögerung um 1,5 
Taktimpulse wie in der Standeard Port Logik wird nachgebildet. "

Hier kann man in deutsch etwas darüber erfahren :

http://www.ruhr-uni-bochum.de/nds/lehre/vorlesungen/eingebetteteprozessoren/ss05/io-Komponenten.pdf

Mir ist allerdings noch nicht klar, wie ich den SBIC-Befehl in dem 
Diagramm einordnen soll.


Warum beginnt tpd,max ( propagation delays ~ Auswirkungsverzögerung ) 
mit der fallenden Flanke und nicht mit der steigenden, die dass SYNC 
LATCH durchlässig macht ( schraffierter Bereich ) ?


Bernd_Stein

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Bernd S. schrieb:
> Warum beginnt tpd,max ( propagation delays ~ Auswirkungsverzögerung )
> mit der fallenden Flanke und nicht mit der steigenden, die dass SYNC
> LATCH durchlässig macht ( schraffierter Bereich ) ?
>
Ich erkläre mir das so :

" Es kann ja passieren, das das Signal gerade dann zur Verfügung steht, 
wenn der Systemtakt kurz zuvor seine fallende Flanke hatte. Zu diesem 
Zeitpunkt befindet sich SYNC LATCH im Speicherzustand und der aktuell 
anstehende Signalpegel wird nicht an das PINx-FlipFlop durchgereicht, 
sondern der vorher gespeicherte Signalpegel. Erst ab der schraffierten 
Fläche wird der Signalpegel erfasst und bei der fallenden 
Systemtaktflanke im SYNC LATCH gespeichert. Mit der steigenden 
Systemtaktflanke ( Takt für den IN-Befehl ) wird dieser Zustand auch im 
PINx-FF gespeichert. Nun wird mit der fallenden Systemtaktflanke ( ALU 
Operation ausführen ) der IN-Befehl abgearbeitet und steht mit dem 
nächsten Systemtakt im r17-Register zur Verfügung. "

Deshalb also die maximale Verzögerung von 1,5 Systemtakten.


Bernd_Stein

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Hier mal was schönes für die Jenigen, die genauso wie ich ihre 
Schwierigkeiten mit den englischen Datenbüchern zu den µ-Controllern 
haben.
Es ist eine deutsche Übersetzung zum ATmega8-Datenbuch :

http://modelleisenbahn-steuern.de/controller/atmega8/atmega8.htm


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Das ist nicht wirklich auf Deutsch übersetzt. Ich sehe da eine Fülle von 
Englischen Wörtern:

Timer, Counter, Interrupt, Software, Interface, Watchdog

An manchen Stellen wurden sie übersetzt, an anderen wieder nicht. Eine 
wirklich vollständige Übersetzung würde lustig aussehen, vielleicht 
sogar wieder unverständlich.

Ich denke, man kommt bei diesem Hobby heute einfach nicht mehr um 
Englisch herum. Selbst die zahlreichen Institute, die immer jüngere 
Kinder in die IT einführen wollen, haben damit Probleme (und die Kinder 
teilweise auch).

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Stefanus F. schrieb:
> Ich denke, man kommt bei diesem Hobby heute einfach nicht mehr um
> Englisch herum.
>
Hast in gewisser Weise recht. Aber es ist nunmal von Vorteil, wenn die 
englischen " Begriffe " wenigstens in der Muttersprache beschrieben bzw. 
umschrieben werden. Die Chinesen sehen es genauso :

( Siehe Anhang )

Bernd_Stein

von Cyblord -. (cyblord)


Lesenswert?

Stefanus F. schrieb:
> An manchen Stellen wurden sie übersetzt, an anderen wieder nicht. Eine
> wirklich vollständige Übersetzung würde lustig aussehen, vielleicht
> sogar wieder unverständlich.

Vielleicht ist gut.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

1
loop3:  
2
 st      X+,akku         ; 2 Takte zum Speichern noetig
3
 in      akku,PIND       ; 1 Takt um den neuen Zustand zu laden
4
        
5
 nop                     ; 1 Takt zur Verzögerung
6
7
 sbiw    zaehll,1        ; 2 Takte um den 16bit Zähler Zu dekrementieren
8
 brne    loop3           ; 2 Takte bei Sprung

Ich finde den NOP-Befehl unnötig, da die zur Synchronisation benötigte 
Zeit ( maximal 1,5 Takte ) die nötig ist um einen PORT-PIN einzulesen,
durch SBIW bereits gegeben ist und durch die nachfolgenden Befehle ( 
BRNE & ST ) erst recht.


Bernd_Stein

von Mönch (Gast)


Lesenswert?

Bernd S. schrieb:
> Ich finde den NOP-Befehl unnötig, da die zur Synchronisation benötigte

Ich auch. Von Synchronisation ist dort gar nicht die Rede.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Mönch schrieb:
> Von Synchronisation ist dort gar nicht die Rede.
>
Damit du den Zusammenhang verstehst solltest du hier noch mal kurz 
nachlesen :

Beitrag "Re: Buch AVR von Günter Schmitt durcharbeiten"


Bernd_Stein

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Wie in der Überschrift zu lesen, geht es um die Adressierung der 
Variablen im SRAM ( Kapitel 2.5.2 ). Dort wird auch die *indirekte 
Adressierung* mit Post-Increment vorgestellt. Im folgenden 
Programmausschnitt ( k2p9.asm ) wird davon allerdings kein Gebrauch 
gemacht, obwohl dies den ADIW-Befehl vermeiden würde und somit ein Word 
und zwei oder drei Takte eingespart werden könnten.

Obwohl mir die Buchreihe von Manfred Schwabel-Schmidt zu undurchsichtig 
ist, stimme ich seiner Aussage zu der Assemblerprogrammierung voll zu.

In etwa meint er, es geht in der Asssemblerprogrammierung darum ein 
bestmögliches Maschinenprgramm, zu dem jeweiligen Gerät zu erstellen, 
denn dies ist halt der Vorteil der Assemblerprogrammierung und dazu ist 
jedes unkonventionelle Vorgehen erlaubt und erwünscht.

Es sind halt die einzigsten Vorteile der ASM-Programmierung, dass man 
hiermit die schnellsten und speichersparensten Programme schreiben kann 
und dies sollte im Vordergrund der ASM-Programmierung auch gelehrt 
werden, sonst macht es keinen Sinn in ASM zu programmieren.

Zwei oder drei Takte deshalb, weil das Instruction Set Summmary zum 
ATmega16 und auch zum Atmega8 zwei Takte sagt und das Instruction Set 
Manual 1 Takt.

Der Simu des AS7 macht bei eingestelltem ATmega8 übrigens 2 Takte, wie 
es im Instruction Set Summary seines Datenbuches steht.
1
_loop1:
2
 lpm                            ;r0 mit dem Inhalt, der durch Z..
3
                                ;...angegebenen Flashadresse laden..
4
                                ;..ICH WÜRDE lpm r0,z+ SCHREIBEN
5
 tst  r0                        ;Endmarke Null?..
6
 breq _lab1                     ;..Ja -> Fertig 
7
 cpi  zaehl,anz+1               ;Ansonsten Max. Listenlänge erreicht?
8
 brsh _lab1                     ;Ja -> ebenfalls Fertig
9
 st   x+,r0                     ;Das jeweilige Flash-Byte ins SRAM..
10
                                ;..kopieren & danach die SRAM-Adresse.. 
11
                                ;..um eins erhöhen
12
 adiw ZH:ZL,1                   ;Flash-Adresse um eins erhöhen
13
                                ;KANN MAN DURCH OBEN lpm r0,z+ SPAREN
14
 inc  zaehl                     ;Listenelementezähler um eins erhöhen
15
 rjmp _loop1                    ;Zum Schleifenanfang springen


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Wie in der Überschrift zu lesen, geht es um die Adressierung der
> Variablen im SRAM

Wie lautet deine Frage?

Zu deiner Meinungsäußerung:

> Es sind halt die einzigsten Vorteile der ASM-Programmierung, dass man
> hiermit die schnellsten und speichersparensten Programme schreiben
> kann und dies sollte im Vordergrund der ASM-Programmierung auch
> gelehrt werden, sonst macht es keinen Sinn in ASM zu programmieren.

Du hast damit einen Vorteil genannt, aber nicht den einzigen. Ich 
ergänze mal, was mir dazu einfällt:

- In Assembler kann man die Funktionsweise der CPU besser nachvollziehen 
und kennen lernen.
- In Assembler kann man einige Dinge tun, die in andere Sprachen 
unmöglich sind. Deswegen enthält praktisch jedes RTOS wenigstens ein 
bisschen Assembler Code im Task-Switcher.
- Wenn ein Hochsprachen-Programm (z.B. in C) mal nicht das tut, was es 
soll, hilft manchmal ein Blick in den generierten Maschinencode 
(Assembler), um eine Lösung zu finden.

Insofern würde ich Assembler nicht als Haupt-Programmiersprache 
einsetzen, aber ein bisschen davon sollte man beherrschen, wenn man sich 
Profi nennen will. Ich finde Assembler-Kenntnisse sogar für mein Hobby 
sehr hilfreich.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Leider konnte ich dies nicht unter bearbeiten noch hinzufügen, da die 
Zeit abgelaufen ist.

Ein weiterer Vorteil von *lpm Rd,z+* kam mir ins Gedächnis.
Hiermit ist man frei in der Auswahl des Arbeitsregisters ( General 
Purpose Register ( GPR ) r0 - r31 ).


Bernd_Stein

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Stefanus F. schrieb:
> Wie lautet deine Frage?
>
Es muss ja nicht immer eine Frage sein.
Es darf ja auch eine Meinung oder Sichtweise vertreten werden über die 
man diskutieren kann.

>
> - Wenn ein Hochsprachen-Programm (z.B. in C) mal nicht das tut, was es
> soll, hilft manchmal ein Blick in den generierten Maschinencode
> (Assembler), um eine Lösung zu finden.
>
Ich will jetzt nicht klugscheissen, aber dennoch eine Unterscheidung 
zwischen Assembler und Maschinencode darstellen, wobei bedacht 
werden muss, dass es bei dem Ausdruck ASSEMBLER einmal um das 
"Assembler-Übersetzungsprogramm" gehen kann und zum Anderen um die 
Programmiersprache, was ich jetzt meine.

Das du das weisst ist mir bekannt, aber ich schreibe halt für alle die 
hier mitlesen.

Das ist Asssembler ( Programmiersprache )    : NOP

und dies Maschinencode                       : 0000 0000 0000 0000

Deshalb hat man den Assembler erschaffen um nicht für uns Menschen diese 
Binärcodes bzw. Hexadezimalzahlen als Programm schreiben zu müssen.

Bernd_Stein

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
>> Wie lautet deine Frage?
> Es muss ja nicht immer eine Frage sein.
> Es darf ja auch eine Meinung oder Sichtweise vertreten

Natürlich, ich dachte nur, dass du die Frage vergessen hättest. Kommt ab 
und zu mal vor.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Stefanus F. schrieb:
> Natürlich, ich dachte nur, dass du die Frage vergessen hättest. Kommt ab
> und zu mal vor.
>
Im Moment habe ich keine direkten oder konkreten Fragen, aber viele 
Verständnisprobleme, also mich in die Gedanken bzw. Absichten des 
jeweiligen Programmierers hinein zu versetzen...

Ach und noch was. Habe wohl nicht wirklich den Sinn dieser beiden Zeilen 
verstanden, sonst hätte ich nicht: " Ja -> ebenfalls fertig " 
geschrieben, nur weil zum selben Label gesprungen wird.

Der Orginaltext lautet nämlich " max. Listenlänge? -> Ja: abbrechen ".

Denn der eigentliche Sinn ist bestimmt einen Fehlerfall damit zu 
erkennen.
Stelle mir vor, das in einem bestimmten Bereich Texte abgelegt werden 
und wenn dieser Bereich verlassen wird, soll dies erkannt und evtl. 
gemeldet werden, was zwar nicht das Thema dieses Kapitels ist aber wohl 
durch Copy und Paste einfach in dieses Kapitel verfrachtet wurde.
1
 cpi  zaehl,anz+1               ;Ansonsten Max. Listenlänge erreicht?
2
 brsh _lab1                     ;Ja -> ebenfalls Fertig


Bernd_Stein

: Bearbeitet durch User
von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Echt ärgerlich das der Simulator so schlecht programmiert wurde.

Günter Schmitt, Wolfgang Trampert lassen sich darüber ( Little oder Big 
Endian ) gar nicht aus und Manfred Schwabel-Schmidt schreibt das alle 
AVR-µC  Little Endian orientiert sind.

Der Simulator macht es im Memoryfenster : pro FLASH, fast richtig und in 
der .lss-Datei auch nur fast richtig.

Damit meine ich im Memoryfenster dürfen die Adressen nicht Byteweise 
angezeigt werden, auch wenn man darauf Byteweise zugreifen kann, denn 
der FLASH-Speicher ist Wordweise organisiert und an der Adresse $0000, 
ist nunmal $29C0 abgelegt und in Adresse $0001 und folgenden halt $FFFF. 
Außerdem werden die Befehle ab $002A gar nicht mehr dargestellt.

Die .lss-Datei zeigt zwar richtig in jeder Adresse Wordweise an, dreht 
aber die Bytes nicht für little endian.


Bernd_Stein

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Im SRAM bzw. in den Spezial Funktions Registern ( SFR ) auch 
I/O-Register genannt, kann man dann doch anhand der 
Stackpointer-Initialisierung sehen, das AVR8-µC Little Endian verwenden 
( siehe Screenshot AVR8_ist... )

Das gehört noch zum oberen Posting lies sich aber wegen einem Fehler 
nicht mehr unter bearbeiten mit einfügen.


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
> kann man dann doch anhand der Stackpointer-Initialisierung sehen

Little-Endian ist ja nicht falsch, aber was hat das mit der Stackpointer 
Initialisierung zu tun, woran glaubst du, es dort erkennen zu können?

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Stefanus F. schrieb:
> Little-Endian ist ja nicht falsch, aber was hat das mit der Stackpointer
> Initialisierung zu tun, woran glaubst du, es dort erkennen zu können?
>
Weil beim ATmega8 der 16-Bit Stackpointer an den Adressen $3D ( SPL )
&
$3E ( SPH ) liegt, RAMEMD $045F beinhaltet und ...

Danke der Nachfrage.

Ist natürlich quatsch, weil LOW(RAMEND) explizit in SPL und und 
High(RAMEND) in SPH geschrieben wird.

Baue jetzt mal eine kleine Breadboard-Schaltung mit dem ATmega88PA auf, 
um zu überprüfen, ob nun LE oder BE bei den AVR8-µC herrscht.


Bernd_Stein

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Bernd S. schrieb:

> Echt ärgerlich das der Simulator so schlecht programmiert wurde.

Was den MCU-Core betrifft, ist er das nicht. Das passt schon. Die 
Peripherie hingegen ist irgendwas zwischen "geht so" und "vollkommen 
untauglich" emuliert. Soweit überhaupt unterstützt...

> Günter Schmitt, Wolfgang Trampert lassen sich darüber ( Little oder Big
> Endian ) gar nicht aus und Manfred Schwabel-Schmidt schreibt das alle
> AVR-µC  Little Endian orientiert sind.

Mein Gott. Der AVR8 ist ein 8Bit-µc. Dementsprechend gibt es für ihn das 
Problem der "endianess" eigentlich überhaupt nicht. Es kommt maximal an 
zwei Punkten überhaupt zum Tragen:

1) Bei den Register-Paaren. Also R1:R0 bei den *mul-Instruktionen und 
alles
   ab R24 aufwärts. Das ist im Register-Adressbereich eindeutig
   little-endian.
2) Im Registerfile, also dem Mapping der Register in den SRAM-Bereich.
   Ebenfalls eindeutig little-endian.

Das war's.

> Damit meine ich im Memoryfenster dürfen die Adressen nicht Byteweise
> angezeigt werden, auch wenn man darauf Byteweise zugreifen kann, denn
> der FLASH-Speicher ist Wordweise organisiert und an der Adresse $0000

Genau deswegen wählt man einfach die Ansicht "Programm memory". Da kann 
man dann noch wählen, ob man es byteweise oder wordweise sehen möchte.

Mein Gott, wenn du nach fast ZEHN *JAHREN* im Thema immer noch 
derartige Probleme hast, such' die besser ein anderes Hobby, das hier 
ist dann ganz offensichtlich nix, wofür du intellektuell hinreichend 
ausgestattet bist...

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

c-hater schrieb:
> Genau deswegen wählt man einfach die Ansicht "Programm memory". Da kann
> man dann noch wählen, ob man es byteweise oder wordweise sehen möchte.
>
Und wie macht man das im AS7?

Ich halte Manfred Schwabel-Schmidt anhand seiner Buchreihe, die ich zwar 
nicht verstehe, für sehr kompetent in AVR8ASM und für ihn ist LE & BE 
schon ein Thema. Die anderen beiden Buchautoren natürlich auch.

Aber ob ein c-hater da mithalten kann, weiß ich nicht zu beurteilen.


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Aber ob ein c-hater da mithalten kann, weiß ich nicht zu beurteilen.

Er mag sich schlecht benehmen, aber ein Dummkopf ist er nicht. Ganz 
besonders nicht im Assembler Umfeld.

von c-hater (Gast)


Lesenswert?

Bernd S. schrieb:

> Und wie macht man das im AS7?

Das ist einfach: Wenn du Assembler programmieren willst, benutzt du nach 
Möglichkeit nicht AS7. Das hilft dir dabei nämlich in keinster Weise.

Nur, dann, wenn das Target vom ollen Studio4 nicht mehr unterstützt 
wird, gibt es auch für Assemblerprogrammierer einen wirklichen Grund, 
auf AS7 zu wechseln.

Man sollte bloß keine zu großen Erwartungen haben. Das AS7 ist schlicht 
Scheisse. Das war das Studio4 zwar auch schon, aber über die vielen 
Jahre hinweg konnte man die ganzen Bugs sammeln und meist auch irgendwie 
umgehen.

Könnte man beim AS7 genauso handhaben, aber der Aufwand lohnt wohl nicht 
mehr. Offensichtlich will MC das AS zumindest mittelfristig komplett 
beerdigen.

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Hi,
finde den Link nicht.
Aber glaube, da gab es 'mal eine App Note für.
"Sorry Titel nicht mehr lieferbar."
Hab noch Screenshot von den hier relevanten Seiten 12 und 13.
"Little Endian" "Wait a minute, that looks backward..."

ciao
gustav

: Bearbeitet durch User
von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Wieder so etwas für mich unverständliches.

Im Programm ist zu sehen, das ich mir die Inhalte der FLASH-Ardressen ab 
$0000 ansehen möchte.

An $0000 steht rjmp _start.
rjmp hat im Opcode dann irgendwas mit $Cx xx.

Warum wird jetzt der Inhalt von Adresse $0000 mit $98 95 angezeigt?

Kennt jemand eine Funktion im AS7 die mir aus einer Hex-Datei den 
Assemblercode wiedergibt, damit ich entschlüsseln kann was $9895 als 
Assemblercode ergibt?


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Schau nochmal genau hin, welchen Adressbereich eine RAM Ansicht gerade 
anzeigt.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Stefanus F. schrieb:
> Schau nochmal genau hin, welchen Adressbereich eine RAM Ansicht gerade
> anzeigt.
>
Genau den, den es anzeigen soll. ;-)

Ich verwende den ATmega88PA und dessen internes SRAM beginnt ab 
Adresse $0100.

Ab *SRAM-Adresse $0101* werden die Inhalte der *FLASH-Adressen ab $0000* 
kopiert.

Ich erkenn also immer noch nicht, worauf du mich mit der Nase stossen 
möchtest.

Bernd_Stein

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Bernd S. schrieb:
> Kennt jemand eine Funktion im AS7 die mir aus einer Hex-Datei den
> Assemblercode wiedergibt, damit ich entschlüsseln kann was $9895 als
> Assemblercode ergibt?

Hi,
Disassembling geht bei mir so.
1. Mache ein Projekt auf
2. Create Initial File
3. Wähle Target aus Liste
4. Wähle im Menü "open File" und klicke auf das zu disassemblierende 
Hex-File.
Dann Speicher unter Name "Disassembler"
Das Debuggen nicht schließen, bevor nicht gespeichert.
Projektdaten wieder löschen. (In *.asm sind dann sowieso nur Null Byte 
drin.)

Dann kommen die Befehle mit Beschreibung allerdings ohne erläuternde 
Kommentare oder Labels. Siehe angehängtes Bild. Ist schon 
zeilenumbruchmäßig in Word bearbeitet worden.
Registernamen in Hex. Ebenso die Konstanten, die sonst gerne so 
aussehen:

ldi   temp, (1<<WGM12)+(1<<CS10)
sts   TCCR1B,   temp

Muss man anhand des Debuggers herausfinden oder aus dem Datenblatt.
Ist Studio 4.
In Studio 7 gibt es das bestimmt auch, mal durchklickern...
Wenn nicht, dann mach es wie ich, ich hatte 7-er Version und wieder 
downgegradet auf 4. Mir reicht die 4-er Version vollauf.

ciao
gustav

: Bearbeitet durch User
von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)



Lesenswert?

Karl B. schrieb:
> Hi,
> Disassembling geht bei mir so.
> 1. Mache ein Projekt auf
> 2. Create Initial File
> 3. Wähle Target aus Liste
> 4. Wähle im Menü "open File" und klicke auf das zu disassemblierende
> Hex-File.
> Dann Speicher unter Name "Disassembler"
> Das Debuggen nicht schließen, bevor nicht gespeichert.
> Projektdaten wieder löschen. (In *.asm sind dann sowieso nur Null Byte
> drin.)
>
Auch Hi,

habe dir über µC.net eine eMail zu einem anderen Thema zukommen lassen.

Jetzt aber zum Dissamblieren einer Hex-Datei.

Ich denke ich habe alle Schritte mit dem von AS7 erzeugten Code der 
automatisch nach Anlegen eines Projekts erstellt wird, gemacht.

Bis auf Projektdaten wieder löschen.

Wie geht das?

Bernd_Stein

von Karl B. (gustav)


Lesenswert?

Hi,
Email wäre garnicht nötig gewesen:
Antwort:
Die Bildschirmausdrucke stammen von der Studio 4.18- Version.

Habe nämlich oben noch ein Edit in den Post oben reingemacht.

Karl B. schrieb:
> Ist Studio 4.
> In Studio 7 gibt es das bestimmt auch, mal durchklickern...
> Wenn nicht, dann mach es wie ich, ich hatte 7-er Version und wieder
> downgegradet auf 4. Mir reicht die 4-er Version vollauf.

Bernd S. schrieb:
> Ich denke ich habe alle Schritte mit dem von AS7 erzeugten Code der
> automatisch nach Anlegen eines Projekts erstellt wird, gemacht.
>
> Bis auf Projektdaten wieder löschen.

Das geht so, dass normalerweise ja ein Fenster aufgeht für den asm-Code 
Editor.
Wenn man stattdessen im Dateimenü (links) auf open File geht, wird der 
Disassembler gestartet, sofern das System eine Hex-Datei auf demselben 
Laufwerkspfad vorfindet.
Dann geht automatisch der "Disassembler"-Fenster auf.
(Eventuell vorher noch eine Targetabfrage. Bestätigen... ist grau 
unterlegt.)
Und oben links der Pfeil zum Debugger.
Jetzt nicht den Fehler machen und Projekt speichern, sondern
im Dateimenü "save as".
Dann wird der Dateiname "Disassembler" ohne Erweiterung automatisch 
angelegt. Kann man mit Word oder irgendeinem Texteditor öffnen.

Das war's.

ciao
gustav

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

*Hat sich erledigt.*
*Ein unscheinbarer Button ist zu klicken ( siehe ScreenShot Button )*


Bernd_Stein

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Ab *SRAM-Adresse $0101* werden die Inhalte der *FLASH-Adressen ab $0000*
> kopiert.

Der Versatz der Adressen war mir entgangen. Interessante Sache, ich 
probiere das mal aus und melde mich dann wieder.

von Stefan F. (Gast)


Angehängte Dateien:

Lesenswert?

Also, bei mir klappt es wie erwartet im Simulator, siehe Screenshot.

In R0 wollte ich das erste Byte vom Flash sehen, und in R1 das zweite. 
Was auch der Fall ist.

Mir fällt dazu etwas ein, aber damit bewege ich mich auf unsicheres 
Terrain:

Bei den echten AVR überschreibt der Debugger einzelne Flash Zellen, um 
Haltepunkte zu setzen. Und der erste Haltepunkt ist immer die erste 
Programmzeile.

Diese BREAK Anweisung hat den Opcode 0x9598

Siehe dazu auch: 
https://electronics.stackexchange.com/questions/114957/avr-atmega-breakpoints-and-break-instruction

Kann das bei Dir die Ursache des Effektes sein?

von Stefan F. (Gast)


Lesenswert?

Bernd, bist du noch da? Du darfst dich gerne bedanken, das täte und 
beiden gut.

Immerhin habe ich für dich diesen Sommer zum ersten mal das besch**** 
Windows gestartet und die unvermeidliche Update-Orgie ertragen.

von Johann J. (johannjohanson)


Lesenswert?

Stefanus F. schrieb:
> Immerhin habe ich für dich diesen Sommer zum ersten mal das besch****
> Windows gestartet und die unvermeidliche Update-Orgie ertragen.

Du tust mir wirklich leid. Eine Runde Mitleid für Stefan (mit dem 
Helfer-Syndrom) - bitte.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Angehängte Dateien:

Lesenswert?

Stefanus F. schrieb:
> Mir fällt dazu etwas ein, aber damit bewege ich mich auf unsicheres
> Terrain:
>
> Bei den echten AVR überschreibt der Debugger einzelne Flash Zellen, um
> Haltepunkte zu setzen. Und der erste Haltepunkt ist immer die erste
> Programmzeile.
>
> Diese BREAK Anweisung hat den Opcode 0x9598
>
> Siehe dazu auch:
> 
https://electronics.stackexchange.com/questions/114957/avr-atmega-breakpoints-and-break-instruction
>
> Kann das bei Dir die Ursache des Effektes sein?
>
Jetzt bin ich wieder da und ich muss mich wirklich bei dir bedanken, 
denn ohne deine Mühe die du dir gegeben hast, wäre dies sicherlich ein 
weiteres ungelöstes Rätsel der AVR8-Asssemblerprogrammierung bei mir 
geworden.

Ich habe nämlich wirklich mit der DebugWire-Funktion gearbeitet, weil 
ich mir Hardwaremäßig auf 8 LED's und 2 Siebensegmentanzeigen, den 
Inhalt der Flashadressen ab $0000, welche ins SRAM ab Adresse $0101 
kopiert wurden, darauf habe anzeigen lassen.

Es zeigt jetzt aber auch deutlich, dass auch der Programmspeicher ( 
FLASH ) little Endian organisiert ist, was noch zu c-haters Aussage zu 
ergänzen ist.


c-hater schrieb:
> Mein Gott. Der AVR8 ist ein 8Bit-µc. Dementsprechend gibt es für ihn das
> Problem der "endianess" eigentlich überhaupt nicht. Es kommt maximal an
> zwei Punkten überhaupt zum Tragen:
>
> 1) Bei den Register-Paaren. Also R1:R0 bei den *mul-Instruktionen und
> alles
>    ab R24 aufwärts. Das ist im Register-Adressbereich eindeutig
>    little-endian.
> 2) Im Registerfile, also dem Mapping der Register in den SRAM-Bereich.
>    Ebenfalls eindeutig little-endian.
>
> Das war's.
>


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Es zeigt jetzt aber auch deutlich, dass auch der Programmspeicher (
> FLASH ) little Endian organisiert ist

Naja, das hätte ich Dir auch ohne Experiment bestätigen können.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Bernd S. schrieb:
> Ich halte Manfred Schwabel-Schmidt anhand seiner Buchreihe, die ich zwar
> nicht verstehe, für sehr kompetent in AVR8ASM und ...
>
Hier mal seine Homepage mit Programmdownloads zu seinen Büchern :

http://web.archive.org/web/20131126231432/http://schwabl-schmidt.de/index.php/download


Bernd_Stein

: Bearbeitet durch User
von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Hallo zusammen,

arbeite sporadisch die 6te Auflage durch.
Seite 67, Kapitel 2.3.4  Operationen mit SF-Registern.

Frage mich was bei den Port-Bit-Befehlen zur besonderen Vorsicht 
beiträgt, was nicht auch für die Port-Byte-Befehle gelten sollte ?

Beide Arten führen doch Lese,- und Schreiboperationen durch.


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Frage mich was bei den Port-Bit-Befehlen zur besonderen Vorsicht
> beiträgt, was nicht auch für die Port-Byte-Befehle gelten sollte ?

Formuliere die Frage nochmal so, dass man dich verstehen kann und 
zitiere ggf. den Text der für das Verständnis nötig ist.

Um welche "Vorsicht" geht es und wert trägt warum dazu bei?

von Karl B. (gustav)


Lesenswert?

Hi,
falls das des Rätsels Lösung ist:
Zitat:
"...die Pseudobefehle cbr und sbr löschen bzw. setzen Bits in einem 
Arbeitsregister. Sie adressieren keine Bitpositionen wie sbi und cbi, 
sondern enthalten konstante Masken., die mit einer 1 die zu verändernde 
Bitposition angeben..."

"...Bitoperationen in nicht bitadressierbaren SFR-Registern müssen mit 
logischen Masken in Arbeitsregistern durchgeführt werden..."
/Zitat
Quelle:
4. Auflage
ISBN 978-3-486-58790-6
Seite 79

Vielleicht erst einmal weiter hinten im Buch die Beispiele anschauen.
Etwas zum Lieferumfang gehörenden downloadbaren Zusatzprogramme hatte 
ich Dir schon vor Jahren einmal gemailt.
Im Moment hier nicht greifbar.
"...9   Ergänzungen
Dieses Dokument enthält Programme und Texte, die in der zweiten Auflage 
gekürzt wurden oder ganz entfallen sind, aber nicht verloren gehen 
sollten..."

ciao
gustav

: Bearbeitet durch User
von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

@Stefan F. & @Karl B.

Da ihr beide diese Auflage nicht habt, ist es zu mühselig darauf 
einzugehen,
denn die 6te Auflage, will mir vielleicht noch einen anderen Hinweis 
geben, als dies in der 4ten Auflage mit den Pseudobefehlen ( SBR & CBR ) 
und den Hinweis hierzu : " Nur auf Arbeitsregister und zudem noch >= R16 
anwendbar ", gegeben hat.

@Karl B.
Damals hatte ich "nur" die ASM & C-Programme zu dem Buch von dir 
erhalten.
Die Texte und Programme die wohl noch zur 2ten Auflage zu Kapitel 9 
Ergänzungen gehörten, habe ich nicht.


Bernd_Stein

von Stefan F. (Gast)


Lesenswert?

Warm fragst du eigentlich immer uns was der Autor sich bei bestimmten 
Sachen gedacht hat? Frage ihn doch besser!

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Stefan ⛄ F. schrieb:
> Warm fragst du eigentlich immer uns was der Autor sich bei
> bestimmten
> Sachen gedacht hat? Frage ihn doch besser!
>
Vielleicht hat es ja ein Anderer verstanden und kann es mir wiederum 
verständlich machen. Dafür ist doch auch ein Forum da oder ?

Übrigens der eine ist schon tod und der Andere hat anderes zu tun ;-)


Bernd_Stein

von c-hater (Gast)


Lesenswert?

Bernd S. schrieb:

> Frage mich was bei den Port-Bit-Befehlen zur besonderen Vorsicht
> beiträgt, was nicht auch für die Port-Byte-Befehle gelten sollte ?

Bezüglich des RMW-Zugriffs auf (zumindest einige) SFIORs ist das 
tatsächlich gleichermaßen kritisch. Aber für den Rest der SFIORs ist 
cbi/sbi sicher.

Es kommt dabei darauf an, ob der Inhalt eines SFIOR auch durch die 
Hardware alleine geändert werden oder nur in Folge von Schreibzugriffen 
der MCU.

Im ersteren Fall sind beide Varianten unsicher, weil sich der Inhalt des 
SFIOR zwischen Lese- und Schreibzugriff allein durch die Wirkung der 
Hardware ändern kann.

Im zweiten Fall sind cbi/sbi sicher, weil kein anderer Schreibzugriff 
auf das SFIOR während der Laufzeit der Instruktionen erfolgen kann.

Man kann das auch so ausdrücken: bezüglich der MCU sind cbi/sbi atomar, 
aber nicht bezüglich der Hardware. Folgen aus "in/log. operation/out" 
sind niemals atomar, weder bezüglich der MCU noch bezüglich der 
Hardware. Maximal kann man sie bezüglich der MCU atomar machen, indem 
man sie in einen Rahmen mit Interruptsperre verpackt (oder innerhalb 
einer bereits bestehenden ausführt, also typisch innerhalb einer 
"normalen" ISR).

von Stefan F. (Gast)


Lesenswert?

Bernd S. schrieb:
> Vielleicht hat es ja ein Anderer verstanden und kann es mir wiederum
> verständlich machen. Dafür ist doch auch ein Forum da oder ?

Ich habe allerdings schon da Gefühl dass die meisten Autoren (jeden die 
ich kontaktierte) sich über Rückfragen freuen.

> Übrigens der eine ist schon tod und der Andere hat anderes zu tun ;-)

Ok, dann kannst du sie nicht mehr fragen.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

c-hater schrieb:
> Man kann das auch so ausdrücken: bezüglich der MCU sind cbi/sbi atomar,
> aber nicht bezüglich der Hardware. Folgen aus "in/log. operation/out"
> sind niemals atomar, weder bezüglich der MCU noch bezüglich der
> Hardware. Maximal kann man sie bezüglich der MCU atomar machen, indem
> man sie in einen Rahmen mit Interruptsperre verpackt (oder innerhalb
> einer bereits bestehenden ausführt, also typisch innerhalb einer
> "normalen" ISR).
>
Interessanter Denkanstoß.


Bernd_Stein

von Hugo H. (hugo_hu)


Lesenswert?

Bernd S. schrieb:
> Übrigens der eine ist schon tod

Kennst Du den Sensenmann?

Bernd S. schrieb:
> Vielleicht hat es ja ein Anderer verstanden und kann es mir wiederum
> verständlich machen. Dafür ist doch auch ein Forum da oder ?

Das geht jetzt seit 2010 in dieser Weise - wie wäre es mit Häkeln oder 
so? Das ist nicht böse gemeint, aber mir scheint das ist nicht Deine 
Welt.

von Karl B. (gustav)


Lesenswert?

Hi,
eine ausführilche Flowchart, wie Befehle in der Praxis abgearbeitet 
werden, wäre hilfreich.
Wir haben es ja bei den AVRs nicht mit asymmetrischer Clock-Erzeugung,
Maschinenzyklus etc. wie bei den 80xx µPs (nicht Controller!)zu tun, 
sondern mit der "direkt" durch die Architektur vorgegebene 
Takt-für-Takt-Abarbeitung.
Aber da können Störungen hineinkommen, die entweder von der 
"Architektur" herrühren, oder vom Programm. bzw. den Befehlen (Opcodes) 
selbst.
Und Unterscheidung von 8- und 16-Bit-Verarbeitung erfolgte schon bei den 
80xx µPs gelatched. Highbyte/Lowbyte.
Oder sogar Adressenlatch noch. Wer weiß alles noch dazwischen, kann man 
garnicht aufzählen.
In dieser "Lücke" will TO ein wenig rumstochern. So wie ich ihn 
verstanden habe. Da muss man eben etwas tiefer in die Architektonik 
reinschnuppern.
(Zufällige Stichworte: Little Endian; Big Endian und die mysteriöse 
indirekte Adressierung. Wo genau wird nun was ins SRAM geschrieben bei 
den Arrays...etc. pp.?)

ciao
gustav

von c-hater (Gast)


Lesenswert?

Karl B. schrieb:

> (Zufällige Stichworte: Little Endian; Big Endian und die mysteriöse
> indirekte Adressierung.

Nomen est omen...

Tatsächlich hat nichts von diesen Stichworten auch nur andeutungsweise 
irgendetwas mit dem Problem zu schaffen, um das es hier zuletzt ging.

von Jan (Gast)


Lesenswert?

Ist heute wieder Bullshit-Bingo angesagt? Wie kann man nur über sowas 
banales wie sbi/cbi so viel schreiben. Warum nicht gleich ein Buch über 
mov?

Und natürlich sind sbi/cbi atomar, genau wie jeder andere 
Assembler-Befehl auch. Ihr habt überhaupt nichts verstanden. Hauptsache 
hochgestochen herumschwurbeln.

von c-hater (Gast)


Lesenswert?

Jan schrieb:

> Und natürlich sind sbi/cbi atomar

Sind sie eben nicht. Nicht bezüglich der Peripherie, nur bezüglich der 
MCU.

> Ihr habt überhaupt nichts verstanden.

Du hast überhaupt nix verstanden.

von Hannes (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Warm fragst du eigentlich immer uns was der Autor sich bei bestimmten
> Sachen gedacht hat? Frage ihn doch besser!

Glaubst Du wirklich, ein ‚Bernd_Stein‘ würde seit 11 1/2 Jahren immer am 
gleichen Buch rumlesen? Für mich ist das noch nicht Mal „trollen“ - 
vielmehr der Versuch, die Werbetrommel für zweifelhafte 
Druck-Erzeugnisse zu rühren.

Weit kann‘s damit ja nicht her sein, sonst würde nicht ein und derselbe 
Fragesteller immer wieder auftauchen mit „ich hab‘s nicht verstanden - 
vielleicht kann es mir ein Anderer verständlich machen ...“.

von Stefan F. (Gast)


Lesenswert?

Naja, ich bekomme (hier und per Email) auch ab und zu mal Rückfragen zu 
meinen PDF. Meistens führen sie zu einer Fehlerkorrektur oder dazu, dass 
ich einen Absatz im Sinne besserer Verständlichkeit überarbeite.

Als Autor habe ich durchaus Interesse daran, dass das Buch gut ist - 
egal wie alt es ist.

von Oliver S. (oliverso)


Lesenswert?

c-hater schrieb:
> Jan schrieb:
>
>> Und natürlich sind sbi/cbi atomar
>
> Sind sie eben nicht. Nicht bezüglich der Peripherie, nur bezüglich der
> MCU.

Es gibt ein paar Steinzeit-AVRs (Mega8, etc.), bei denen sbi/cbi über 
ein read/modify/write auf das ganze Register ausgeführt werden. Bei 
allen neueren wird atomar das jeweilige Bit geschrieben, sonst nichts.

Oliver

: Bearbeitet durch User
von Georg M. (g_m)


Angehängte Dateien:

Lesenswert?

Oliver S. schrieb:
> Es gibt ein paar Steinzeit-AVRs

von Stefan F. (Gast)


Lesenswert?

Georg M. schrieb:
> Oliver S. schrieb:
> Atmega328P abgekündigt

Wow! Das ist eine Überraschung.

Keine Sorge, den werden die Chinesen ggf. nachbauen, wenn sie es nicht 
schon längst tun.

von Oliver S. (oliverso)


Lesenswert?

Stefan ⛄ F. schrieb:
> Georg M. schrieb:
>> Oliver S. schrieb:
>> Atmega328P abgekündigt
>
> Wow! Das ist eine Überraschung.

Na ja, schrub ich zwar nicht, aber abgekündigt ist nur der „328P“. Die 
anderen 328er gibts noch. Da muß der Chinese noch nicht aktiv werden.

Oliver

von Karl B. (gustav)


Lesenswert?

c-hater schrieb:
> Tatsächlich hat nichts von diesen Stichworten auch nur andeutungsweise
> irgendetwas mit dem Problem zu schaffen, um das es hier zuletzt ging.

Die Simulatoren dder "Debugger" veranschalichen,
was bei der Befehlsabarbeitung passiert.
Aber eben nicht so detailliert, wie Du das gerne haben möchtest.
sonst hätte sich Dein Problem ganz easy erledigt.
Die anderen Sachen, die ich oben erwähnte, sind nämlich gedanklich auf 
derselben Ebene:
Wo schreibt der AVR die Daten physisch hin. Bei den Arrays/Tabellen mit 
der indirekten Adressierung.
Dinge, die AVRs intern erledigen.
Das werden wohl die Hersteller für sich behalten.
Nur das Nötigste preisgeben, und sei es auch nur mit sibyllinischen 
Hinweisen. Oder diese Dinge werden von ATMEL schlichtweg für 
Programmierer und Schaltungsdesigner als völlig irrelevant angesehen.
Bernd S. schrieb:
> Vielleicht hat es ja ein Anderer verstanden und kann es mir wiederum
> verständlich machen. Dafür ist doch auch ein Forum da oder ?

Aber, falls es Dich interessiert:
Eventuell gibt es noch weiterführende Hinweise in einigen 
Atmel-Fan-Foren.
https://www.avrfreaks.net/forum


ciao
gustav

von Oliver S. (oliverso)


Lesenswert?

Karl B. schrieb:
> Wo schreibt der AVR die Daten physisch hin. Bei den Arrays/Tabellen mit
> der indirekten Adressierung.
> Dinge, die AVRs intern erledigen.

Du schreibst und redest ziemlich wirr. Arrays/Tabellen mit indirekter 
Adressierung, intern?

Oliver

von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Karl B. schrieb:
> Aber, falls es Dich interessiert:
> Eventuell gibt es noch weiterführende Hinweise in einigen
> Atmel-Fan-Foren.
> https://www.avrfreaks.net/forum

Dort kannst Du Deine Frage in Englisch formulieren.
Wo, in welchem Unterforum Du das postest, müsstest Du erst selber 
herausfinden. Die Arbeit nehme ich Dir hier nicht ab.
BTW: Bin schon gespannt, wie Deine Fragestellung im Englischen klingt.

ciao
gustav

von Stefan F. (Gast)


Lesenswert?

Karl B. schrieb:
> Bin schon gespannt, wie Deine Fragestellung im Englischen klingt.

Ich habe sie nicht einmal auf deutsch verstanden.

> arbeite sporadisch die 6te Auflage durch.
> Seite 67, Kapitel 2.3.4  Operationen mit SF-Registern.
> Frage mich was bei den Port-Bit-Befehlen zur besonderen Vorsicht
> beiträgt, was nicht auch für die Port-Byte-Befehle gelten sollte ?
> Beide Arten führen doch Lese,- und Schreiboperationen durch.

von Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)


Lesenswert?

Oliver S. schrieb:
> c-hater schrieb:
>> Jan schrieb:
>>
>>> Und natürlich sind sbi/cbi atomar
>>
>> Sind sie eben nicht. Nicht bezüglich der Peripherie, nur bezüglich der
>> MCU.
>
> Es gibt ein paar Steinzeit-AVRs (Mega8, etc.), bei denen sbi/cbi über
> ein read/modify/write auf das ganze Register ausgeführt werden. Bei
> allen neueren wird atomar das jeweilige Bit geschrieben, sonst nichts.
>
> Oliver
>
Deshalb lernt man ja nie aus.

Woher weiß man so etwas ?

Warum hat der der SBI-Befehl dann nur max. 2 Takte und nicht 3, wenn er 
doch RMW macht ?

IN  Rd, PORTx
ORI Rd, Bitmaske
OUT PORTx, Rd

Aber Atomar ist er ja doch, weil er als einzelner Befehl vom 
Befehlsdekoder erkannt wird und dementsprechend erstmal verarbeitet 
wird, bevor ein IRQ diesen unterbrechen könnte.

"Nicht gegenüber der Peripherie" ist mir eindeutig zu hoch, denn dass 
kann doch sowie so nicht unterbunden werden oder sind die internen 
Peripherie-Einheiten gemeint ( I/O-Ports, ADC, AC, ICP usw. ) ?

Bernd_Stein

: Bearbeitet durch User
von Karl B. (gustav)


Angehängte Dateien:

Lesenswert?

Oliver S. schrieb:
> Du schreibst und redest ziemlich wirr. Arrays/Tabellen mit indirekter
> Adressierung, intern?

Hi,
das schwebte mir vor. Leider Downloadlink verschütt gegangen.
Wo jetzt genau was ins SRAM geschrieben wird, (so lange nicht der Stapel 
überläuft,) ist nicht so super einfach erklärt.
Das wird natürlich erst dann von praktischer Bedeutung, wenn durch 
Versorgungsspannungsausfall mit Datenverlusten zu rechnen ist.
Welche Adresse wurde zuletzt beschrieben? Eine FAT oder MFT hat AVR 
nicht?
Oder?

ciao
gustav

von Johannes S. (Gast)


Lesenswert?

Oliver S. schrieb:
> Stefan ⛄ F. schrieb:
>
>> Georg M. schrieb:
>>> Oliver S. schrieb:
>>> Atmega328P abgekündigt
>>
>> Wow! Das ist eine Überraschung.
>
> Na ja, schrub ich zwar nicht, aber abgekündigt ist nur der „328P“. Die
> anderen 328er gibts noch. Da muß der Chinese noch nicht aktiv werden.
> Oliver

Die Chinesen sind doch von 8051 Derivaten gleich auf ihre eigenen 32 
Bitter gewechselt. Zum 8051 liefen da lange Schulungsprogramme im TV. 
War schon lange nicht mehr da, vermutlich wird da jetzt auch was zu den 
Cortex-M gebracht.

von jo (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Georg M. schrieb:
>> Oliver S. schrieb:
>> Atmega328P abgekündigt
>
> Wow! Das ist eine Überraschung.
>
> Keine Sorge, den werden die Chinesen ggf. nachbauen, wenn sie es nicht
> schon längst tun.

*** BITTE RICHTIG LESEN! ***

Was wirklich da steht ist: 
(https://www.microchip.com/en-us/product/ATMega328P)
- ATmega328P / Not Recommended for New Designs

Weiter unten findet sich dann: 
(https://www.microchip.com/en-us/product/ATMega328P#buy-from-store)
- Out of Stock / Additional quantities can ship by 24-Oct-2022

Also nix abgekündigt, sondern nur irre lange Lieferzeiten.

von Stefan F. (Gast)


Angehängte Dateien:

Lesenswert?

jo schrieb:
> BITTE RICHTIG LESEN!
> Also nix abgekündigt, sondern nur irre lange Lieferzeiten.

Irre lange Lieferzeiten gelten für alle AVR Mikrocontroller.

Wenn ein Chip durch einen anderen ersetz wurde, dann steht das 
normalerweise auf der Webseite und im Datenblatt. Bei der Gelegenheit 
fiel mir auf, dass das Datenblatt nicht mehr verlinkt ist. Ein Klick auf 
"Documentation" scrollt nur nach unten wo die Doku normalerweise wäre, 
aber da ist keine mehr.

Bei allen anderen AVR (z.B. ATmega8, ATttiny13A, ATmega128, ATmgega644 
und sogar ATmega328 ohne P, sowie ATmgea328PB) konnte ich Doku jedoch 
finden und sie sind noch "In Production".

Wenn man die Seite vom ATmega328 (ohne P) aufruft kommt man auf das 
Datenblatt vom ATmega328/P, in dem steht kein Vermerk dass er ersetzt 
oder nicht mehr empfohlen sei.

von Jimi H. (jimih)


Lesenswert?

Stefan ⛄ F. schrieb:
> Irre lange Lieferzeiten gelten für alle AVR Mikrocontroller

Na das stimmt natürlich in keinster Weise.
Bei Digikey sind viele (vor allem neuere) lieferbar. Allerdings würde 
ich empfehlen, die alten Kamellen endlich links liegen zu lassen denn 
die aktuellen (z.B. AVR128Dx oder ATTiny1624) ersetzen locker alle alten 
Chips und haben in jeder erdenklichen Hinsicht Vorteile. Bis hin zu 
Preis und Lieferbarkeit...

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.