Forum: Compiler & IDEs BCD oder was ist das :-( ?


von AVRli (Gast)


Lesenswert?

Hallo...

ich hoffe mir kann hier einer einen Tip geben ich suche seit bestimmt 
einer Stunde hier im Forum doch ich finde nicht's was mich weiter 
bringt. Ich dachte meine Infos sind BCD Zahlen, das ist wohl ein Irrtum 
:-( Wie nennt man das folgende?

Ich schreibe mein PRG für einen ATmega16 mit GCC bekomme über die UART 
Schnittstelle folgende Bytes...

0x01
0x28

Das soll ein Wert von dezimal 128 sein. Prima...
0x01 * 100 + 0x28 = 128 Ok das würde ich nun noch verstehen wenn es denn 
stimmt. Ist das wirklich effektiv oder ginge es anders (schieben?) noch 
schneller?
Andersherum muss ich auch Daten in diesem "tollen" Format aussenden.
Also aus 1024 muß dann...

0x10
0x24

...werden. Warum macht man sich den Stress eigentlich?

Gruß AVRli...

von Grrrr (Gast)


Lesenswert?

AVRli schrieb:
> 0x01
> 0x28
>
> Das soll ein Wert von dezimal 128 sein. Prima...
> 0x01 * 100 + 0x28 = 128 Ok das würde ich nun noch verstehen wenn es denn
> stimmt.

Das stimmt soweit: 0x0128 ist die hexadezimale Darstellung einer 
16-Bit-BCD Zahl dezimal 128.

AVRli schrieb:
> 0x01 * 100 + 0x28 = 128 Ok das würde ich nun noch verstehen wenn es denn
> stimmt. Ist das wirklich effektiv oder ginge es anders (schieben?) noch
> schneller?

Diese Berechnung musst Du doch garnicht ausführen. Wenn Du 0x01 und 0x28 
empfängst, speicherst Du sie einfach ab.

AVRli schrieb:
> Andersherum muss ich auch Daten in diesem "tollen" Format aussenden.
> Also aus 1024 muß dann...
>
> 0x10
> 0x24
>
> ...werden.

Also, erst Division durch 1000, dann Rest durch 100 und wieder Rest 
durch 10 und der lezte Rest ist die Einer-Stelle.

AVRli schrieb:
> Warum macht man sich den Stress eigentlich?
Wenn z.B. Rundungsfehler beim Wechsel der Zahlenbasis zu vermeiden.

von Grrrr (Gast)


Lesenswert?

Grrrr schrieb:
> Diese Berechnung musst Du doch garnicht ausführen. Wenn Du 0x01 und 0x28
> empfängst, speicherst Du sie einfach ab.

Wobei Du eine Berechnung natürlich dann doch durchführen musst, wenn Du 
mit der so empfangenen Zahl noch weiterrechnen willst.

Dann aber wäre es etwa so:
1
char TausenderHunderter = 0x01;
2
char ZehnerEiner = 0x28;
3
int Zahl;
4
5
Zahl = (((int) TausenderHunderter & 0xF0) >> 4) * 1000 + 
6
((int) TausenderHunderter & 0x0F) * 100 + 
7
(((int) ZehnerEiner & 0xF0) >> 4) * 10 + 
8
((int) ZehnerEiner & 0x0F);

von Michael U. (amiga)


Lesenswert?

Hallo,

AVRli schrieb:
> Hallo...
>
> ich hoffe mir kann hier einer einen Tip geben ich suche seit bestimmt
> einer Stunde hier im Forum doch ich finde nicht's was mich weiter
> bringt. Ich dachte meine Infos sind BCD Zahlen, das ist wohl ein Irrtum
> :-( Wie nennt man das folgende?
>
> Ich schreibe mein PRG für einen ATmega16 mit GCC bekomme über die UART
> Schnittstelle folgende Bytes...
>
> 0x01
> 0x28
>
> Das soll ein Wert von dezimal 128 sein. Prima...
> 0x01 * 100 + 0x28 = 128 Ok das würde ich nun noch verstehen wenn es denn
> stimmt. Ist das wirklich effektiv oder ginge es anders (schieben?) noch
> schneller?
> Andersherum muss ich auch Daten in diesem "tollen" Format aussenden.
> Also aus 1024 muß dann...
>
> 0x10
> 0x24
>
> ...werden. Warum macht man sich den Stress eigentlich?
>
> Gruß AVRli...

Nennt sich Packed BCD. Sind letztlich die Dezimalwerte zu je 2 Stellen 
in ein Byte verpackt. Wozu? Einmal muß man nur jeweils die 4 Bit nehmen 
und 0x30 dazu addieren und hat den ASCII-Code, außerdem konnten 
Prozessoren wie z.B. der Z80 damit direkt rechnen. Da gab es dann einen 
Befehl, der das z.B. nach einer Addition wieder passend gemacht hat.

Gruß aus Belin
Michael

von AVRli (Gast)


Lesenswert?

Danke für Eure Antworten, vlt. steig ich jetzt dahinter was ich hier im 
Forum zu dem Thema finde.

Gruß AVRli...

von Karl H. (kbuchegg)


Lesenswert?

AVRli schrieb:

> Das soll ein Wert von dezimal 128 sein. Prima...
> 0x01 * 100 + 0x28 = 128

Vorsicht!
Da darfst hier natürlich nicht hex mit dezimal mischen

  0x01 * 0x0100 + 0x28 = 0x0128

von AVRli (Gast)


Lesenswert?

Karl heinz Buchegger schrieb:
> Vorsicht!
> Da darfst hier natürlich nicht hex mit dezimal mischen

Da hast Du recht, das habe ich da natürlich gemacht!

Also aus dem BCD Daten zum int Wert

0x01 // 0*1000 + 1*100
0x28 // 2*10 + 8

und zurück dann...

0x01 // 0 = 128 / 1000     1=128 / 100
0x28 // 2 = 128 / 10       8

Läuft... ob es effektiv ist weiß ich nicht... ;)

Gruß AVRli...

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
Noch kein Account? Hier anmelden.