itoa in Großbuchstaben ausgeben

Lokus Pokus schrieb:
> Geht das so überhaupt?
Nein, so würde es gehen:

1

  char *p_str = itoa(toupper(irmp_data.address),s,16);

2

  while(*p_str)

3

  {

4

    *p_str = toupper(*p_str);

5

    p_str++;

6

  }

7

  lcd_puts(s);

Versuchs mal mit toupper(...)

Sry, blöder Fehler, der Code sollte so aussehen:

1

  char *p_str = itoa(irmp_data.address, s, 16);

2

  while(*p_str)

3

  {

4

    *p_str = toupper(*p_str);

5

    p_str++;

6

  }

7

  lcd_puts(s);

Danke euch.

jetzt würde ich der Ausgabe gerne noch führende Nullen voran setzen.

Also eigentlich immer auf 5 Zeichen auffüllen.

geht das nicht etwas kompakter?
Oder ist das so aufwändig weil ich hier mit HEX-Weerten arbeite?

Auf 5 Stellen füllen mit führenden Nullen:

   snprintf(s,sizeof(s)-1,"%05X",irmp_data.address);
   lcd_puts(s);

Einfacher gehts nicht.

Aber warum auf 5 Stellen? Der maximale Wert, den Du von IRMP bekommst, 
ist 4 stellig, nämlich 0xFFFF.

Also:

  snprintf(s,sizeof(s)-1,"%04X",irmp_data.address);
  lcd_puts(s);

Um anzudeuten, dass es sich um eine Hex-Zahl handelt:

  snprintf(s,sizeof(s)-1,"0x%04X",irmp_data.address);

Verbrät allerdings 6 Stellen auf Deinem Display. Achte darauf, das Array 
s[] groß genug zu wählen, also mindestens:

  char s[7];   // 6 Stellen + '\0'

Frank M. schrieb:
>   snprintf(s,sizeof(s)-1,"%04X",irmp_data.address);

Ich habe gerade mal ins Manual von snprintf() geschaut:

"The functions snprintf() and vsnprintf() write at most size bytes 
(including the terminating null byte ('\0')) to str."

Korrekt wäre demnach:

  snprintf (s, sizeof(s), "%04X", irmp_data.address);

Sonst könnte am Ende eine Stelle fehlen, wenn man das Array s[] von der 
Größe her genau passend macht.

Lokus Pokus schrieb:
> Jetzt hab ich schon folgendes Versucht:
> lcd_puts(itoa(toupper(irmp_data.address),s,16));
>
> Allerdings funkt das nicht.

Wäre eine schöne Übung um deine C Kenntnisse zu verbessern zu erkennen 
WARUM das so nicht funkt.
Kleiner Tipp: Was ist der Variablentyp der Eingangsvariable von itoa() 
und was ist der Ein und Ausgangstyp von toupper().

Schaulus Tiger schrieb:
> wenn man sich ein lcd_printf() schreibt, das die Zeichen direkt ausgibt

Oder ein lcd_putchar(), und dann fprintf() nehmen.

Habe mir letztens einen Mini-VT100-Emulator dafür geschrieben, dann
kann man auch Cursorpositionierung und Löschen gleich noch eingebettet
im Zeichenstrom erledigen.

Irgendwer schrieb:
> Und was passiert wenn du eine String bis aufs letzte Zeichen voll
> quetschst?
> Das abschließende Nullbyte fehlt und deine nachfolgende Funktion gibt
> solange Zeichen aus irgendwo im Speicher aus Zufall mal eine null kommt.

Unsinn. Kannst Du nicht lesen? Hier nochmal das Zitat aus dem Manual:

"The functions snprintf() and vsnprintf() write at most size bytes
(including the terminating null byte ('\0')) to str."

Das heisst:

  1. Es werden höchstens size Zeichen geschrieben
  2. Das letzte Zeichen ist immer '\0'

Ergo: Der String wird immer terminiert.

> Genaugenommen müsste noch eine s[sizeof(s)-1]=0; einfügt werden.

Doppel-Falsch:

 a) sizeof(s)-1 ist falsch: Du hast ein Zeichen zu wenig, weil
    snprintf() bereits mit '\0' terminiert - und zwar bereits
    an der Stelle sizeof(s)-2, wenn Du sizeof(s)-1 als Argument
    heruntergibst.

 b) Eigene Terminierung ist doppelt gemoppelt.

> Bei deiner Variante müsstest du das nach jedem snprintf machen!

Unsinn.

Du hast snprintf() nicht verstanden. Ich habe meine Korrektur doch genau 
mit dem Manual-Auszug begründet. Wie konnte Dir das entgehen?

Wahrscheinlich bist Du einer der Übervorsichtigen: Array vorsichtshalber 
128 Bytes groß, obwohl nur 16 Stellen benutzt werden. Da fällt Dir 
natürlich eine vorzeitige Terminierung von snprintf() an der Stelle 
sizeof(s)-2 gar nicht auf ;-)

P.S.
Du verwechselst das Verhalten offenbar mit strncpy(). Da hättest Du 
nämlich Recht, strcnpy() ist tatsächlich ziemlich fies in dieser 
Hinsicht. Es knallt den Target-String bis zur Stelle n-1 (inkl.) voll 
und terminiert dann tatsächlich nicht, wenn kein Platz mehr ist.

welche Variante ist nun die richtige?

Schrieb ich doch oben:

1

  char s[5];

2

  snprintf (s, sizeof(s), "%04X", irmp_data.address);

3

  lcd_puts(s);

die Großschreibung ist da jetzt aber nicht inkludiert.

Lokus Pokus schrieb:
> die Großschreibung ist da jetzt aber nicht inkludiert.

Klar: %x macht klein, %X macht groß. %04X füllt mit Nullen auf, bis das 
Ding insgesamt 4 Stellen hat.

Ist also eine Rundum-Lösung für Dich.

grundschüler schrieb:

Solange du sowas schreibst
>   x=(byteX%(65536>>(4*i)))/(4096>>(4*i));
sollte man den Leistungsvergleich erst mal links liegen lassen.

grundschüler schrieb:
> ist einfacher

hüstel, hüstel …

grundschüler schrieb:
>   x=(byteX%(65536>>(4*i)))/(4096>>(4*i));

Sag mal, weisst Du, was Du da tust?

65536 ist schon kein uint16_t mehr, da ist nämlich bei 65535 Schluss. Du 
shiftest also einen Long (falls der Compiler 65636 ohne "L" dahinter 
überhaupt versteht) um einen variablen Wert.

Da eine ATmega keinen Barrel-Shifter hat, kommt da eine gaaaaanz lange 
Schleife raus.

Das Ganze 2 mal. Das ist krass.

Variante A: 7792 Bytes

Das mach ich mit weniger als einem Zehntel.

> A erfüllt alle Anforderungen, ist einfacher und kürzer...

Von einfacher kann keine Rede sein.

Frank M. schrieb:
> falls der Compiler 65636 ohne "L" dahinter überhaupt versteht

Ja, macht er, muss er machen.

Aber das Ding taugt eher als Einstieg in den IOCCC denn als eine
allgemein anpreisbare Implementierung.

Dass ein printf nicht klein ist, ist von vornherein klar.  Aber
sofern man die paar Bytes mehr nicht gerade wirklich knausern muss,
weil man den falschen Controller für den Job gewählt hat (oder das
Pflichtenheft auf mysteriöse Weise sich mittlerweile verdoppelt hat ;),
dann hat man mit der printf-Familie auf jeden Fall eine Lösung, bei
der man ohne graue Haare schnell zum Ziel kommt, weil man sich auf
das Wesentliche konzentrieren kann, statt sich mit derartigen
Nebensächlichkeiten abquälen zu müssen.

Jörg Wunsch schrieb:
> Ja, macht er, muss er machen.

Ich erinnere mich noch an Zeiten, da musste man für F_CPU bei 8000000 
immer ein L dranpappen, damit es richtig übersetzt wurde ;-)

> Aber das Ding taugt eher als Einstieg in den IOCCC denn als eine
> allgemein anpreisbare Implementierung.

grundschüler hat etwas ähnliches kryptisches in "Projekte und Code" 
gepostet. Ein Source, den weder ein Mensch noch ein Compiler verstehen 
kann. Das grenzt schon an Unverschämtheit.

> Dass ein printf nicht klein ist, ist von vornherein klar.  Aber
> sofern man die paar Bytes mehr nicht gerade wirklich knausern muss,
> weil man den falschen Controller für den Job gewählt hat (oder das
> Pflichtenheft auf mysteriöse Weise sich mittlerweile verdoppelt hat ;),
> dann hat man mit der printf-Familie auf jeden Fall eine Lösung, bei
> der man ohne graue Haare schnell zum Ziel kommt, weil man sich auf
> das Wesentliche konzentrieren kann, statt sich mit derartigen
> Nebensächlichkeiten abquälen zu müssen.

Das sehe ich genauso. Gefragt war eine einfache Lösung. snprintf() 
ist eine einfache Lösung.

Wenn man die kürzeste Lösung haben will:

1

#include <stdint.h>

2

3

static uint8_t

4

itox (uint8_t val)

5

{

6

    uint8_t rtc;

7

8

    val &= 0x0F;

9

10

    if (val <= 9)

11

    {

12

        rtc = val + '0';

13

    }

14

    else

15

    {

16

        rtc = val - 10 + 'A';

17

    }

18

    return (rtc);

19

}

20

21

static void

22

itoxx (char * xx, unsigned char i)

23

{

24

    *xx++ = itox (i >> 4);

25

    *xx++ = itox (i & 0x0F);

26

}

27

28

static void

29

itoxxxx (char * xx, unsigned int i)

30

{

31

    itoxx (xx, i >> 8);

32

    itoxx (xx + 2, i & 0x0FF);

33

}

34

35

int

36

main ()

37

{

38

   char buf[5];

39

40

   uint16_t u = 1234;

41

42

   itoxxxx (buf, u);

43

   buf[4] = '\0';

44

}

Verbraucht gerade mal 224 Bytes im Flash, also weitab von der 
verkorksten Lösung von grundschüler. Ausserdem bietet es 1, 2 und 4 
stellige Ausgabe an :-)

Frank M. schrieb:
> Ich erinnere mich noch an Zeiten, da musste man für F_CPU bei 8000000
> immer ein L dranpappen, damit es richtig übersetzt wurde ;-)

Nö, machen die Leute nur aus Gewohnheit.

Für <util/delay.h> kann man auch 8E6 schreiben, dann spart man sich
das mühselige Zählen der Nullen. ;-)  <util/setbaud.h> braucht es aber
als Ganzzahl.

Jörg Wunsch schrieb:
> Frank M. schrieb:
>> Ich erinnere mich noch an Zeiten, da musste man für F_CPU bei 8000000
>> immer ein L dranpappen, damit es richtig übersetzt wurde ;-)
>
> Nö, machen die Leute nur aus Gewohnheit.
>


War da nicht irgendwas mit dem unsigned. Denn eigentlich lautet es ja

1

#define F_CPU 8000000UL

und das U für unsigned war wichtig. Ich kann aber nicht mehr sagen, bei 
welcher Berechnung da dann was schief ging. Könnte irgendwas mit 
Bitshifts zb bei Baudratenberechnung zu tun haben. Aber genaueres weiss 
ich auch nicht mehr.

Karl Heinz schrieb:
> War da nicht irgendwas mit dem unsigned.

Ja, das eher noch.  Kann sein, dass sonst ein Zwischenergebnis
mal negativ wird.  Hängt aber natürlich davon ab, was man mit F_CPU
noch so anstellt.  <util/delay.h> benutzt den Makro sowieso innerhalb
von Gleitkommaberechnungen, da ist das egal.

Karl Heinz schrieb:
> War da nicht irgendwas mit dem unsigned. Denn eigentlich lautet es ja
>

1

> #define F_CPU 8000000UL

2

>

> und das U für unsigned war wichtig.

Ja, kann tatsächlich so gewesen sein. Ich habs auch nicht mehr so genau 
im Kopf. Aber irgendwas war da mal. Ist aber schon ein paar Jährchen 
her.

Egal.

> int
> main ()
> {
>    char buf[5];
>
>    uint16_t u = 1234;
>
>    itoxxxx (buf, u);
>    buf[4] = '\0';
> }
> [/c]
>
> Verbraucht gerade mal 224 Bytes im Flash, also weitab von der
> verkorksten Lösung von grundschüler. Ausserdem bietet es 1, 2 und 4
> stellige Ausgabe an :-)

Kannst du mir das bitte erläutern wie ich das jetzt in meinem Beispiel 
umsetze?

Ist u jetzt der Wert den ich Umwandeln möchte oder die Anzahl der 
Null-Stellen?

Lokus Pokus schrieb:

> Ist u jetzt der Wert den ich Umwandeln möchte oder die Anzahl der
> Null-Stellen?

Du verzeihst, dass ich schmunzle.

Der Funktionsaufruf lautet

1

  itoxxxx (buf, u);

buf ist recht offensichtlich das char Array, in welches die ASCII 
Repräsentierung rein soll.

Was also wird u sein, wenn die Funktion einen Wert in eine ASCII 
Darstellung umwandelt?

Und warum hat die Funktion, die einen uint16_t in eine ASCII-Hex 
Darstellung umwandelt (4 hexadezimale Ziffern) 4 Stück x im Namen, 
während eine Funktion itoxx, die einen unsigned char umwandelt (2 
hexadezimale Ziffern) nur 2 x im Namen hat?
Konsequenterweise hätte Frank die Funktionen allerdings itoXXXX und 
itoXX genannt, denn die ASCII Repräsentierungen werden ja mit 
Grossbuchstaben gebildet. Aber ... das sei ihm mal nachgesehen :-)

Dann muß ich für die Funktion itoxxxx bereits den umgewandelten HEX Wert 
angeben oder wie?
Oder ersetzt es das ursprüngliche itoa?

Lokus Pokus schrieb:
> Dann muß ich für die Funktion itoxxxx bereits den umgewandelten HEX Wert
> angeben oder wie?
> Oder ersetzt es das ursprüngliche itoa?

es ersetzt das ursprüngliche itoa.

Was ist denn so schwer drann einfach mal

1

...

2

  char s[20];

3

4

  itoxxxx( s, 15 );

5

  lcd_puts( s );

in ein Testprogramm zu schreiben und nachzusehen, ob danach

1

000F

auf dem LCD steht?
D.h. die Zahl, ausgedrückt als Hex-Zahl, mit Grossbuchstaben, und auf 4 
Stellen aufgeblasen.

Mehr oder weniger funktioniert das.
Allerdings habe ich noch ein unerwünschtes Verhalten.

Die komplette Schaltung soll mit einer 3V Lithium Zelle betrieben 
werden.

Wenn ich die Funktion nun verwende:

1

char s[7];

2

3

dogm_cursor(0,2);

4

dogm_puts("A: ");

5

itoxxxx(s, irmp_data.address);

6

dogm_puts(s);

7

dogm_puts(" C: ");

8

itoxxxx(s, irmp_data.command);

9

dogm_puts(s);

dann verstümmelt es mir die Anzeige nach ein paar Ausgaben. Im 
Netzbetrieb passiert das nicht.
Ist diese Funktion nun so Performancelastig das dabei der AVR in die 
Knie geht?

Lokus Pokus schrieb:


> dann verstümmelt es mir die Anzeige nach ein paar Ausgaben.


Verstümmeln bedeutet?

> Im
> Netzbetrieb passiert das nicht.
> Ist diese Funktion nun so Performancelastig das dabei der AVR in die
> Knie geht?

Dem µC ist das grundsätzlich wurscht was er macht. Deswegen braucht er 
da auch nicht mehr Strom.

Schon mal frische Batterien probiert?

Tor Tor Tor schrieb:
> Lokus Pokus schrieb:
>> lcd_puts(itoa(toupper(irmp_data.address),s,16));
>
> lcd_puts(toupper(itoa(irmp_data.address,s,16)));

falsch.

Können wir diesen Nebenschauplatz jetzt bitte in Frieden ruhen lassen?
Das 'Problem' ist schon längst gelöst.

(Falls es interessiert. Es ist deswegen falsch, weil toupper keinen 
String konvertiert, sondern ein einzelnes Zeichen.)

Irgendwer schrieb:
> Scheit also durchaus abhängig von der verwendeten Implementation der std
> zu sein.

Wir schreiben das Jahr 2015, und seit C99 ist snprintf() genormt:

1

  7.19.6.5 The snprintf function

2

  Synopsis

3

4

1         #include <stdio.h>

5

          int snprintf(char * restrict s, size_t n,

6

                  const char * restrict format, ...);

7

  Description

8

9

2 The snprintf function is equivalent to fprintf, except that the

10

  output is written into an array (specified by argument s) rather

11

  than to a stream. If n is zero, nothing is written, and s may be a

12

  null pointer. Otherwise, output characters beyond the n-1st are

13

  discarded rather than being written to the array, and a null

14

  character is written at the end of the characters actually written

15

  into the array. If copying takes place between objects that overlap,

16

  the behavior is undefined.

Lokus Pokus schrieb:
> dann verstümmelt es mir die Anzeige nach ein paar Ausgaben.

Du hast vergessen, nach dem Aufruf von itoxxxx() den Buffer zu 
terminieren - so wie ich es im Beispiel von itoxxxx() auch verwendet 
habe.

Also:

   itoxxxx(s, irmp_data.command);
   buf[4] = '\0';

Das ist ein Unterschied zu itoa().

Anderenfalls kannst Du auch itoxxxx() (dann konsequenterweise auch 
itoxx()) selbst terminieren lassen:

1

static void

2

itoxx (char * xx, unsigned char i)

3

{

4

    *xx++ = itox (i >> 4);

5

    *xx++ = itox (i & 0x0F);

6

    *xx = '\0';               // NEU!

7

}

8

9

static void

10

itoxxxx (char * xx, unsigned int i)

11

{

12

    itoxx (xx, i >> 8);

13

    itoxx (xx + 2, i & 0x0FF);

14

    *(xx + 4) = '\0';               // NEU!

15

}

Dann brauchst Du nur

   itoxxxx(s, irmp_data.command);

aufzurufen und Du kannst Dir das:

   buf[4] = '\0';

schenken.

P.S.
In main.c des IRMP-Projekts sind genau diese itoxx()-Funktionen 
(mit interner Terminierung!) schon seit vielen Monaten vorhanden, um 
eine konkrete Anwendung von IRMP zu zeigen. Ich frage mich, wieso Du 
nicht sowieso darüber gestolpert bist.

Irgendwer schrieb:
> Beschreibung
>
> Sendet formatierte Ausgabe an einen buffer, der die in nsize angegebene
> Maximalgröße hat. Ist die Anzahl der auszugebenden Bytes:
>
> < nsize, so werden alle Zeichen einschließlich des abschließenden ‘\0’-
> Zeichens geschrieben.
>
> == nsize, so werden nsize Zeichen ohne das abschließende ‘\0’-Zeichen
> geschrieben.

Kannst Du dazu bitte eine Quelle nennen? Ich traue deutschen 
Übersetzungen von libc-Manuals nicht.

Das da oben beschriebene wäre das gleiche Verhalten, wie strncpy() es 
macht. Ich weiß aber, dass diese Implemenation für snprintf() dann 
falsch wäre.

> Scheit also durchaus abhängig von der verwendeten Implementation der std
> zu sein.

Nein, das ist ein Fehler. Es gibt Standards. Wenn diese nicht 
eingehalten werden, ist das einen Bug-Report wert.

asdfasd schrieb:

1

> char *

2

> itoh(char *buf, int digits, unsigned number)

3

> {

4

>     for (buf[digits] = 0; digits--; number >>= 4)

5

>         buf[digits] = "0123456789ABCDEF"[number & 15];

6

>     return buf;

7

> }

Sehr elegante Lösung, gefällt mir um einiges besser als mein eigenes 
itoxxxx() und verbraucht zudem nur die Hälfte des Flashs :-)

Ich werde diese Version direkt in meine Libs so übernehmen.

Danke,

Frank

super und wie wendet man das nun wieder an?
"number" ist die Anzahl der Nullen?
Digits der HEX-Wert?

Lokus Pokus schrieb:
> super und wie wendet man das nun wieder an?

Ist das wirklich so schwierig zu verstehen? Das erkennt man doch schon 
an den Typen und Namen der Argumente. Nimm Dir abends mal ein gutes 
C-Buch zur Hand. Grundlagen können nie schaden. Und wenn man das 
versteht, was man da anwendet, ist das auch nicht verkehrt.

> "number" ist die Anzahl der Nullen?

Nein.

> Digits der HEX-Wert?

nein.

number (deutsch "Zahl") ist die Zahl, die Du konvertieren willst.

digits (deutsch "Ziffern") ist die Anzahl der Ziffern, auf die die
       Ausgabe formatiert wird. Mit der Anzahl von Nullen hat das
       wirklich nichts zu tun. Bei 0x1234 gibts z.B. keine Nullen
       bei digits = 4. Jedoch gibts für die Zahl 0x12 genau 2 Nullen.
       Die Ausgabe ist dann nämlich "0012".

Hier hätte statt eines C-Buchs sogar ein Wörterbuch "deutsch-englisch" 
gereicht....

Was macht denn nun diese Funktion: "{ V24_CharOut (HexChars[aHex & 
0x0F]); }" nun genau?

>   for (buf[digits] = 0; digits--; number >>= 4) {
>     if((buf[digits] = '0'+(number & 0x0F))>'9'){buf[digits]+=7;}
>   }
> [/c]
> Eine while-Schleife wäre sowieso eleganter.

Diese Variante benötigt 2 Bytes mehr im Flash