Möglichst kurze Routine für Hex-to-ASCII-Conversion

[Alex V. (bastel_alex)]

Worum es geht:

auf einem AVR controller einen empfangenen 16 Bit Hexwert (hier vom ADC) 
zB. 0xA2FD in 4 ASCII Werte umwandeln: "A" "2" "F" "D" (zum Senden über 
UART).

Gibt es da EINFACHE KURZE routinen? Wenn ich jetzt anfange das 
umzusetzen wird es sicher wieder komplizierter als es sein muss...

[Alex V. (bastel_alex)]

Außerdem noch eine nebenfrage:
Ich schicke alles per ASCII, damit ich es dann einfach im CSV format 
speichern kann.

Schicke ich dann am ende jeder Zeile ein
- Carriage Return oder
- Line Feed oder
- Carriage Return + Line Feed?

[micha (Gast)]

Du nimmst ein 16 char Array mit [0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F] und 
nutzt jeweils ein Nibble des Datenwortes als index. Ist nicht schwer

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

micha schrieb:
> Du nimmst ein 16 char Array mit [0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F] und
> nutzt jeweils ein Nibble des Datenwortes als index. Ist nicht schwer

Hier mal die praktische Umsetzung:

// main conversion routine 
// table unfortunately needs to reside in RAM for now
char hextable[16] = "0123456789ABCDEF";
// very simple output to hex 
static void printbyte(const unsigned char data)
{
  uart_put(hextable[data >> 4]);
  uart_put(hextable[data & 0x0f]);
}
static void printword(const unsigned int data)
{
  printbyte(data >> 8);
  printbyte(data);
}

Es wäre auch möglich, die Hextabelle ins Flash zu setzen, und über 
pgm_read_byte drauf zuzugreifen. So kostet der Spass 16 Bytes im RAM für 
die Tabelle.

[Alex V. (bastel_alex)]

Dankesehr, das waren doch mal klare ansagen! :)

Und wie ist es konventionell mit den CR /LF am ende?

[Max G. (l0wside)]

Windows-Welt: CR+LF
Unix-Welt: nur LF

Ist letztendlich Geschmackssache.

Max

[Alex V. (bastel_alex)]

Danke!!

[Falk B. (falk)]

CR + LF, das ist das Standardformat aus DOS-Zeiten. Unix macht nur CR.

[innerand i. (innerand)]

Alex v. L. schrieb:
> Und wie ist es konventionell mit den CR /LF am ende?

Das hängt vom Betriebssystem ab.
Bei Windows Systemen ist es zum Beispiel CR + LF, bei Unixioden nur der 
LF.

[Cyblord -. (cyblord)]

innerand innerand schrieb:
> bei Unixioden nur der LF

Typisch, und wie kommt dann der Cursor wieder an den Anfang der Zeile?

[Udo S. (urschmitt)]

Falk Brunner schrieb:
> CR + LF, das ist das Standardformat aus DOS-Zeiten. Unix macht nur CR.

CR LF auch Windows (auch neue Apple?)
Nur CR hatte Apple früher
IBM (vor allem Host, aber auch AIX teilweise) unterscheidet zwischen 
Line Feed (LF) und New Line (NL)

[innerand i. (innerand)]

cyblord ---- schrieb:
> Typisch, und wie kommt dann der Cursor wieder an den Anfang der Zeile?

Magie.

[ich (Gast)]

cyblord ---- schrieb:
> innerand innerand schrieb:
>> bei Unixioden nur der LF
>
> Typisch, und wie kommt dann der Cursor wieder an den Anfang der Zeile?

Stimmt schon, was "innerand" sagt.
Bei Unix: LF
Bei Mac: CR
Bei DOS/Windoofs: CR+LF

[Peter D. (peda)]

char buff[4+2+1];

sprintf( buff, "%04X\r\n", val );

[Luther B. (luther-blissett)]

Array ist viel zu lang!

/*
$ avr-gcc -mmcu=atmega8 -DHEX_FUN -c -Os h.c && avr-size h.o
   text     data      bss      dec      hex  filename
     52        0        0       52       34  h.o
$ avr-gcc -mmcu=atmega8 -DHEX_TABLE -c -Os h.c && avr-size h.o
   text     data      bss      dec      hex  filename
     60       16        0       76       4c  h.o
$ avr-gcc -mmcu=atmega8 -DHEX_PROGMEM -c -Os h.c && avr-size h.o
   text     data      bss      dec      hex  filename
     76        0        0       76       4c  h.o
*/
#include <stdint.h>
#include <avr/pgmspace.h>

extern void put(char c); 

#if defined(HEX_TABLE)

 char hextable[16] = "0123456789ABCDEF";
 #define N2C(X) (hextable[X])

#elif defined(HEX_FUN)

 char n2c(uint8_t n) { return (n<10?n+'0':n+('A'-10)); }
 #define N2C(X) (n2c(X))

#elif defined(HEX_PROGMEM)

 char hextable[16] PROGMEM = "0123456789ABCDEF";
 #define N2C(X) (hextable[X])

#else 
#error "define HEX_FUN or HEX_TABLE or HEX_PROGMEM"
#endif

void put8(uint8_t n)
{
  put(N2C(n>>4)); 
  put(N2C(n&0xf)); 
}
void put16(uint16_t n) 
{
  put8(n>>8);
  put8(n);
}

[Luther B. (luther-blissett)]

char n2c(uint8_t n)
{
   n+='0';
   if (n>'9') n+=('A'-'0'-10);
   return n;
}

spart noch mal 2 byte.

[LTC1043 (Gast)]

Luther Blissett schrieb:
> char hextable[16] = "0123456789ABCDEF";

Sollte das nicht char hextable[17] = "0123456789ABCDEF";
                                ^
--------------------------------|

sein? Im String "0123456789ABCEDF" wird ja wohl noch die '/0' als 
Terminierung dazu gepackt

Cheers

[Karl H. (kbuchegg)]

LTC1043 schrieb im Beitrag #3499442:
> Luther Blissett schrieb:
>> char hextable[16] = "0123456789ABCDEF";
>
> Sollte das nicht char hextable[17] = "0123456789ABCDEF";
>                                 ^
> --------------------------------|
>
> sein? Im String "0123456789ABCEDF" wird ja wohl noch die '/0' als
> Terminierung dazu gepackt

Die allerdings keiner braucht.
Das Teil wird hier als ein Array von Charactern benutzt und nicht als 
String.

(Und es gibt eine Sonderregel in C: Ist die Initialisierung eines 
Char-Arrays  genau so groß, das alle Zeichen in das Array passen, dann 
hängt der COmpiler kein \0 hinten drann. Jetzt hab ich endlich mal ein 
Beispiel dafür, wo dieses Verhalten nützlich ist :-)

[Axel S. (a-za-z0-9)]

In vielen meiner Projekte findet sich diese kurze Funktion:

void hexout(uint8_t x)                                                          
{                                                                               
    register uint8_t d= (x>>4) & 0x0F;                                          
    putc(d + (d>9 ? 'A'-10 : '0'));                                         
    d= x & 0x0F;                                                                
    putc(d + (d>9 ? 'A'-10 : '0'));                                         
}

Da man einen längeren Integer i.d.R. problemlos in Bytes zerlegen kann, 
ruft man die Funktion einfach für jedes Byte einmal auf, beginnend mit 
dem höchstwertigen.

Selbstverständlich kann man statt putc() auch sendRS232() o.ö. 
verwenden. Und wenn man Klein- statt Großbuchstaben will, tauscht man 
das 'A' gegen ein 'a'.


XL

[Peter II (Gast)]

Axel Schwenke schrieb:
> In vielen meiner Projekte findet sich diese kurze Funktion:
>     register uint8_t d= (x>>4) & 0x0F;

hast du dir mal den erzeugten ASM code angeschaut? Das Register hatte 
bei mir mehr negative Auswirkungen, weil es dann dafür extra ein neues 
Register verwendet hat. Dabei steht der übergebene wert ja bereits in 
einem Register.

Schneller wird es damit auf jeden Fall nicht.

[Peter D. (peda)]

Karl Heinz schrieb:
> (Und es gibt eine Sonderregel in C: Ist die Initialisierung eines
> Char-Arrays  genau so groß, das alle Zeichen in das Array passen, dann
> hängt der COmpiler kein \0 hinten drann.

Ich bin immer zu faul zum Zählen.
Ich lass daher die Klammer leer und opfere das Byte.

Aber es ginge auch so:

#define STR "1245"

char y[sizeof(STR)-1] = STR;

[Axel S. (a-za-z0-9)]

Peter II schrieb:
> Axel Schwenke schrieb:
>> In vielen meiner Projekte findet sich diese kurze Funktion:
>>     register uint8_t d= (x>>4) & 0x0F;
>
> hast du dir mal den erzeugten ASM code angeschaut? Das Register hatte
> bei mir mehr negative Auswirkungen, weil es dann dafür extra ein neues
> Register verwendet hat. Dabei steht der übergebene wert ja bereits in
> einem Register.

Der übergebene Wert darf aber nicht direkt verändert werden, weil er ja 
zweimal gebraucht wird. Unten wird er daher nach r17 gerettet und die 
eigentliche Rechenarbeit wird in r24/r25 gemacht. Was sinnvoll ist, weil 
r24 ja gleich das Argument für den Aufruf von putc() enthalten muß. Ein 
weiterer Grund, das hexout()-Argument nach r17 zu retten.

> Schneller wird es damit auf jeden Fall nicht.

Nein. Es schadet aber auch nicht. avr-gcc erzeugt bei mir mit oder oder 
ohne register den gleichen Code. Interessant ist aber, daß man einen 
Maschinenbefehl sparen kann, wenn man den Ausdruck

putc(d + (d>9 ? 'A'-10 : '0'))

ausführlicher (aber nicht unbedingt lesbarer) so schreibt:

d+= '0';
if (d > '9')
  d+= 'A'-10-'0';
putc(d)

Hier ist was avr-gcc im Optimierungslevel -Os erzeugt:

void hexout(uint8_t x)                                                          
{                                                                               
 3e4:   1f 93           push    r17                                             
 3e6:   18 2f           mov     r17, r24                                        
    register uint8_t d= (x>>4) & 0x0F;                                          
 3e8:   98 2f           mov     r25, r24                                        
 3ea:   92 95           swap    r25                                             
 3ec:   9f 70           andi    r25, 0x0F       ; 15                            
    lcd_putc(d + (d>9 ? 'A'-10 : '0'));                                         
 3ee:   9a 30           cpi     r25, 0x0A       ; 10                            
 3f0:   10 f4           brcc    .+4             ; 0x3f6 <hexout+0x12>           
 3f2:   80 e3           ldi     r24, 0x30       ; 48                            
 3f4:   01 c0           rjmp    .+2             ; 0x3f8 <hexout+0x14>           
 3f6:   87 e3           ldi     r24, 0x37       ; 55                            
 3f8:   89 0f           add     r24, r25                                        
 3fa:   fe d2           rcall   .+1532          ; 0x9f8 <lcd_putc>              
    d= x & 0x0F;                                                                
 3fc:   91 2f           mov     r25, r17                                        
 3fe:   9f 70           andi    r25, 0x0F       ; 15                            
    d+= '0';                                                                    
 400:   89 2f           mov     r24, r25                                        
 402:   80 5d           subi    r24, 0xD0       ; 208                           
    if (d>'9') d+= 'A'-10-'0';                                                
 404:   8a 33           cpi     r24, 0x3A       ; 58                            
 406:   08 f0           brcs    .+2             ; 0x40a <hexout+0x26>           
 408:   89 5f           subi    r24, 0xF9       ; 249                           
    lcd_putc(d);                                                                
 40a:   f6 d2           rcall   .+1516          ; 0x9f8 <lcd_putc>              
}                                                                               
 40c:   1f 91           pop     r17                                             
 40e:   08 95           ret

In Assembler hätte ich den Teil übrigens anders geschrieben:

  andi r24, 0x0F
  ldi r25, '0'
  cpi r24, 10
  brcs +2
  ldi r25, 'A'-10
  add r24, r25
  rcall putc

genauso kurz wie die kürzere Variante oben, aber IMHO lesbarer. Und am 
Ende der Funktion hätte ich das ret noch weggespart ;)

  pop r17
  rjmp putc

XL

[W.S. (Gast)]

Peter Dannegger schrieb:
> sprintf( buff, "%04X\r\n", val );

Tja Pete, Thema verfehlt ürde ich sagen. Es ging nicht um eine 
minimalistische Quellzeile, sondern um eine "EINFACHE KURZE" Routine.
Ich denke, der TO meinte sowas:

const char HexChars[17]   = {"0123456789ABCDEF"};
/* ein Hex-Zeichen ausgeben */
void Nibble_Out (int aHex)
{ V24_CharOut (HexChars[aHex & 0x0F]); }

/* ein Byte als Hexa ausgeben */
void HexB_Out (byte aHex)
{ Nibble_Out (aHex >> 4);
  Nibble_Out (aHex);
}

/* ein Word als Hexa ausgeben */
void HexW_Out (word aHex)
{ HexB_Out (aHex >> 8);
  HexB_Out (aHex);
}

/* ein DWORD als Hexa ausgeben */
void HexL_Out (long aHex)
{ HexW_Out (aHex >> 16);
  HexW_Out (aHex);
}

/* ein QWORD als Hexa ausgeben */
void HexQ_Out (int64* aHex)
{ HexL_Out (*aHex >> 32);
  HexL_Out (*aHex);
}

zitiert aus der Lernbetty..  ;-)

W.S.

[Yalu X. (yalu) (Moderator)]

Axel Schwenke schrieb:
> Und am Ende der Funktion hätte ich das ret noch weggespart ;)
>   pop r17
>   rjmp putc

Das hätte der GCC 4.7+ auch ;)

[Luther B. (luther-blissett)]

W.S. schrieb:
> Peter Dannegger schrieb:
>> sprintf( buff, "%04X\r\n", val );
>
> Tja Pete, Thema verfehlt ürde ich sagen. Es ging nicht um eine
> minimalistische Quellzeile, sondern um eine "EINFACHE KURZE" Routine.
> Ich denke, der TO meinte sowas:
>
> const char HexChars[17]   = {"0123456789ABCDEF"};

Lies den Thread noch mal durch. Die Kovertierung über einen Arraylookup 
ist schon diskutiert worden. Du findest dort auch einen Post der 
erläutert, warum du für den HexChar Array keine 17 bytes brauchst.

[Peter D. (peda)]

W.S. schrieb:
> Tja Pete, Thema verfehlt ürde ich sagen. Es ging nicht um eine
> minimalistische Quellzeile, sondern um eine "EINFACHE KURZE" Routine.

Nö, es ging ihm genau um den Quelltext, daß der nicht zu kompliziert 
ist:

Alex v. L. schrieb:
> Wenn ich jetzt anfange das
> umzusetzen wird es sicher wieder komplizierter als es sein muss...

Das mit "wenig Flash" haben nur andere fälschlich hinein interpretiert.

[Luther B. (luther-blissett)]

Peter Dannegger schrieb:

> Das mit "wenig Flash" haben nur andere fälschlich hinein interpretiert.

Das stimmt allerdings :)