Hallo Community, ich habe hier leider nichts zu meinem Problem gefunden, wenn ich das überhaupt als Problem bezeichnen darf. Ich will mit einem Atmega8 eine Oszillator ansteuern, der einen 32-Bit Wert seriell benötigt um die Frequenz einzustellen. Weiterhin ist an dem Atmega noch ein Display und eine Ziffern-Tastatur angeschlossen. Das Einlesen der Ziffern und Ausgeben auf dem Display ist nicht das Problem. Aber ich muss die Dezimalzahl jetzt ins Binärsystem umrechnen. Das heißt ich habe ein Char-Array der Länge 10 (0-2000000000) und will daraus ein unsigned char-Array der Länge 4 machen. Wie man zwei Zahlensysteme ineinander umrechnet ist nicht das Problem, aber auf dem Atmega8 gibt es schließlich keine 32-Bit-Befehle für Multiplikation, Addition und Modulo. Wie kann ich das also effektiv machen? Bietet mir der Compiler vielleicht sogar schon vorgefertigte Möglichkeiten? Ich bin da noch nicht so eingestiegen. Ich nutze die GCC mit Eclipse und avrdude zum Flashen unter Ubuntu 10.04 x64. Ich habe bereits Routinen für 32-Bit große Bit-Zahlen geschrieben: - Addition zweier 32-Bit-Zahlen mit Carry, - Multiplikation einer 32-Bit- mit einer 8-Bit-Zahl und Carry, - Multiplikation zweier 8-Bit-Zahlen und anschließendes Modulo mit einer 4-Bit-Zahl. Diese Funktionen dienen mir momentan als Grundlage und als nächstes würde die Division einer 32-Bit-Zahl durch eine 8-Bit-Zahl mit Rest dran kommen. Wenn ich die Divisions-Funktion habe, kann ich mit meiner Umrechnungsroutine von Dezimal in Binär beginnen. Und um nochmal die Frage von oben zu wiederholen: Geht das ganze effizienter und hätte ich mir die bisherige Implementierung vielleicht sparen können? Falls nicht, ist auch nicht schlimm, denn die Zahlensystemkonvertierung wird schneller sein als jede Eingabe über die Tastatur. ;) PS.: Wen's interessiert, der findet im Anhang die bisherige Include. Allerdings ist dies noch kein AVR-C-Code, sondern stink normaler C-Code zum Testen der Funktionen unter Verwendung von unsigned char.
Nicolas G. schrieb: > aber auf dem Atmega8 gibt es > schließlich keine 32-Bit-Befehle für Multiplikation, Addition und > Modulo. Wenn ich Dich richtig verstanden habe, geht es Dir um C für den AVR. Dort gibt es den Zahlentyp [u]int32_t (bzw. [unsigned] long) und alle von Dir beschriebenen Operationen dafür.
Mit einem C-Compiler kannst du auch den Datentyp long verwenden... > Division einer 32-Bit-Zahl durch eine 8-Bit-Zahl mit Rest In C geht das per / und % > hätte ich mir die bisherige Implementierung vielleicht sparen können? Ja, das kann der C-Compiler von sich aus. Die optimale Umsetzung (Zeit, Platz) macht dann der Compiler mit seinen Optimierungs-Funktionen...
> Ich habe bereits Routinen für 32-Bit große Bit-Zahlen geschrieben: > - Addition zweier 32-Bit-Zahlen mit Carry, > - Multiplikation einer 32-Bit- mit einer 8-Bit-Zahl und Carry, > - Multiplikation zweier 8-Bit-Zahlen und anschließendes Modulo mit einer > 4-Bit-Zahl. Du hast dir eine Menge Arbeit für nichts gemacht, weil du es verabsäumt hast, die Programmiersprache die du benutzt erst mal wenigstens in ihren Grundzügen zu lernen. > Das heißt ich habe ein Char-Array der Länge 10 (0-2000000000) > und will daraus ein unsigned char-Array der Länge 4 machen. Wenn du das char Array mit der Länge 11 gemacht hättest, könntest du daraus ganz simpeln einen C-String machen
1 | char Digits[11] = "2000000000"; |
2 | |
3 | uint32_t Value = atol( Digits ); |
fertig. In Value hast du deine 32-Bit Zahl die der 'Zahl' im String entspricht. Mehr hättest du nicht tun müssen.
Hallo Nicolas, die Frage bitte nicht falsch verstehen, aber es interessiert mich wirklich mal: Wie kommt man auf die Idee, in C 32-Bit-Operatoren nachbauen zu wollen?
Karl heinz Buchegger schrieb: > fertig. In Value hast du deine 32-Bit Zahl die der 'Zahl' im String > entspricht. Mehr hättest du nicht tun müssen. Fast. atol und uint32_t passen nicht zusammen. strtoul schon.
Hui, die Antworten hier kamen ja wie aus der Pistole geschossen. Hc Zimmerer schrieb: > Wenn ich Dich richtig verstanden habe, geht es Dir um C für den AVR. > Dort gibt es den Zahlentyp [u]int32_t (bzw. [unsigned] long) und alle > von Dir beschriebenen Operationen dafür. Du wirst lachen, aber ich habe eben im Zug von der Uni nach Hause genau diese Typen in der stdint.h gefunden. :D Karl heinz Buchegger schrieb: > Du hast dir eine Menge Arbeit für nichts gemacht, weil du es verabsäumt > hast, die Programmiersprache die du benutzt erst mal wenigstens in ihren > Grundzügen zu lernen. Naja, ein Menge Arbeit war es nicht. Vielleicht zwei Tüftel-Stunden. Allerdings muss ich mich noch zum zweiten Teil deines Satzes rechtfertigen. Ich programmiere als Informatik-Student jetzt schon länger Java, C, C++, usw. und kenne diese Sprachen durchaus in großen Umfang, aber ich Schlaumeier bin fest bei der Annahme geblieben, dass der Atmega8 eben nur 8 Bit rechnen kann bzw. 16 Bit Pointer unterstützt. Klaus schrieb: > Hallo Nicolas, die Frage bitte nicht falsch verstehen, aber es > interessiert mich wirklich mal: Wie kommt man auf die Idee, in C > 32-Bit-Operatoren nachbauen zu wollen? Siehe oben. Außerdem machen mir so Bit-Tüfteleien unheimlich viel Spaß. Ich habe schon bei dem Raytracer-Projekt letztes Jahr in den unteren zwei Bit eines aligned Pointers die drei Achsen und das Child-Flag eines kd-Trees versteckt. ^^ Dennoch werde ich meine Routinen weiterführen. Somit wird es dann möglich sein mit Zahlen zu rechnen, die den ganzen Speicher füllen. :) Außerdem an alle nochmal ein herzliches Dankeschön. So eine rege Beteiligung an einem Thread macht jedenfalls Spaß!
Nicolas G. schrieb: > Außerdem machen mir so Bit-Tüfteleien unheimlich viel Spaß. Hm, ich glaube, dir würde es auch Spaß machen, Assembler zu lernen ;)
Nicolas G. schrieb: > aber ich Schlaumeier bin fest bei der Annahme geblieben, dass > der Atmega8 eben nur 8 Bit rechnen kann Dann kennst du leider nichtmal die Grundlagen von C. Der Datentyp "int" muss, damit man dem Standard genügt, ja bereits mindestens 16 bits haben, wenn die Maschine mit binärer Zahlendarstellung arbeitet. > Dennoch werde ich meine Routinen weiterführen. Somit wird es dann > möglich sein mit Zahlen zu rechnen, die den ganzen Speicher füllen. :) Nennt sich "arbitrary precision arithmetic" und gibt's schon fertig als Bibliothek. ;-) Habe mir aber noch nicht angesehen, ob die Bibliothek auch auf einem AVR compilierbar wäre.
> Dann kennst du leider nichtmal die Grundlagen von C. Der Datentyp > "int" muss, damit man dem Standard genügt, ja bereits mindestens > 16 bits haben, wenn die Maschine mit binärer Zahlendarstellung > arbeitet. Ja, da hast du natürlich Recht. Da hätte ich selbst drauf kommen müssen. > Nennt sich "arbitrary precision arithmetic" und gibt's schon fertig > als Bibliothek. ;-) Habe mir aber noch nicht angesehen, ob die > Bibliothek auch auf einem AVR compilierbar wäre. Dass es solche Bibliotheken schon gibt, war mir klar. Es gibt schließlich kaum noch was, was in C oder C++ noch nicht geschrieben wurde. Das hindert mich allerdings nicht daran, trotzdem weiter zu machen. ;) Da steht mir der Spaß dann im Vordergrund.
Bitte 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.