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.
Lese das mal durch. http://www.avr-roboter.de/controller/befehle/beschreibung/beschreibung.html C: Das C-Flag wird gesetzt, wenn im Ergebnis ein Überlauf von Bit 8 erfolgte, andernfalls wird es gelöscht. Schicke mal den Code den Du hast zum Testen und nicht verstehst.
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)
Ich würde den Lernaufwand in die Sprache C investieren.
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 |
2 | Rr: Source register in the Register File |
3 | R: Result after instruction is executed |
Oliver
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.
Noch was Wichtiges. Beim Bild vom 2-Bit Addierer / Subtrahierer ist b beim subtrahieren (b = Subtrahend) zu negieren. Bis demnächst Bernd_Stein
Hallo zusammen, es ist wirklich schade das in diesem Buch so verdammt spärlich auf die Bedingungsbits ( Flags ) im Statusregister ( SREG ) eingegangen wird. Ich beschäftige mich gerade eingehend mit dem Halfcarry-Flag, was sich genauso verhalten dürfte wie das Carry-Flag. Nur halt mit dem Bit3. Beim NEG-Befehl steht foldendes : Rd <= $00 - Rd H = P3 + /Rd3 Jetzt habe ich folgendes progrämmchen im ATMEL-Studio 7.0.1188 laufen lassen und wunderte mich, das das Halfcarry-Flag nicht gesetzt wurde, obwohl Rd ja = $00 ist, was ich mal als /Rd interpretiere.
1 | ; |
2 | ;.INCLUDE "m8def.inc" ;AVR-Definitionsdatei einbinden |
3 | .CSEG ;was ab hier folgt kommt in den FLASH-Speicher |
4 | .ORG $0000 ;Programm beginnt an der FLASH-Adresse 0x0000.CSEG |
5 | |
6 | .INCLUDE "Header_A400_BS.inc" ;Einbinden der Controllerspezifischen |
7 | ;Definitionsdatei, sowie weitere Definitionen und |
8 | ;Wertezuweisungen |
9 | |
10 | _RESET: ;Hier beginnt der µC nach einem Reset mit seiner Arbeit |
11 | rjmp _START ;Springe zum Programmbeginn |
12 | |
13 | _START: |
14 | |
15 | clr al ;Arbeitsregister-Low Null setzen... |
16 | neg al ;... und das Zweierkomplement davon bilden |
17 | |
18 | rjmp _START |
19 | |
20 | .EXIT ;Ende des Quelltextes |
Wo ist mein Gedankenfehler ? Bernd_Stein
@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?
Angehängte Dateien:
-
AVR_Befehl_NEG.jpg
110 KB
Stefan U. schrieb: > Die 8bit AVR Mikrocontroller, um die es in dem von mir zittierten > Datenblatt geht und auf das ich Bezug nahm, können durchaus subtrahieren > (SUB Befehl). Und P3 kommt in dem gesamten Dokument nirgends vor. > Wenn du nicht über 7000 Beträge bisher geschrieben hättest und ich nicht der Meinung wäre, daß du etwas von der Materie verstehst, hätte ich nicht geantwortet. Nun, da ein Bild ja bekanntlich mehr sagt als tausend Worte, habe ich dies mal angefügt. Die ALU ( Arithmetic and Logic Unit ) bzw. das Rechenwerk kann ja noch nicht einmal im eigentlichen Sinne addieren, aber logische Verknüpfungen druchführen schon. Darauf baut ja die Addition auf. Siehe : Beitrag "Re: Buch AVR von Günter Schmitt durcharbeiten" oder die Seiten 13 bis 15 in dem zur Diskussion stehendem Buch. Bernd_Stein
:
Bearbeitet durch User
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.
Interessant, ich hatte eben in meine lokale Kopie des Manuals geschaut, und da steht in Kapitel 84.2 "H: R3 + /RD3"
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
Ich hoffe noch so alt zu werden, bis du die nächste Frage zum Zero-Flag stellst.
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?
Mit Vorzeichen kann ein Byte nur -128 bis +127 darstellen. -200 gibt es nicht (in einem Byte).
Beitrag #4953600 wurde vom Autor gelöscht.
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
Angehängte Dateien:
-
Falsch_BCD_addition.jpg
160 KB
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
Bernd S. schrieb: > habe ich mal alle Befehle herausgesucht Das hättest Du auch einfach haben können: http://www.avr-asm-tutorial.net/avr_de/beginner/commands.html Aber schön, dass jetzt für Dich alles erklärbar ist - dann kannst Du den Thread ja schließen lassen.
Auf der Seite 62 bzw. 74 steht: " ...Der Anfangswert wird aus dem Systemtakt berechnet, der als Symbol TAKT im Hauptprogramm definiert sein muss. Ein Zahlenüberlauf bei Frequenzen größer 16,38MHz wird durch die bedingte Assemblierung abgefangen.
1 | .IF (TAKT/250) > 65535 ;Anfangswert fuer max. 16MHz |
2 | .ERROR "Fehler: TAKT > 16MHz " |
3 | .ELSE |
4 | ldi XL,LOW (TAKT/250) ; 8MHz / 250 = 32000 |
5 | ldi XH,HIGH(TAKT/250) ; 32000*5*1/8 MHz = 20ms |
6 | .ENDIF |
Abgesehen davon, dass sich wohl ein Fehler in dem Kommentarteil mit den 8MHz Beispiel eingeschlichen hat, frage ich mich 1. Warum gerade 16,38MHz, wenn ein 16MHz verbaut ist? Evtl. weil man mit einem 16,384MHz Quarz genauere Baudraten generieren kann ? und 2. Warum nicht durch z.B. 245 geteilt wird, was 65306,122 ergeben würde ( auf 16MHz bezogen ). Bernd_Stein
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
Schmitt_Programm_CD.png
23 KB
Bernd S. schrieb: > Die CD habe ich leider nicht, denke es ist auch besser die Programme > abzutippen, um die Syntax zu erlernen ;-) Hi, auf der CD ist noch eine Ergänzung. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > Hi, > der Autor sagt doch auf Seite 170, dass das Programm "einbcd" abbricht. > "...Die Eingabe wird bei der ersten Nicht-Ziffer oder bei einem Überlauf > abgebrochen..." > Danke für die zusätzlichen Informationen. Mir ist klar, das der Assembler die Assemblierung abbricht, wenn der TAKT > 16.383750 ist. Karl B. schrieb: > Hi, > auf der CD ist noch eine Ergänzung. > Hm -? Ich habe die 4. Auflage. Verstehe jedoch leider immer noch nicht den Zusammenhang, den du mir klarmachen willst. Markus K. schrieb: >> Warum gerade 16,38MHz, wenn ein 16MHz verbaut ist? > > Das ist das Limit, das man nicht überschreiten darf. D.h. Du kannst an > der Stelle erstmal keinen 17MHz Quarz benutzen. 16MHz sind aber ok. > > Es geht eigentlich um folgendes: > Das Ergebnis der Division wird in 2 Bytes gespeichert. Da kann man aber > nicht beliebig große Zahlen reintun. Das Limit für 16 Bit ohne > Vorzeichen sind 65535. Das bedeutet, dass > Takt / 250 = maximal 65535 > > Das kann man jetzt Rückwärts rechnen: > 65535 * 250 = 16383750 > Das ist also der höchste Takt, bei dem das Ganze noch funktioniert. > Das liest sich sehr stimmig. Es gibt Tatsächlich einen 16.384MHz Quarz, aber beim ATmega8, sowie beim ATmega16 ist in den Electrical Characteristics unter *External Clock Drive*, maximal 16MHz angegeben. Habe zwar schon gehört, das man diese auch übertakten kann, denke aber nicht das dies der Autor meint, da der Assembler ja abbrechen würde, wenn man die 16.384000 eingibt. .IF (TAKT/245) > 65535 wäre da eigentlich passender gewesen ( 16.056075MHz ), wenn es dem Autor Prof. Dipl.-Ing. darum ginge ;-) Das Einzige was mir auffällt ist, das 16e6 / 250 eine Ganzzahl ergibt ( 64000 ), was in Assembler immer von Vorteil ist. Bernd_Stein
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
1 | 3.1.1 Akkumulator-Maschine |
2 | Die Akkumulator-Architektur ist das Organisationsprinzip vieler einfacher früher Rechner aber auch vieler Mikrocontroller (z.B. Motorola 6809). Sie zeichnet sich durch einen Akkumulator (ggf. auch zwei Akkumulatoren) als zentrales Register aus. Rechenergebnisse werden in diesem Register |
3 | ”akkumuliert“ (daher der Name). Rechenoperationen beziehen sich auf einen Operanden und implizit den Akkumulator. In der Befehlscodierung ist somit bereits die Information enthalten welches Register als Quelle und ggf. Ziel zur Operation genutzt wird... |
UND
1 | 3.1.3 Registersatz-Maschine |
2 | Die Registersatz-Architektur basiert auf mehreren, üblicherweise 16 oder 32 gleichberechtigten Universalregistern. Abbildung 3.3 zeigt die allgemeine Struktur einer Registersatz-Maschine. Mindestens ein Operand wird aus einem der internen Prozessorregister bezogen, wobei dieses Register im Befehl explizit angegeben werden muss. |
3 | |
4 | Überhaupt kennen Registersatz-Architekturen nur explizite Operanden, entweder Register oder Speicheradressen. Dass die Registersatz-Maschine - wie der Name schon sagt - auf einem Satz von Registern basiert, liefert einige Vorteile. Register sind schneller als RAM-Speicher. Dadurch dass die Register als Variablenspeicher verwendet werden, kann der Speicherverkehr verringert und so die Programmausführung beschleunigt werden (da Register flexibler und schneller sind als Speicher). Letztlich wird im Gegensatz zur Verwendung von Speichervariablen auch die Codierung kompakter, da Register mit weniger Bits adressierbar sind als Speicherstellen... |
Quelle : https://prof.beuth-hochschule.de/fileadmin/prof/svoss/MOP/Skripte/Skript_MOP_WS16.pdf Wenn man mir auf meine beiden einfachen Fragen antworten würde, wäre mir mehr geholfen. In diesem Sinne, Bernd_Stein
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
Ich würde ja eher einen Bogen um Franzis Produkte machen, wenn ich etwas lernen möchte.
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 ;-)
Angehängte Dateien:
-
SBIC_Simulator.jpg
230 KB
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
Angehängte Dateien:
-
sbic_Simulator_2.jpg
210 KB
spess53 schrieb: > Hi > >>Klar könnte ich den Breakpoint einen Befehl eher setzen ( *sts LOW >>(kopfz),xl* ), aber wenn ich das mache, wird dieser für mich auch >>richtigerweise erst beim anklicken von Step Into ausgeführt und nicht >>wie bei *sbic PIND,7* der schon ausgeführt wird, bevor ich Step Into >>anklicke. > > Muss man diese Aussage jetzt verstehen? > Der Gelbe Pfeil sagt :"This is the next Statement that will be executed...". Den Rest bin ich zu faul zu tippen und kann ihn auch ohne zu googeln gar nicht richtig übersetzen. Auf jeden Fall sagt mir dieser Satz, das der Befehl erst ausgeführt wird, wenn ich z.B. den Einzelschritt ( Step Into ) ausführe. > > Setze doch einfach mal ein nop ein: > > _loop1: nop > sbic PIND,1 > rjmp _loop1 > ... > > und setze den Breakpoint auf "_loop1: nop". > Dann PIND7 setzen oder löschen und sehen, was passiert. > Blöderweise das gleiche. Also, ich starte mit dem grünen Play-Pfeil ( Start Debugging ), lande dann beim nop-Befehl ( Breakpoint ). Nun setze ich PIND7, klicke Step Into, lande beim Skip-Befehl, klicke Step Into und lande fälschlicherweise beim in-Befehl. Frage mich natürlich warum ? Nutze das ATMEL-Studio 7 Version 7.0.1645 Ach, habe dummerweise im Programm beim herumexperimentieren in Zeile 55 ( mov xh,xh ) geschrieben, muss richtigerweise *mov yh,xh* heißen. Bernd_Stein
:
Bearbeitet durch User
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
Hi Ich habe das bei mir getestet. Bei mir reagiert der Simulator egal, ob mit oder ohne dem nop richtig auf den Inhalt von PIND7 . Mfg Spess
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.
Angehängte Dateien:
-
Simulatorwahl.jpg
75 KB
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
Angehängte Dateien:
-
ATMEL_Studio7_avrsim2.jpg
290 KB
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
Angehängte Dateien:
-
Synchronisation_PINx.jpg
100 KB
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.
1 | loop3: |
2 | st X+,akku ; 2 Takte zum Speichern noetig |
3 | in akku,PIND ; 1 Takt um den neuen Zustand zu laden |
4 | |
5 | nop ; 1 Takt zur Verzögerung |
6 | |
7 | sbiw zaehll,1 ; 2 Takte um den 16bit Zähler Zu dekrementieren |
8 | brne loop3 ; 2 Takte bei Sprung |
Ich finde den NOP-Befehl unnötig, da die zur Synchronisation benötigte Zeit ( maximal 1,5 Takte ) die nötig ist um einen PORT-PIN einzulesen, durch SBIW bereits gegeben ist und durch die nachfolgenden Befehle ( BRNE & ST ) erst recht. Bernd_Stein
Bernd S. schrieb: > Ich finde den NOP-Befehl unnötig, da die zur Synchronisation benötigte Ich auch. Von Synchronisation ist dort gar nicht die Rede.
Mönch schrieb: > Von Synchronisation ist dort gar nicht die Rede. > Damit du den Zusammenhang verstehst solltest du hier noch mal kurz nachlesen : Beitrag "Re: Buch AVR von Günter Schmitt durcharbeiten" Bernd_Stein
Wie in der Überschrift zu lesen, geht es um die Adressierung der Variablen im SRAM ( Kapitel 2.5.2 ). Dort wird auch die *indirekte Adressierung* mit Post-Increment vorgestellt. Im folgenden Programmausschnitt ( k2p9.asm ) wird davon allerdings kein Gebrauch gemacht, obwohl dies den ADIW-Befehl vermeiden würde und somit ein Word und zwei oder drei Takte eingespart werden könnten. Obwohl mir die Buchreihe von Manfred Schwabel-Schmidt zu undurchsichtig ist, stimme ich seiner Aussage zu der Assemblerprogrammierung voll zu. In etwa meint er, es geht in der Asssemblerprogrammierung darum ein bestmögliches Maschinenprgramm, zu dem jeweiligen Gerät zu erstellen, denn dies ist halt der Vorteil der Assemblerprogrammierung und dazu ist jedes unkonventionelle Vorgehen erlaubt und erwünscht. Es sind halt die einzigsten Vorteile der ASM-Programmierung, dass man hiermit die schnellsten und speichersparensten Programme schreiben kann und dies sollte im Vordergrund der ASM-Programmierung auch gelehrt werden, sonst macht es keinen Sinn in ASM zu programmieren. Zwei oder drei Takte deshalb, weil das Instruction Set Summmary zum ATmega16 und auch zum Atmega8 zwei Takte sagt und das Instruction Set Manual 1 Takt. Der Simu des AS7 macht bei eingestelltem ATmega8 übrigens 2 Takte, wie es im Instruction Set Summary seines Datenbuches steht.
1 | _loop1: |
2 | lpm ;r0 mit dem Inhalt, der durch Z.. |
3 | ;...angegebenen Flashadresse laden.. |
4 | ;..ICH WÜRDE lpm r0,z+ SCHREIBEN |
5 | tst r0 ;Endmarke Null?.. |
6 | breq _lab1 ;..Ja -> Fertig |
7 | cpi zaehl,anz+1 ;Ansonsten Max. Listenlänge erreicht? |
8 | brsh _lab1 ;Ja -> ebenfalls Fertig |
9 | st x+,r0 ;Das jeweilige Flash-Byte ins SRAM.. |
10 | ;..kopieren & danach die SRAM-Adresse.. |
11 | ;..um eins erhöhen |
12 | adiw ZH:ZL,1 ;Flash-Adresse um eins erhöhen |
13 | ;KANN MAN DURCH OBEN lpm r0,z+ SPAREN |
14 | inc zaehl ;Listenelementezähler um eins erhöhen |
15 | rjmp _loop1 ;Zum Schleifenanfang springen |
Bernd_Stein
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
:
Bearbeitet durch User
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.
1 | cpi zaehl,anz+1 ;Ansonsten Max. Listenlänge erreicht? |
2 | brsh _lab1 ;Ja -> ebenfalls Fertig |
Bernd_Stein
:
Bearbeitet durch User
Angehängte Dateien:
-
AS7_Scheiss_Simulator.jpg
150 KB -
AVR8_ist_Little_Endian.jpg
290 KB
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
:
Bearbeitet durch User
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.
Angehängte Dateien:
Hi, finde den Link nicht. Aber glaube, da gab es 'mal eine App Note für. "Sorry Titel nicht mehr lieferbar." Hab noch Screenshot von den hier relevanten Seiten 12 und 13. "Little Endian" "Wait a minute, that looks backward..." ciao gustav
:
Bearbeitet durch User
Angehängte Dateien:
-
DebugWire_0x000.jpg
360 KB
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
Schau nochmal genau hin, welchen Adressbereich eine RAM Ansicht gerade anzeigt.
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
Angehängte Dateien:
-
Disassembling_.jpg
49 KB -
Debugger_1_.jpg
50 KB -
Disassembling_1.jpg
79 KB
Bernd S. schrieb: > Kennt jemand eine Funktion im AS7 die mir aus einer Hex-Datei den > Assemblercode wiedergibt, damit ich entschlüsseln kann was $9895 als > Assemblercode ergibt? Hi, Disassembling geht bei mir so. 1. Mache ein Projekt auf 2. Create Initial File 3. Wähle Target aus Liste 4. Wähle im Menü "open File" und klicke auf das zu disassemblierende Hex-File. Dann Speicher unter Name "Disassembler" Das Debuggen nicht schließen, bevor nicht gespeichert. Projektdaten wieder löschen. (In *.asm sind dann sowieso nur Null Byte drin.) Dann kommen die Befehle mit Beschreibung allerdings ohne erläuternde Kommentare oder Labels. Siehe angehängtes Bild. Ist schon zeilenumbruchmäßig in Word bearbeitet worden. Registernamen in Hex. Ebenso die Konstanten, die sonst gerne so aussehen: ldi temp, (1<<WGM12)+(1<<CS10) sts TCCR1B, temp Muss man anhand des Debuggers herausfinden oder aus dem Datenblatt. Ist Studio 4. In Studio 7 gibt es das bestimmt auch, mal durchklickern... Wenn nicht, dann mach es wie ich, ich hatte 7-er Version und wieder downgegradet auf 4. Mir reicht die 4-er Version vollauf. ciao gustav
:
Bearbeitet durch User
Angehängte Dateien:
-
Dissassembllieren_1.jpg
92 KB -
Dissassembllieren_1_Hexdatei.jpg
90 KB -
Dissassembllieren_1_Simulator.jpg
110 KB -
Button_Disassembling.jpg
98 KB
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
Angehängte Dateien:
-
Button_Disassembling.jpg
98 KB
*Hat sich erledigt.* *Ein unscheinbarer Button ist zu klicken ( siehe ScreenShot Button )* Bernd_Stein
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
geht_doch.png
430 KB
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.
Angehängte Dateien:
-
DebugWire_BREAK.jpg
120 KB
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.
Bernd S. schrieb: > Ich halte Manfred Schwabel-Schmidt anhand seiner Buchreihe, die ich zwar > nicht verstehe, für sehr kompetent in AVR8ASM und ... > Hier mal seine Homepage mit Programmdownloads zu seinen Büchern : http://web.archive.org/web/20131126231432/http://schwabl-schmidt.de/index.php/download Bernd_Stein
:
Bearbeitet durch User
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
:
Bearbeitet durch User
@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
Warm fragst du eigentlich immer uns was der Autor sich bei bestimmten Sachen gedacht hat? Frage ihn doch besser!
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
:
Bearbeitet durch User
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
Angehängte Dateien:
-
AVR_Freaks_Forum.jpg
50 KB
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
:
Bearbeitet durch User
Angehängte Dateien:
-
Adressing_indirect.jpg
49 KB
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.
Angehängte Dateien:
-
2021-10-24_18-13.png
190 KB
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...
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.