Integer zu ASCII wandeln M16C/62P

Hallo Zusammen

Ich möchte Euch um Rat fragen betrefen der Umwandlung von
integerwerten in ASCII code.

Es geht um volgendes: Ich habe an meinem uP ein Standarddisplay
angeschlossen mit 8 Datenleitungen und 3 Steuerleitungen welches auch
tip top funktioniiert.

Nun möchte ich aber einen integerwert, welchen ich zuvor berechnet
habe auf das Display ausgeben.
Dafür muss ich diesen zuerst mal in ASCII Code wandeln.

Ich habe einen uP EVBM16C/62P von Glyn und verwende den Tasking
Compiler.

Kann mir jemand von Euch mit einfachen Worten erklären, wie man das am
Besten macht?
kann man das mit itoa() bewerksteligen? wie müsste das denn konkret
aussehen?

Habe leider noch zu wenig Erfahrung, aber das lässt sich ja ändern

Danke für Eure Hile

Gruss Oliver

 

[Thomas Graf]

Ich möchte Euch um Rat fragen betrefen der Umwandlung von
integerwerten in ASCII code.

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

 

[MaWin]

"Thomas Graf" <u.s.e.n.e.t.s.p.a.m@gmail.com> schrieb im Newsbeitrag
news:3nvsl8F3hbpvU1@individual.net...

Ich möchte Euch um Rat fragen betrefen der Umwandlung von
integerwerten in ASCII code.

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

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++) sende_zeichen_an_lcd(str);

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.

 

[Jan Bruns]

<huber_oliver@freesurf.ch>:

Nun möchte ich aber einen integerwert, welchen ich zuvor berechnet
habe auf das Display ausgeben.

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];

int wert;
wert = 1000;
sprintf(str, "%d", wert);

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ützt. stimmt das?

Gruss Oliver

 

[Thomas Graf]

huber_oliver@freesurf.ch wrote:

dabei habe ich volgende Fehlermeldungen
m16 E042: "C:\serial\totalberechnung.c" line 94: syntax error,
expecting statement ---------"char str[20]; "
[...]

Wie sieht deine komplette C-Datei aus?

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

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 <stdio.h>
#include <stdlib.h>
#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öschen 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 = preis + preis1 + preis2;

totalkalorien = kalorien + kalorien1 + kalorien2;

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


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

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

 

[Thomas Graf]

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

totalkalorien = kalorien + kalorien1 + kalorien2;

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

Mach mal die Variablendeklarationen _vor_ irgendwelche Anweisungen!

ciao - Thomas

 

[Thomas Matern]

Hallo,

was macht eigentlich dein UART-Problem vom 23.08.?

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

totalkalorien = kalorien + kalorien1 + kalorien2;

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

Aha.

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

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

totalkalorien = kalorien + kalorien1 + kalorien2;

wert = 1000;
sprintf(str, "%d", wert);
}

HTH, bye
Thomas

 

[Henning Paul]

Thomas Graf schrieb:

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

totalkalorien = kalorien + kalorien1 + kalorien2;

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

Mach mal die Variablendeklarationen _vor_ irgendwelche Anweisungen!

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 = preis + preis1 + preis2;

totalkalorien = kalorien + kalorien1 + kalorien2;

wert = 1000;
sprintf(str, "%d", wert);
}

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

Ah ja das UART Problem hab ich zwischenzeitlich auch lösen können.
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

 

[Michael Schöberl]

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

[...]

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

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

 

[Johannes Bauer]

Thomas Matern wrote:

Aha.

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

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<10; i++) printf("%d", i);
}
}

Gruß,
Johannes

 

[Johannes Bauer]

Michael Schöberl wrote:

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

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

 

[Thomas Graf]

Michael Schöberl wrote:

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

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

 

[Michael Roth]

Thomas Graf wrote:

Mach mal die Variablendeklarationen _vor_ irgendwelche Anweisungen!

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

 

[Michael Roth]

Henning Paul wrote:

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

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...

 

[Michael Roth]

Michael Schöberl wrote:

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

Johannes Bauer wrote:

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

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.

Der Algorithmus von Jan ist eigentlich die erste Wahl.

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.

Immernoch _viel_ effizienter als das sprintf Geraffel.

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.

 

[Michael Roth]

Johannes Bauer wrote:

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

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;
}

 

[Johannes Bauer]

Michael Roth wrote:

Michael Schöberl wrote:

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

Johannes Bauer wrote:

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

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.

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 von Jan ist eigentlich die erste Wahl.

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.

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.

Immernoch _viel_ effizienter als das sprintf Geraffel.

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

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).

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.

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