Archiv verlassen und diese Seite im Standarddesign anzeigen : Binär--> Ascii Converter Routine in asm?
Import-Script
22.04.2002, 11:19
Wer kann mir helfen? Ich habe da einen AVR und ein <BR>LCD Display. Text anzeigen funktioniert.Jetzt Ich möchte eine signed Integer Zahl an einem diesem <BR>LCD Display anzeigen und bräuchte dazu eine <BR>Routine die mir die se binäre zahl in Ascii Zeichen umwandelt. Die Routine sollte in Assembler geschrieben sein. Kann mir da jemand helfen? <BR>Karl
Import-Script
22.04.2002, 13:32
Ne Zahl zwischen 0 und 9 kannst du einfach mit 48 addieren fertig dann müsstest du noch abfragen ob die Zahl größer als 9 ist <BR>Ist aber meiner Meinung nach nicht allzu schwer zu coden <BR>Viel Erfolg
Import-Script
22.04.2002, 13:33
<A HREF="http://progshop.com/elektronik/diskussion/messages/2066/2068.html?1012055136" TARGET="_top">http://progshop.com/elektronik/diskussion/messages/2066/2068.html?1012055136</A>
Import-Script
22.04.2002, 16:50
Sorry, aber das hilft mir nicht viel weiter. Ich <BR>bräuchte das ganze für ein signed 16Bit Integer <BR>und für einen AVR90S2333
Import-Script
22.04.2002, 19:05
Hi <BR> <BR>evtl. mal einen Blick in die Sourcen der printf()-Routine des SDCC werfen. Ist dann aber auch 51er Code. Vieleicht hilft auch der Blick in die Sourcen des AVR-GCC. <BR> <BR>Matthias
Import-Script
23.04.2002, 10:26
Hallo Matthias, <BR> <BR>ich glaube, Karl will alles aufm Silbertablett geliefert haben, d.h. genau passend und ganz ohne nachdenken. <BR> <BR>Alle 3 Methoden sind ja in dem Link zu finden und ein bisschen Anpassungsarbeit (unsigned->signed, 8051->AVR) hilft doch nur zu verstehen, was man da macht. <BR> <BR>Hinter die Kulisssen von printf() zu sehen, sollte aber auch die meisten Profis erschlagen, ob der Unmenge von Funktionen. <BR> <BR> <BR>Hallo Karl, <BR> <BR>ich bin mir sicher, mit Google findest Du auch das genau passende. <BR>Also entweder suchen oder nachdenken, ganz ohne Arbeit gehts nun mal nicht. <BR> <BR> <BR>Peter
Import-Script
24.04.2002, 15:59
Hi, <BR>Das ganze ist eigentlich ganz einfach: <BR>Zahl 16-Bit kann nur Werte bis 65535 annehmen. Die Decodierung geht dann nach Folgendem rezept: <BR> <BR>Prüfen, ob Zahl >= 10000; wenn nicht ->Ende <BR>1000 abziehen und ein Merkregister inkrementieren <BR>Gehe zum Anfang der Schleife. <BR> <BR>merkregister mit 48 addieren und ins Display schreiben. Generiert wurde das ASCII-Zeichen der 10000 Stelle. <BR> <BR>Das ganze dann nochmal mit <BR>1000 <BR>100 <BR>10 <BR>durchführen. <BR>Anschließdend die Verbleibende Zahl (Einerstelle) ebenfalls mit 48 Addieren und ausgeben. <BR>Da die Ausgabe auf dem Display von links nach rechts geschrieben wird, erhält man eine korrekte Darstellung. Führende Nullen werden bei dieser Methode mitausgageben: <BR>Aus 1234 wird auf dem Display 01234. <BR>Das sorgt für konstante Darstellungsbreite. Die Führeden Nullen kann man entweder unterdrücken oder durch Lehrzeichen ersetzen. <BR> <BR>Viel Spaß beim schreiben der Funktion <BR> <BR>Gruß <BR>Elmar
Import-Script
24.04.2002, 16:00
Ups, hab ich noch vergessen: das merkregister muß selbstverständlich vor decodierung der einzelnen Stellen auf 0 gesetzt werden!
Import-Script
25.04.2002, 08:28
Hallo Elmar, <BR> <BR>ja, das ist z.B. die Subtraktionsmethode. <BR>Sie ist immer die schnellste, wenn der Mikrokontroller keinen passenden Divisionsbefehl hat. <BR> <BR>Ich verwende die auch, allerdings etwas modifiziert. Ich subtrahiere immer solange, bis das Carry-Flag gesetzt ist, d.h. einmal mehr. Das spart den extra Vergleich und ist dadurch fast doppelt so schnell. <BR> <BR> <BR>Peter
Import-Script
25.04.2002, 12:31
Hallo Peter, <BR>natürlich gibt es immer eine Methode, die schneller, besser und bunter ist, aber da es sich offensitlich um einen Anwender handelt, der mit dieser Art von verfahren nicht vertraut ist, ist das enfachste Verfahren besser geeignet weil lehrreich. Natürlich dürfen verbesserungsvorschläge nicht fehlen, für dijenigen gedacht, die schon etwas erfahrener sind. Aus diesem Grunde gebe ich grundsätzlich nur Theorie und Grundlagen an. Fertige Programme verschicke ich dann nur auf Anfrage. Selberdenken macht schlau! <BR> <BR>Die "einmahl mehr subtraktion" bringt auch keinen vorteil, da der CJNE - Befehl, mit keiner Sprungadresse angegeben das Carrybit passend setzt. Damit hat man dann die Abbruchbedingung und Wiederholung der Schleife durch J(N)C. Muß man die zuvielgemachte subtraktion rückgängig machen, so spart man nicht, sondern braucht sogar 1 Maschinentakt (1µs) pro Durchgang mehr! <BR>Vielleicht denke ich aber auch in die falsche richtung... <BR> <BR>Gruß <BR>Elmar
Import-Script
25.04.2002, 13:11
Hallo Elmar, <BR> <BR>das sollte keine Kritik sein. Ich wollte nur erklären, warum meine Routine (siehe obigen Link) auch zur Subtraktionsmethode zählt, obwohl der Vergleich fehlt. <BR> <BR>Die nachträgliche Addition spare ich, indem ich abwechselnd bei einem Digit subtrahiere und beim nächsten addiere. <BR> <BR>Schlußendlich subtrahiere ich ja garnicht, ich addiere dann nur eine negative Zahl. Das spart das Löschen des Carry-Bits. <BR> <BR> <BR>Peter
Import-Script
25.04.2002, 13:15
Mit den "fertigen Programmen" hast Du völlig recht, es bringt nichts. <BR>Wenn man es nicht versteht, kommt meistens auch was falsches raus, weil man es falsch einsetzt. <BR> <BR> <BR>Peter
Import-Script
25.04.2002, 13:45
Hi <BR> <BR>ein fertiger Sourcecode bringt aber was wenn mal schnell was nachschauen will. Ich bin grade an nem FAT32-HDD-Treiber für den 80C320 dran und dann ist es nicht übel wenn man mal schnell in einen bestehenden und funktionierenden Sourcecode kucken kann. Mann muß allerdings verstehen was da gemacht wird. <BR> <BR>Matthias
Import-Script
25.04.2002, 19:28
Hi, <BR>das sollte natürlich keine Kritik sein. Wenn jemand es eilig hat, so sollte er auch darauf hinweisen. Dann kann er eine schnelle Hilfe bekommen und die Erklärungen können dann auf Anfrage erfolgen. Hat man die Programmierung als Hobby, so geht es ja ums lernen und Spaß haben. Wer das nicht möchte, kann schließlich fertigbausätze kaufen. Dieses Diskussionsforum ist ein guter Weg, Wissen auszutauschen. Ich selber habe in diesem Forum schon viele Anregungen und Problemlösungen gefunden, auch für Dinge, die ich <I>noch</I> nicht brauche. <BR> <BR>@Peter: <BR>Habe das mal mit einem Registerrechner durchprobiert. Das ganze spart natürlich etwas aufwand, aber den methematischen Beweis, daß es <B>immer</B> richtigrechnet bekomme ich nicht hin. Dann bleibt nur noch ausprobieren.... Da sieht man mal wieder: Da habe ich was tolles gelernt, was ich in Zukunft brauchen kann. Deine Methode benötigt tatsächlich viel weniger ROM und ist um ca. 5% schneller. Alle achtung! <BR> <BR>Gruß <BR>Elmar
Import-Script
26.04.2002, 08:42
Hallo Elmar, <BR> <BR>es sind ja 4 völlig voneinander unabhängige Schleifen. <BR>D.h. um zu beweisen, daß es geht, brauchst Du nicht alle 65536 Zahlen durchzuprobieren. Es reicht, wenn man jedes Digit separat von 0 ... 9 testet. <BR> <BR>Die Routine ist von unten nach oben gewachsen. D.h. man kann sie bequem auf 24 oder 32 Bit aufbohren. <BR> <BR> <BR>Das mit den 5% glaube ich nicht ganz, da die Zeit ja werteabhägig ist. Deine Routine braucht bei 59990 am längsten, meine bei 60900. <BR> <BR> <BR>Peter
Import-Script
28.04.2002, 13:33
Hi, <BR>@Peter: <BR>Ich habe die Routine, wie ich sie mir vorgestellt habe auf einem MC getestet. Dazu wird die Zahl via Hyperterminal eingegeben. Beim Returnzeichen werden die Ziffern passend umgewandelt und gespeichert. Bevor die Routine aufgerufen wird wird ein Timer gestartet. Die Routine wandelt die Werte um und speichert sie in verschiedenen Registern. Dann wird der Timer gestoppt. Danach erfolgt die Ausgabe der Ergebnisse via RS232 mit umgewandelter Zahl und Zeitangabe. Im mittel hat sie 5% Geschwindigkeitsvorteil, die Ergebnisse waren bei allen 10 Zahlen richtig. Vielleicht habe ich auch irgendwo was falsch gemacht. Aber warscheinlich bei beiden Routinen gleich falsch. Da kann man eine Diplomarbeit draus machen, um rauszufinden, ob alles mit rechten Dingen zugeht. Das ganze habe ich in 5 Minuten auf die Beine gestellt, also nichts besonders seriöses. <BR> <BR>Gruß <BR>Elmar
Powered by vBulletin® Version 4.1.12 Copyright ©2012 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.