binärwert in Hex wert umwandeln

Da ist nichts umzuwandeln. Die Binärdarstellung ist nur eine andere 
Schreibweise...

Erste Idee wäre:

1 * 2^0 bzw. (001)
1 * 2^1 bzw. (002)
1 * 2^1 bzw. (004)
1 * 2^1 bzw. (008)
1 * 2^1 bzw. (016)
1 * 2^1 bzw. (032)
1 * 2^1 bzw. (064)
1 * 2^1 bzw. (128)

Alles miteinander addieren und fertig müsste das Unterfangen sein. Viel 
Spaß!

Im allgemeinen indem du nichts machst.

Binärwert oder Hexwert oder Dezimalwert oder Oktalwert ist alles nur 
eine unterschiedliche Sicht auf den gleichen Zahlenwert im Register oder 
Speicher. Spezielle Zahlensysteme wie BCD mal aussen vor.

Wenn du Werte in Textform AUSGEBEN willst, d.h. eine spezielle Ansicht 
willst, dann musst du dich um das Format kümmern. Und bei der 
technischen Realisierung müsste man die verwendete Programmiersprache 
kennen...

Ein Byte enthält nur Nullen und Einsen. Wenn in einem Byte die Bitfolge

1

00101010

steht, dann ist das exakt dasselbe wie

1

2A (hexadezimal)

2

42 (dezimal)

3

52 (oktal)

Der Artikel Zahlensysteme ist leider (noch) ein bisschen dürftig, 
vielleicht mach ich mal was dran, wenn ich Zeit habe...

Stefan B. wrote:
> Und bei der
> technischen Realisierung müsste man die verwendete Programmiersprache
> kennen...
Hmmm, das "BYTE" oben lässt mich BASCOM erahnen...

der Windoofrechner kann das ganz gut... (wens nur ums umrechnen geht)

Johannes M. wrote:

> Hmmm, das "BYTE" oben lässt mich BASCOM erahnen...

Da hast du mehr Glück als ich. Hier regnet es schon stundenlang in 
Strömen und meine Glaskugel ist stark beschlagen.

Stefan B. wrote:
> Da hast du mehr Glück als ich. Hier regnet es schon stundenlang in
> Strömen und meine Glaskugel ist stark beschlagen.
Wie, Du hast die draußen stehen? Oder ist das so eine verspiegelte, die 
man sich auf nem Stock ins Blumenbeet stellt?

;-)

> es geht darum, dass ich den Wert über die UART Schnittstelle auslese.
> Diese frage ich mit dem Hyperterminal von Windows ab. Zurzeit gibt
> dieses mir sehr tolle Zeichen aus. Aber eigentlich sollte es in Hex
> erscheinen.

du willst also eine Zahl in einen String umwandeln...dazu gibt es die 
utoa()-Funktion, die kann auch unterschiedliche Zahlensysteme

http://www.mikrocontroller.net/articles/FAQ#Wie_kann_ich_Zahlen_auf_LCD.2FUART_ausgeben.3F

wobei die aber auch einfach die Suche und/oder google benutzen hättest 
können...

Marc wrote:
> Ok und wie benütze ich diese Funktion?
Echte Programmierer benutzen keine Funktionen. ;)

Ein Byte in eine ASCII-Darstellung im Hexformat umzurechnen ist ziemlich 
einfach:

1

void puthexbyte(uint8_t bt)

2

{

3

  uint8_t btnibble = (bt >> 4) & 0x0f;

4

  if (btnibble > 9)

5

    btnibble += 'a'-10;

6

  else

7

    btnibble += '0';

8

  sendchar(btnibble);

9

10

  btnibble = bt & 0x0f;

11

  if (btnibble > 9)

12

    btnibble += 'a'-10;

13

  else

14

    btnibble += '0';

15

  sendchar(btnibble);

16

}

Gruss
Andreas

Matthias Lipinsky wrote:
>>oder einfach H-Term statt des Windows Terminal verweden, der kann alles
>>darstellen.
>
> Das würde ich auch sagen. Das Hyperterminal ist Murks. Das stellt nur
> sichtbare Zeichen (ASCII) dar.

Kommt immer drauf an, was das Ziel ist.
Wenn es um Debuggen von Kommunikation geht, ist HTerm sicher nicht zu 
schlagen. Wenn es darum geht, das ganze tatsächlich wie ein Terminal 
einzusetzen (also als Ausgabemedium für ein Programm), ist IMHO HTerm zu 
technisch angehaucht.

Marc wrote:
> @Andreas
>
> Wenn ich das so in mein Programm einfüge, kommt ein Fehler beim
> Compaillieren.
>
> Fehler:
>  identifier "uint8_t" is undefined

du musst nach inttypes.h inkludieren

#include <inttypes.h>


> In Welche "Variable" muss ich meinen zu wandelnden Wert schreiben??

Gar nicht. Andreas hat sich selbst ein Ei gelegt. Er wollte eigentlich 
sagen: Echte Programmierer benutzen keine Funktion, die sie nicht selbst 
geschrieben haben (was zumindest eine fragwürdige Aussage ist).

Das ist nach wie vor eine Funktion, und wird auch als solche benutzt.

1

int main()

2

{

3

  ...

4

  puthexbyte( 23 );

5

  puthexbyte( 0x56 );

6

}

Karl heinz Buchegger wrote:
> Gar nicht. Andreas hat sich selbst ein Ei gelegt. Er wollte eigentlich
> sagen: Echte Programmierer benutzen keine Funktion, die sie nicht selbst
> geschrieben haben (was zumindest eine fragwürdige Aussage ist).

Das ist völlig richtig. Deshalb hatte ich auch ein ;) hinter die Aussage 
geschrieben, was soviel heißen sollte wie "Nicht ernst gemeint".

Gruss
Andreas

Dein Code lässt mich schaudern.
Man muss 40 Sekunden konzentriert hinschauen um sich zu vergewissern, 
dass du keinen CopyPaste Fehler mit all den ...HighLow ...LowHigh etc 
gemacht hast.

An dieser Stelle ist doch eine Funktion eine perfekte Waffe, das Chaos 
einzudämmen.

1

char toHexDigit( unsigned char Value )

2

{

3

  if( Value <= 9 )

4

    return Value + '0';

5

6

  return Value + '7';

7

}

8

9

10

...

11

12

                  UARTTXBuff[4] = '2';

13

                  UARTTXBuff[5] = '=';

14

15

                  UARTTXBuff[6] = toHexDigit( DataADCHighHigh );

16

                  UARTTXBuff[7] = toHexDigit( DataADCHighLow );

17

                  UARTTXBuff[8] = toHexDigit( DataADCLowHigh );

18

                  UARTTXBuff[9] = toHexDigit( DataADCLowLow );

19

20

                  UARTTXLen = 10;

21

                  UARTSendPacket();

22

...

Das ist nicht nur kürzer, es ist auch leichter sich davon zu überzeugen 
das er korrekt ist. Man sieht besser in welcher Reihenfolge die 
einzelnen Bytes gesendet werden und falls mal umgestellt werden muss ist 
das auch einfacher.

Solch wiederkehrende Muster, wie du sie im Original hattest, lohnen sich 
immer in Funktionen ausgelagert zu werden! Alleine dadurch, dass der 
Code kürzer und damit besser überblickbar ist, hat man schon an Qualität 
gewonnen!

Falls du übrigens genug Platz in deinem µC hast, kann man hier auch 
sprintf sinnvoll ins Spiel bringen (für nicht benutzten Flash kriegt man 
kein Geld zurück. Es lohnt also nicht, sich selbst ne Menge Arbeit zu 
machen, wenn dann ohnehin 50% des Flash brach liegen. Da kann man dann 
auch getrost solch eierlegende Wollmilchsäue wie sprintf zum Einsatz 
bringen)

1

   else if (UARTRXBuff[3] == (ModuleNr+'0') &&

2

            UARTRXBuff[4] == '.' &&

3

            UARTRXBuff[5] == '2' &&

4

            !IO)

5

  {

6

    NewDataD = FALSE;

7

    sprintf( UARTTXBuff, "EW%1d.2=%04x", ModuleNr, DataADC );

8

    UARTTXLen = 10;

9

    UARTSendPacket();

10

  }

Marc wrote:
> Das stimmt ich hab bisher immer assembler programmiert und Denke für C
> noch viel zu detailliert und kompliziert.

Dann wirds Zeit für Literatur.
Die C-Library ist nicht sehr umfangreich, aber die 10 oder 20 
wichtigsten Funktionen sollte man schon kennen um sie bei Bedarf richtig 
einzusetzen zu können.

Auch der ganze Bereich rund um String-Verarbeitung ist etwas, das man 
mit Versuch&Irrtum nicht richtig lernen kann.

Dann noch die Devise "Das ist mir jetzt an dieser Stelle zu kompliziert, 
dafür schreib ich mir eine eigene Funktion". Hochsprachen machen es 
einem Programmierer leicht, sich Funktionen für alles Mögliche zu 
schreiben. Dadurch, dass man sich um deutlich weniger kümmern muss als 
in Assembler (Register sichern, Argumente auf den Stack packen oder 
irgendwo im Speicher parken) ist es sehr viel einfacher ein Programm in 
kleinere, überschaubare Codeteile zu zerlegen. Der Codequalität, im 
Sinne eines lesbaren wartbaren Programms, kommt sowas immer zugute. Wenn 
dann doch mal der Fall eintritt, dass die Funktionsaufrufe zu 
kostspielig sind, gibt es immer noch Mittel und Wege, wie man das 
vermeiden kann.