Integer zu ASCII wandeln M16C/62P

char str[20]; int wert;

wert = 1000;

sprintf(str, "%d", wert);

In str steht der Wert dann als String. Ich gehe mal davon aus, dass der Tasking Compiler das soweit bereitstellt...

ciao

"Thomas Graf" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

Ja seid ihr denn des Wahnsinns, das ganze Monster sprintf nur zur Ausgabe einer einzigen Ganzzahl zu missbrauchen ?

Ihr bestellt doch auch nicht den Schwerlasthelikopter wenn ihr mal einen Bleistift mit in die Schule nehmen wollt, oder ?

Olivers itoa ist sicher viel besser geeignet, wenn er Zahlen mit Vorzeichen ausgeben will

itoa(wert,str,10); for(i=0;str[i];i++) sende_zeichen_an_lcd(str[i]);

aber man kann es auch anders machen, wenn man fuehrende Nullen oder Leerzeichen auffuellen oder Zahlen ohne Vorzeichen ausgeben will oder es mit anderen Ausgaben verquicken will.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

:

Habe das Display m Stellen zur basis b. Liege eine positive Ganzzahl als bitstream vor, in der Reihenfolge MSB nach LSB.

Dann legst Du einen "BCD"-Puffer mit m Elementen an, welche in der Lage sein sollten, Zahlenwerte bis zu 2*b zu speichern.

1.) lösche Puffer 2.) multipliziere jedes Pufferelement mit 2 3.) nimm ein bit vom stream 4.) falls dieses bit=true, dann addiere den Wert 1 zum niederwertigsten pufferlement 5.) sorge dafür, daß alle Pufferlemente < b sind, indem du die Überträge handhabst. 6.) falls der stream nun noch immer nicht leer ist, fahre mit Schritt 2.) fort. 7.) Ergebnis anzeigen

Gruss

Jan Bruns

Hallo Zusammen

Ich habe schon wieder einiges auprobiert. Leider bis jetzt ohne den durchschlagenden Erfolg Ich habe zuerst mal versucht:

char str[20];

dabei habe ich volgende Fehlermeldungen m16 E042: "C:\serial\totalberechnung.c" line 94: syntax error, expecting statement ---------"char str[20]; " cm16 E117: "C:\serial\totalberechnung.c" line 94: "str" undefined cm16 E042: "C:\serial\totalberechnung.c" line 95: syntax error, expecting statement cm16 E131: "C:\serial\totalberechnung.c" line 95: bad operand type(s) of (deref)'*' cm16 E042: "C:\serial\totalberechnung.c" line 96: syntax error, expecting statement cm16 E117: "C:\serial\totalberechnung.c" line 96: "wert" undefined

Leider verstehe ich nicht wo das Problem liegt. Sieht jemanf von Euch das Problem?

Der Befehl itoa wird soweit ich das sehe nicht vom Tasking Compiler unterst=FCtzt. stimmt das?

Gruss Oliver

Wie sieht deine komplette C-Datei aus?

Das kann sehr gut sein. Das kenne ich von vielen C-Compilern so. Deshalb wird das meist mit sprintf gemacht...

ciao - Thomas

Das sieht dann so aus: extern void pause(void); extern void lcdinit(void); extern void pause1s(void);

//*************************************************************************=

************************** //include Files deffinieren * //*************************************************************************= **************************

#include "iom16c62p.h" #include #include #include "iodriver.h"

//*************************************************************************=

************************** //Definitions Files * //*************************************************************************= **************************

#define time 0x0FFF #define wait2ms 0x4268 #define rdwr P3_2//P3_bit.P3_2 //Seuersignal (LCD-)Umschalten Read/write auf P3.5 (T1) #define regs P3_1//P3_bit.P3_1 // Steuersignal (LCD-)Registerauswahl auf P3.4 (T0) #define en P3_3//P3_bit.P3_3 // Steuersignal (LCD-)Enable auf P3.3 (INT1) #define maske 0xc7 // Maske zum L=F6schen von rdwr, regs, en

//*************************************************************************=

************************** //Datentypenzuweisung vornehmen * //*************************************************************************= **************************

extern signed int preis; //externe variabeln deklarieren extern signed int preis1; extern signed int preis2; extern signed int kalorien; extern signed int kalorien1; extern signed int kalorien2; //externe variabeln deklarieren int totalpreis; int totalkalorien; //*************************************************************************=

************************** //eigentliche Routine totalberechnung starten * //*************************************************************************= **************************

void totalberechnung(void) { totalpreis =3D preis + preis1 + preis2;

totalkalorien =3D kalorien + kalorien1 + kalorien2;

char str[20]; int wert; wert =3D 1000; sprintf(str, "%d", wert);

------------------------------------------------------------------- am Ende stelle ich mir das dann etwa so vor:

char str[20]; sprintf(str, "%d", totalkalorien;

Mach mal die Variablendeklarationen _vor_ irgendwelche Anweisungen!

ciao - Thomas

Hallo,

was macht eigentlich dein UART-Problem vom 23.08.?

Aha.

C mag es nicht, wenn du Variablen _nach_ Anweisungen deklarierst. Die Funktion sollte also so aussehen:

HTH, bye Thomas

Thomas Graf schrieb:

Offensichtlich hat C++ schon zu viele Leute verdorben...

Gruß Henning

--
henning paul home:  http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613

Aha vielen Dank

Ich habs jetzt

Es hat wirklich nur an der Deklaration der Variabeln gelegen. Diese waren am falschen Ort deklariert, wie Ihr gesagt hattet

Habs nun so gemacht:

void totalberechnung(void) > { > char str[20]; > int wert; > totalpreis =3D preis + preis1 + preis2; >

und jetzt funktionierts. "auf den ersten Blick" Nat=FCrlich muss ich noch weiter austesten aber bis jetzt siehts gut aus

Ah ja das UART Problem hab ich zwischenzeitlich auch l=F6sen k=F6nnen. Da war eine kleine Einstellung im Compiler Fehlerhaft. Es gibt dort eine Einstellung, welche die Baudrate teilt. Leider war dort "dividiere durch 8" anstatt durch 1 eingetragen

Na ja, kleine Ursache, grosse Wirkung

Nochmals vielen Dank

Gruss Oliver

[...]

die Frage ist jetzt um wieviel byte/prozent dein binary größer geworden ist (dadurch dass du sprintf dazugelinkt hast) und ob dich das stört ... wenn es nur die Darstellung von integers geht, dann ist "sprintf" schon arge Verschwendung

Trade-off zwischen Preis und Entwicklungsaufwand - bei einem Prototypen oder Einzelstück mag es ok sein

bye, Michael

In C dürfen Variablen sehr wohl nach Anweisungen deklariert werden, sie müssen lediglich am Beginn eines Skopus stehen:

int main(int argc, char **argv) { printf("Test!\n"); { int i; for (i=0; i

Also mir drehts den Magen um, wenn ich das sehe.

Der Algorithmus von Jan ist eigentlich die erste Wahl.

Wem der zu kompliziert zu implementieren ist, und wer weiß, dass er z.B. nur positive 8-bit Integers hat, kann was in der Art machen:

unsigned char Zahl; char Buffer[4]; Buffer[3]=0; Buffer[0]=(Zahl/100)+'0'; Buffer[1]=((Zahl%100)/10)+'0'; Buffer[2]=(Zahl%10)+'0'; if (Buffer[0]=='0') { Buffer[0]=' '; if (Buffer[1]=='0') Buffer[1]=' '; }

Immernoch _viel_ effizienter als das sprintf Geraffel.

Gruß, Johannes

Meist wird man sprintf wohl noch öfter als nur an einer Stelle verwenden. Aber wenn man zuviel Zeit hat kann man natürlich alles selbst ganz toll implementieren ;) Es wird schon seinen Grund haben warum es diese Methode gibt...

ciao - Thomas

Hat er doch, er hat nur keinen ISO-C99-Compiler.

Nein, das hat nichts mit C++ zu tun oder verdorben zu sein, sondern das ist der ganz normale ISO-C99-Standard. Die Zeiten von K&R sind schon ein Weilchen vorbei...

Mir überhaupt nicht, ganz im Gegenteil. Es ist einfach nur gefährlich, wenn keine Not am Mann ist, jedes Rad und jede Schraube ständig neu zu erfinden.

Nein. Die Gefahr, dass in einem selbst implementierten Algorithmus ein Fehler enthalten ist, ist um ein vielfaches größer als die Gefahr, dass in einer erprobten Bibliothek, nämlich der Laufzeitumgebung des Compilers, ein Fehler enthalten ist.

Effizienz gemessen, geraten oder auf alten Vorurteilen gestüzt?

Davon abgesehen, dass die Formatierung anzuzeigender Daten eher selten zeitkritisch ist, kann man im dem Fall, in dem das doch _ausnahmsweise_ der Fall sein sollte, zur spezialisierten Version greifen.

Ein Problem immer erst mit den erprobten und ausgiebig getesten Werkzeugen lösen. Erst wenn das aus einem bestimmten Grund fehl schlägt, kann man ein eigenes Werkzeug bauen.

Das war einmal. Der seit 6 Jahren gültige ISO-C99-Standard erlaubt z.B. auch folgendes (etwas sinnloses Beispiel):

int main(int argc, char *argv[]) { int laenge = 10; puts("hallo"); char str[laenge+argc]; strcpy(str, "Huhu"); puts(str); return 0; }

Gerade bei Entwicklung auf einem uC ist es nicht unerheblich, ob ein so riesiger Codeteil wie der zu sprinf gehörige im Flash landet oder nicht. Sprintf ist absolut überdimensioniert für eine einfache Konvertierungsaufgabe. Es kann halt zu viel.

Der Algorithmus an sich ist korrekt. Zusätzlich ist er noch recht einfach. Wer da einen Fehler reinprogammiert, hat Pech, da hast du natürlich recht.

Erfahrungswerte.

Für dich hab ichs aber mal gemessen: mein Code, den ich im anderen Thread gepostet habe (Einschränkung: 8bit Integers!) 10000000 Mal laufen lassen, gegen sprintf:

Meine Version: real 0m0.073s user 0m0.061s sys 0m0.002s

Sprintf: real 0m2.290s user 0m2.271s sys 0m0.004s

Das ist jetzt gemessen. Zusätzlich habe ich noch ausgerechnet, wie groß die Differnenz der Codegröße ist. Mit Optimierung ist die sprintf-Variante 347 Bytes größer. Zugegeben, hier hatte ich deutlich mehr erwartet (in der Größenordnung von 1-2kB).

Man muss aber auch nicht immer gleich zur fettesten Variante greifen. Auf meinen uCs läuft auch keine Java RE, obwohl es prinzipiell natürlich schöner ist, objektorientierten Code zu schreiben.

Gruß, Johannes