ZitierenRichtig.Zitat von avr_racer
MfG
ah, stimmt, klar, Highbyte und Lowbyte passen ja bei unsigned char (0...255) zusammen rein.
Nur wenn man signed char (-128...+127) hat, braucht man bei 174 zwei Byte.
Richtig.
MfG
war das jetzt noch nötig?
Ja.
HeSt versucht was zu verstehen. Deshalb noch mal die Betonung, um Unsicherheit zu beseitigen. Und das Pallaver am Rande hilft ihm auch nicht weiter.
MfG
He Leute!
Langsam! Keine Seitenhiebe wegen mir !!!
Ich hab schon verstanden.
Die Auslegung von DEZIMAL war mir in diesem Sinne nicht geläufig.
Darum habe ich im Post #116 ja geschrieben: "reden wir aneinander vorbei?"
Dem war defacto so.
Ich meinte mit "dezimal" NUMMERN/ZIFFERN (123...)!
Gespeichert wird in dual, angezeigt in Hex um einstellig zu bleiben.
Und "Ziffern" (0,1,2,...) kann ein Display nicht darstellen, sondern nur in "Textform" als $30,$31, ....
Das war eben die Ungereimtheit.
Jeder meinte mit "dezimal" was anderes.
Ich werd mal alles durcharbeiten, was ich an Erklärungen erhalten hab.
Wird ein bisschen dauern, muss auch wieder mehr was anderes tun als nur hier rumgrübeln ...
Ja das ist es eben. Du kennst Zahlen als Schrift, wie Du schreibst. So existieren sie in Deiner Vorstellung und deswegen meinst Du diese Zahlen. Aber der Computer kennt eben eine andere "Schrift" für Zahlen und die ist erst mal binär. Die hexadezimale Darstellung bildet eine bestimmte Bit-Menge ab. Mit 4 Bit lassen sich Werte von 0 bis 15 abbilden: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E und F. Danach kommen 8 Bit, die aus jeweils 4 Bit bestehen: 4Bit|4Bit (z.B.: 0A, 12, B3). Dann fasst man zweimal 8 Bit zu 16 Bit zusammen: 8Bit|8Bit. Und so geht das dann vom Prinzip immer weiter. So kommt man irgendwann zu Datentypen, die 32 Bit umfassen oder noch mehr sogar.
Du musst Dich auf jeden Fall intensiv mit dem Rechnen in Maschinensprache auseinandersetzen. Ich finde, das ist jetzt das Wichtigste an allem. Sonst kommst Du immer wieder in Schwierigkeiten und verschiedene Dinge nicht verstehen zu können. Das gehört aber zum Grundverständnis. - Du hast Dir ganz schön was vorgenommen.
MfG
Ein Zündgedanke war im #116er schon dabei nur in der Weiterführung gings in die falsche Richtung.Die Auslegung von DEZIMAL war mir in diesem Sinne nicht geläufig.
Darum habe ich im Post #116 ja geschrieben: "reden wir aneinander vorbei?"
Dem war defacto so.
Ich meinte mit "dezimal" NUMMERN/ZIFFERN (123...)!
Gespeichert wird in dual, angezeigt in Hex um einstellig zu bleiben.
Und "Ziffern" (0,1,2,...) kann ein Display nicht darstellen, sondern nur in "Textform" als $30,$31, ....
Das war eben die Ungereimtheit.
Jeder meinte mit "dezimal" was anderes.
Ich werd mal alles durcharbeiten, was ich an Erklärungen erhalten hab.
Wird ein bisschen dauern, muss auch wieder mehr was anderes tun als nur hier rumgrübeln ...
Können wir uns auf Zeichen einigen ?
Diese Zeichen sind im LCD als ZEICHENVORRAT hinterlegt welche dann über eine ADRESSE angesprochen und dargestellt werden kann.
Das das LCD keine Ziffern darstellen kann ist eher nicht richtig, es kanns ja, nur du meinst eher die Umsetzung von Zahl -> Mensch -> µC -> LCD -> Zahl passiert.
Diesen Gedankengang hatte ich damals auch wie stellt ein LCD etwas da, bis mir jmd sagte das vieles fest vordefiniert wird was einfach dann abgerufen wird.
https://de.wikipedia.org/wiki/Americ...on_Interchange
Hab es mir schon gedacht das da ein Denkfehler vorlag. Mit signed vollkommen recht.
@Moppi danke für die Unterstützung
Jep das hat ja schon den Hauch einer Definition.
eine "Ziffer" ist ein Zeichen (für die Darstellung einer Stelle einer Zahl), ist aber selber keine Zahl !
(Eine "Zahl" ist Konstrukt, das sich in verschiedenen Zahlensystemen mit verschiedenen Ziffern schriftlich darstellen lässt)
Ziffern sind genau das, was die ASCII Codes 48...57 plus ggf. zusätzlich weitere Buchstaben (für andere Zahlensyteme) repräsentieren.
Geändert von HaWe (14.01.2019 um 09:48 Uhr) Grund: typo
@avr_racer
Hab mich mit deinem "Mathe.asm" Programm auseinander gesetzt.
Vieles ist mir jetzt klar(er), alles noch nicht ...
Was ich gefunden hab, hab ich dir bereits in der PN geschrieben.
Was mir noch nicht klar ist, wozu die SWAPs in HEX_DEC gut sein sollen?
Das macht die Umwandlung in ASCII schwieriger!
Beispiel:
34515: 03 40 05 15 (besser: 03 04 05 01 05 ohne swap und ZE getrennt)
Wie kann ich ZE gemeinsam in ASCII umwandeln/anzeigen?
Da ich die Ziffern am LCD einzeln ausgebe, müssen die getrennt sein.
Das ist zumindest mein Gedankengang.
Oder liege ich hier falsch?
ich fürchte, du hast immer noch nicht verstanden, dass du eine auf dem µC gespeicherte Zahl (z.B. 0xAE) nicht direkt in ASCII als Dec Zahl ausgeben kannst, denn weder 0xA noch 0xE sind Dezimalziffern.
also musst du erst durch eine Reihe von Rechenoperationen (Division, Modulo) eine Dezimalsystem-Stellen-Zerlegung erzeugen (Hunderter, Zehner, Einer, hier also: 1*100 + 7*10 + 4*1)
und erst DIESE kannst du dann (per ASCII offset=48 ) als Ziffern ausgeben (1 7 4 , einzeln oder gemeinsam als string).Code:Hunderter: 0xAE/100 Zehner: (0xAE mod 100) / 10 Einer: (0xAE mod 100) mod 10
Geändert von HaWe (16.01.2019 um 11:14 Uhr) Grund: typo
Berechtigungen
Lesezeichen