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...
Stefan B. wrote:
> Und bei der> technischen Realisierung müsste man die verwendete Programmiersprache> kennen...
Hmmm, das "BYTE" oben lässt mich BASCOM erahnen...
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?
;-)
Hallo,
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.
Programmiersprache ist C
> 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
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:
>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.
HTerm, der Terminal kann alles.
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.
@Andreas
Wenn ich das so in mein Programm einfüge, kommt ein Fehler beim
Compaillieren.
In Welche "Variable" muss ich meinen zu wandelnden Wert schreiben??
Fehler:
identifier "uint8_t" is undefined
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.
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
chartoHexDigit(unsignedcharValue)
2
{
3
if(Value<=9)
4
returnValue+'0';
5
6
returnValue+'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)
>In Welche "Variable" muss ich meinen zu wandelnden Wert schreiben??
Da fehlen gravierende C Kenntnisse. Erstmal ein C Tutorial durch
arbeiten. Wenn man Funktionen nicht kennt kann man sie auch nicht
einsetzen.
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.