Hi, hab mal eine Frage zu der Routine aus dem ASM ADC-Tutorial, welche zur Umwandlung einer Zahl in deren Dezimalziffern genutzt wird. Gemeint ist der Beispielcode von hier: http://www.mikrocontroller.net/articles/AVR-Tutorial:_ADC#Ausgabe_als_Spannungswert Explizit um diesen Teil des Codes der im Anhang zu finden ist. Mein Problem das sich bei dieser Routine ergibt ist folgendes: Wann muss ich wieviele Bytes einer Zahl zu dieser Berechnung heranziehen? Also: Hier geht es ja um eine 32 Bit Zahl welche ich zerlegen will. Bei dem Schritt mit dez. 10.000 benutze ich 3 Byte, obwohl ja die 10.000 allein nur 2 Byte in der binären Darstellung benötigen würde. Bei dez. 100 das Selbe: 2 Byte für Rechnung, 1 Byte für binäre Darstellung ausreichend. Gibt es da eine Regel? Hat es was damit zu tun ob man addiert oder subtrahiert? Bei der Subtraktion ist es egal wieviele Bytes man verwendet (also es müssen mind. soviele sein, dass man die Zahl damit darstellen kann) da die führenden Nullen ja keinen Einfluss in der Berechnung haben. (Ich verwende für die schriftliche Kontrollrechnung das "direkte" Subtraktionsverfahren, nicht die Subtraktion über die Addition des 2er Komplements. Damit stimmt auch die Auswertung des Carry Flags für den bedingten Sprung.) Wenn ich jedoch die negative Zahl abziehen will (wie im Beispiel bei 10.000 und 100) dann bedeutet das für die ALU (wenn ich mich jetz nich irre) ja nichts weiter als die Zahl als Vorzeichenbehaftet anzusehen. Also statt dez. 10 zu addieren kann ich in 8Bit Darstellung ja auch 246 abziehen. Und das ist wieder der springende Punkt: ich kann aber ja, rein theoretisch, genauso gut mit 16 Bit rechnen und statt dez. 10 addieren 65526 abziehen - funktioniert beides prima -> 1 Byte zuviel scheint also nicht gefährlich zu sein, sondern schafft Sicherheit. Daher: Woher weiß ich wann ich welchen Bereich nehmen soll? Danke schonmal fürs durchlesen und evtl. Antworten :) Sry wenn nicht rüberkommt was ich meine bzw. nicht verstehe. Es ist immer schwierig relativ Abstrakte Dinge, in welche man sich paar Stündchen eingedacht hat, in Schriftform zu bringen so dass andere Leute sofort folgen können :( MfG Robert
@ Robert K. (molch) >Wann muss ich wieviele Bytes einer Zahl zu dieser Berechnung >heranziehen? Genügend ;-) >Also: Hier geht es ja um eine 32 Bit Zahl welche ich zerlegen will. Bei >dem Schritt mit dez. 10.000 benutze ich 3 Byte, obwohl ja die 10.000 >allein nur 2 Byte in der binären Darstellung benötigen würde. >Bei dez. 100 das Selbe: 2 Byte für Rechnung, 1 Byte für binäre >Darstellung ausreichend. >Gibt es da eine Regel? Hat es was damit zu tun ob man addiert oder >subtrahiert? Sicher. Aber 9x10.000 = 90.000 = "24 Bit". 9x100 = 900 = "16 Bit" Na dämmerts? >65526 abziehen - funktioniert beides prima -> 1 Byte zuviel scheint also >nicht gefährlich zu sein, sondern schafft Sicherheit. Ja, dauert nur ein paar Tackte länger. Man kann auch ALLE Rechungen komplett in 32 Bit durchziehen, ist hier halt schon einen Tick optimiert. >Daher: Woher weiß ich wann ich welchen Bereich nehmen soll? Siehe oben. >Stündchen eingedacht hat, in Schriftform zu bringen so dass andere Leute >sofort folgen können :( Das ist die Kunst. MFG Falk
Morgen :) >>Gibt es da eine Regel? Hat es was damit zu tun ob man addiert oder >>subtrahiert? > > Sicher. Aber > > 9x10.000 = 90.000 = "24 Bit". > 9x100 = 900 = "16 Bit" > > Na dämmerts? > lichtaufgeh Danke! Das is wiederum ein Punkt an den ich noch überhaupt nicht gedacht hab. >>65526 abziehen - funktioniert beides prima -> 1 Byte zuviel scheint also >>nicht gefährlich zu sein, sondern schafft Sicherheit. > > Ja, dauert nur ein paar Tackte länger. Man kann auch ALLE Rechungen > komplett in 32 Bit durchziehen, ist hier halt schon einen Tick > optimiert. > Jep, leider für einen Anfänger eben schon aufs stolpern hin optimiert. Auch die abwechselnde Addition und Subtraktion ist verwirrend - für den Anfang (also für die Zielgruppe des Tutorials) wäre es m. E. günstiger gewesen man hätte am Ende jedes Schrittes einfach das zuviel abgezogene wieder addiert und und die Zählvariable temp5 wieder mit -1 + '0' geladen so das jeder Schritt identisch gewesen wäre. Leider ist dies in einigen Codebeispielen des Tutorials der Fall. Womit wir ich glaube wieder bei der Kunst wären etwas für andere Leute verständlich zu schreiben. Rechnet man das Beispiel durch ist es nach dem 5ten Mal wohl auch "trivial" (das Lieblingswort eines Mathe Profs.) - und wenn es einem selbst selbstverständlich vorkommt, heisst es leider nicht das jemand mit einem anderen Denkansatz es ebenfalls so klar und deutlich herausschaut um was es geht. Aber möglicherweise muss man stolpern um dann wieder aufzustehen und mitzubekommen, dass man auch so, etwas lernen kann ;) > >>Stündchen eingedacht hat, in Schriftform zu bringen so dass andere Leute >>sofort folgen können :( > > Das ist die Kunst. > siehe oben. Also nochmals Danke für die einleuchtende Antwort. MfG Robert
>> "trivial" (das Lieblingswort eines Mathe Profs.)
Mathe 1 & 2 beim Klein in Weingarten???
http://www.mikrocontroller.net/articles/AVR_Arithmetik#Bin.C3.A4r_zu_BCD_-_Umwandlung ich habe da mal die verschiedenen Algorithmen aufgelistet. Das mit dem abwechselnden Addieren und Subtrahieren ist wirklich etwas schwer zu verstehen, erst subtrahiert man, bis die Null unterschritten ist, und dann addiert man für die nähchste Stelle im Negativen, bis die Null wieder überschritten wird.
Bastler wrote: >>> "trivial" (das Lieblingswort eines Mathe Profs.) > > Mathe 1 & 2 beim Klein in Weingarten??? Ne, aber gibt wies aussieht einige von der Sorte :D Christoph Kessler wrote: > http://www.mikrocontroller.net/articles/AVR_Arithmetik#Bin.C3.A4r_zu_BCD_-_Umwandlung > ich habe da mal die verschiedenen Algorithmen aufgelistet. Das mit dem > abwechselnden Addieren und Subtrahieren ist wirklich etwas schwer zu > verstehen, erst subtrahiert man, bis die Null unterschritten ist, und > dann addiert man für die nähchste Stelle im Negativen, bis die Null > wieder überschritten wird. Die Links bei den Algorithmen habe ich leider noch nich durchgearbeitet. Meine Äußerung oben auch bitte nicht als Anklage verstehen. Ich finde es super, dass sich Leute welche es sowieso schon können, trotzdem noch mal die Mühe machen alles sauber gegliedert in einen Artikel zu packen, Links dazu sammeln etc. Also weiter so MfG Robert
@ Robert K. (molch) >Jep, leider für einen Anfänger eben schon aufs stolpern hin optimiert. >Auch die abwechselnde Addition und Subtraktion ist verwirrend - für den >Anfang (also für die Zielgruppe des Tutorials) wäre es m. E. günstiger >gewesen man hätte am Ende jedes Schrittes einfach das zuviel abgezogene >wieder addiert und und die Zählvariable temp5 wieder mit -1 + '0' >geladen so das jeder Schritt identisch gewesen wäre. Hast Recht. Werde ich bei Gegegenheit mal vereinfachen. MfG Falk
Die Alternative ist das Rücknehmen der letzten Subtraktion, oder noch ein paar Takte länger die Verwendung der virtuellen Subtraktion mit cp/cpc, auch das findet man in "div32.txt" bei elm-chan: http://elm-chan.org/docs/avrlib/div32.txt Wenn ich das recht sehe, verlängert sich so die Rechnung pro Dezimalstelle um bis zu 9 Subtraktionen gegenüber einer einzigen zusätzlichen bei Rücknahme der letzten, und Null beim abwechselnden add/sub
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.