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
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.
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
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.
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.
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
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.
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
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
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
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
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)
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
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?
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.
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
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 ?
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.
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.
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
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
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
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.
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.
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.
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) :-(
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.
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
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
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.
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
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
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
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.
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.
@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!
> 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?
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
> 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?
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
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.
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
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?
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
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?
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
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.
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
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
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
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
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.
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
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.
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
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
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
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.
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
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
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.
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
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
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
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.
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
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
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
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.
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...
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.
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.
> 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.
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
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.
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 ;-)
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
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.
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
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
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.
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
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
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).
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.
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
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
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
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.
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
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
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
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
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
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).
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
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.
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
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.
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.
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
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
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.
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.
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
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
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?
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
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...
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
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.
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.
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
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
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
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
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
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
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.
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?
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.
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.
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
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.
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
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?
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
@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
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
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).
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.
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
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.
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
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.
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.
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.
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 ...“.
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.
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
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.
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
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
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
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
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.
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
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
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.
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.
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.
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...