Hallo
Ich habe die Aufgabe ein Bluetooth Modul zu konfigurieren um damit eine
Kommunikation aufzubauen. (F2M03GLA)
Die Steuerkommandos müssen HEX Befehle sein. Das heisst ich habe zum
Beispiel den Befehl der so aussehen muss:
01 04 FF 00 55 AA
Jetzt bin ich verzweifelt am programmieren, aber finde keine Lösung
dazu. Im Datenblatt sind die Befehle ebenfalls als Hex-Befehle
aufgeführt, darum möchte ich eine Hex-Zahl eingeben (z.Bsp. 0xFF) und
dies auch so ausgeben: FF
Dies funktioniert leider nicht:
printf("%0.2x",0xFF); // Ausgabe: 66 66 anstatt FF
printf("%x",0xFF); // Ausgabe: 66 66 anstatt FF
printf("%x",255); // Ausgabe: 66 66 anstatt FF
Wie kann ich dies lösen?
Und wie könnte ich auch noch alles auf einer Programmcode-Linie
schreiben? (Damit ich nicht 10 printf Befehle nacheinander habe)
Danke @ all
Fux schrieb: > und das heisst im code? Das heisst vor allen Dingen erst einmal: C Buch kaufen
1 | unsigned char Byte = 0xFF; |
2 | |
3 | fwrite( &Byte, 1, 1, stdout ); |
Fux schrieb: > Dies funktioniert leider nicht: Du machst was anderes falsch. Bei mir geht das (Visual C++). > Dies funktioniert leider nicht: Woran siehst du das? Welchen Compiler und welche Zielplattform hast du? > Und wie könnte ich auch noch alles auf einer Programmcode-Linie > schreiben? (Damit ich nicht 10 printf Befehle nacheinander habe) Du meinst untereinander? Falls ja: lass die Zeilenumbrüche raus... :-o Fortgeschrittene nehmen dann eine for-Schleife dafür.
Ich benutze den C-Compiler C30 von Microchip, und uC ist der PIC24FJ128... Zu "C-Buch kaufen": Ja schon klar, eigentlich habe ich mit C gar keine Probleme, das ganze Programm ist mit IrDA Stack EEprom inkl. mirroring, Pumpenkalibrierung usw. wirklich ziemlich komplex, aber wenn es um solche Ausgaben geht bin ich Anfänger, das gebe ich ja zu.... :-) Ok, werde mal weiter probieren
> Dies funktioniert leider nicht: > > printf("%0.2x",0xFF); // Ausgabe: 66 66 anstatt FF > printf("%x",0xFF); // Ausgabe: 66 66 anstatt FF > printf("%x",255); // Ausgabe: 66 66 anstatt FF > das ist auch gut so ehrlich, %x erwartet eine Variable du gibst aber eine Konstante, Ich kann nur Raten was da passiert aber ich denke dein Programm übertragt einfach eine Adresse wo zufählig 0x66 drin steht was das ist kein plan. entweder so
1 | hex = 0xCD; |
2 | printf("%02X",hex ); |
oder aber mit ein wenig "Hashtable magic", Ich kenne dein Programm nicht aber printf ist ein ziemlich dickes brett auf das ich gerne verzichte auf sehr kleinen µC
1 | unsigned char highnibble; |
2 | unsigned char lownibble; |
3 | unsigned char hextable[] = { '0','1','2'. |
4 | '3','4','5'. |
5 | '6','7','8', |
6 | '9','A','B', |
7 | 'D'.'E','F', }; |
8 | }; |
9 | |
10 | highnibble = hextable[ ( hex & 0xF0 ) >> 4) ]; |
11 | lownibble = hextable[ ( hex & 0x0F) ]; |
jetzt kannst hast du in highnibble das erste Zeichen deiner Hex Zahl und in lownibble das zweite. beides könntest du un so ungefahr auf die Reise chicken
1 | send_sign('0'); |
2 | send_sign('x'); |
3 | send_sign(highnibble); |
4 | send_sign(lownibble); |
5 | send_sign(' '); |
wobei das send_sign eine passende Funktion dienes µC sein muss die auf geeigneten Weg (TM) ein Zeichen an dein bluetooth modul sendet.
> übertragt einfach eine Adresse wo zufählig 0x66
Argl. Da hat jemand nicht gemerkt, dass 'f' == '\x66' == 0x66.
Der printf ist natürlich zulässig und gibt zwei 'f' aus, wie er's soll.
Es besteht keine Notwendigkeit, das so unmäßig kompliziert auszudrücken
wie geschildert.
So an alle 9mal klugen: Ich weiss schon dass F = 0x66 ist usw., die Frage ist wie ich einen Befehl der in HEX steft, also zum Beispiel FF auch so auf das Modul bringe, PUNKT! Wenn ich dies wüsste müsste ich mir ja nicht alle so super schlauen Kommentare hier anhören!!! Danke an den Poster mit der Tabelle, das ist genau was ich gesucht habe, ohne grosses kauf dir ein C-Buch usw... Schönes Wochenende noch!
Imon schrieb: > das ist auch gut so ehrlich, %x erwartet eine Variable du gibst aber > eine Konstante, Ich kann nur Raten was da passiert aber ich denke dein > ... Sorry, das ist Quark.
Fux schrieb: > Danke an den Poster mit der Tabelle, das ist genau was ich gesucht habe, Das ist genau das was du nicht gesucht hast. Denn wwenn das dein Problem lösen würde, dann würde es ein simples printf( "%02X", 0xFF ); auch tun :-) (grosses X, nicht kleines x) Aber das sendet einfach nur 2 mal den Buchstaben F anstatt wie bei dir den Buchstaben f. Man kann allerdings getrost davon ausgehen, dass es dem Empfänger egal ist, ob du Gross- oder Kleinbuchstaben sendest. f ist F ist f ist dezimal 15. Wenn ein Empfangsprogramm dermassen pingelig ist, dass es da einen Unterschied zwischen Klein und Grossbuchstaben macht, dann kann man guten Gewissens den Programmierer, der es geschrieben hat, mit einem nassen Fetzen erschlagen. Daher denke ich: Es löst nicht dein Problem. > ohne grosses kauf dir ein C-Buch usw Mit deiner Antwort hast du eigentich nur noch mehr unterstrichen, dass du ein Buch brauchst. Aber was solls. Bis zum nächsten mal, an dem du anlassbedingt dir das nächste Halbwissen zusmmenfragst und immer noch keinen Überblick über C, seine Möglichkeiten und den Vorrat an Funktionalität hast.
Fux schrieb: > Danke an den Poster mit der Tabelle, das ist genau was ich gesucht habe, Wenn dir das hilft, dann viel Glück. Wenn nicht: werde dir erst mal klar, ob du a) Bytes mit dem Wert 0xFF etc. schicken willst, oder b) ASCII-Zeichen in der Art 'F', 'F', ' ' u.s.w.. Deine erste Frage würde ich als b) interpretieren, nur dann brauchst du printf und Konsorten (formatierte Ausgabe). Bei a) brauchst du etwas in der Art von fwrite, fputc (unformatierte Ausgabe).
Ich brauche das f aber nicht als ASCII Zeichen sondern als HEX-Wert!!! Mit einem Terminal Programm kann man da sehr schön sehen was die Ausgabe in Hex oder ASCII ist (Docklight.de)
Zeig mir bitte mal den, der C komplett versteht, und ich meine nicht eifach einige Schalufen usw. Aber was solls, danke an alle die mir helfen wollten, alle anderen Professoren sollten sich so schnell wie möglich eine eigene Firma aufbauen und sich nicht in Foren rumtreiben
Fux schrieb: > Ich brauche das f aber nicht als ASCII Zeichen sondern als HEX-Wert!!! Dann schicks als Hex-Wert unsigned char Byte = 0xFF; fputc( Byte, stdout ); fwrite( &Byte, 1, 1, stdout ); putc( Byte, stdout ); putchar( Byte ); write( stdout, &Byte, 1 ); macht alles dasselbe: Schickt eine binäre Repräsentierung von Byte über die Leitung. Und zwar so, wie sie als Bits im Byte vorliegen. Ohne zuerst eine Textrepräsentierung von Byte zu generieren.
Fux schrieb: > Ich weiss schon dass F = 0x66 ist usw. Ist es nicht (und hat auch niemand geschrieben). > Danke an den Poster mit der Tabelle, das ist genau was ich gesucht habe, Wie belieben ... Du wirst statt „66 66“ damit „46 46“ bekommen ... viel Vergnügen. Die wirkliche Lösung wurde ja schon gepostet.
Angehängte Dateien:
-
NullXff.gif
9 KB
Imon schrieb: > %x erwartet eine Variable du gibst aber eine Konstante Ich kann es nur nochmal wiederholen: Bei mir geht das, und ich hätte auch erwartet, dass das genau so geht.
Imon schrieb: > das ist auch gut so ehrlich, %x erwartet eine Variable du gibst aber > eine Konstante solltest vielleicht nochmal in dein Handbuch kucken printf("%x",0xFF); übernimmt eine Zahl als Argument, es ist egal, ob es eine Variable oder eine Konstante ist. anders wäre es bei Strings (printf("%s",pS)), da wird ein Pointer übergeben, das ist dann die Adresse, an dem der String im Speicher steht
:-)
Bin neugierig wie lange es dauert, bis der TO endlich an der Kernfrage
angelangt ist: Gibt es in einem Computer eigentlich so etwas wie Hex?
Gibt es einen Unterschied zwischen
unsigned char Byte = 0xFF;
und unsigned char Byte = 255U;
und unsigned char Byte = 0b11111111; // im Falle von gcc
lange Rede, kurzer Sinn - es wird am Compiler liegen, der %x nicht kennt. Kann sein, dass man das einstellen kann, kann sein, dass es gar nicht implementiert ist.
H.joachim Seifert schrieb: > lange Rede, kurzer Sinn - es wird am Compiler liegen, der %x nicht > kennt. > Kann sein, dass man das einstellen kann, kann sein, dass es gar nicht > implementiert ist. Ich schmeiss mich weg :-) Wenn das ernst gemeint war, dann bist du noch weiter vom eigentlichen Problem weg als es der TO ist. Wenn es nicht ernst gemeint war, dann war es immer noch ziemlich fies.
Ich werde aus euch leider nicht schlau... Sorry aber wollt ihr helfen oder euch über Leute lustig machen? Egal, ich werde mich dann eben selber darum kümmern aber wette mal, dass nicht 50% der Personen die hier Antworten einen uC auf dem Tisch haben sondern das nur am PC simulieren, aber wie es halt so ist, Siulation entspricht nicht der Realität... Ich poste dann meine Lösung wenn ich soweit bin
Interessanterweise könnte auch printf( "%c", 0xFF ); gehen. Also bei 0xFF wird es sicherlich funktionieren. Nur bei bestimmten Bytewerten könnte es Ärger geben, je nachdem ob das I/O System zb einen 0x10 durch die Sequenz 0x13, 0x10 ersetzt oder nicht.
in dem fall lässt sich das Problem so lösen:
bei 32 bit Integerbreite:
unsigned int zahl= 0xdead1234;
for(int i=0; i< 4; i++)
{
printf("%c", ((char * )"0123456789ABCDEF")[((char*)&zahl)[i] >> 16];
printf("%c", ((char * )"0123456789ABCDEF")[((char*)&zahl)[i] & 15];
};
sollte klappen, wenn alle Fehler draussen sind;)
qu schrieb:
1 | printf("%c", ((char * )"0123456789ABCDEF")[((char*)&zahl)[i] >> 16]; |
2 | *****
|
Vorsicht. Das könnte ins Auge gehen. Lieber auf unsigned char* casten.
> sollte klappen, wenn alle Fehler draussen sind;)
Abgesehen davon siehts gut aus :-)
So ist es ev. noch ein bischen eleganter ...
1 | printf("%c", (((unsigned char*)&zahl)[i] >> 16)["0123456789ABCDEF"]); |
obowhl ich zugebe: Geschmäcker sind verschieden.
> Mit einem Terminal Programm
Auweia... daher weht der Wind... :-(
HEX 0x66 0x66 = ASCII ff
Ist doch toll, funktioniert doch.
Nur die Darstellung im Terminal muß noch umgestellt werden.
qu schrieb: > &zahl)[i] >> 16 muss &zahl)[i] >> 4 heissen aber so wies aussieht, hat eggy recht: Karl heinz Buchegger schrieb: > Interessanterweise könnte auch > > printf( "%c", 0xFF ); > > gehen. Also bei 0xFF wird es sicherlich funktionieren. Nur bei > bestimmten Bytewerten könnte es Ärger geben, je nachdem ob das I/O > System zb einen 0x10 durch die Sequenz 0x13, 0x10 ersetzt oder nicht.
Fux schrieb: > Ich werde aus euch leider nicht schlau... Mehr als dir die Lösung auf dem Präsentierteller zu überreichen könenn wir auch nicht tun. > Sorry aber wollt ihr helfen oder euch über Leute lustig machen? Ein bischen Spass wird ja wohl noch erlaubt sein. > Egal, > ich werde mich dann eben selber darum kümmern tu das mal > aber wette mal, dass nicht > 50% der Personen die hier Antworten einen uC auf dem Tisch haben Die Wette hast du verloren > sondern > das nur am PC simulieren Spielt keine Rolle. Die Lösung sieht auf dem PC nicht anders aus als am µC > aber wie es halt so ist, Siulation entspricht > nicht der Realität... Eher: Das Können entspricht nicht dem Geforderten. > Ich poste dann meine Lösung wenn ich soweit bin Schön. Dann scrollen wir hoch und sehen nach, wer deine Lösung als erstes geopstet hat. Bin schon neugierig, wer gewinnt.
Angehängte Dateien:
Nochmals für alle, im Terminal Programm habe ich auf Hex umgestellt, und dezimal soll dann 255 gleich Hex FF sein, denn das Modul kennt nur HEX Kommandos (sieh beide Bilder
Fux schrieb: > Nochmals für alle, im Terminal Programm habe ich auf Hex umgestellt, und > dezimal soll dann 255 gleich Hex FF sein, denn das Modul kennt nur HEX > Kommandos Wir haben dich schon verstanden. Nur du verstehst die Lösungsvorschläge (die jetzt zumindest von meiner Seite aus) mindestens 2 mal gepostet wurden nicht.
Es funktioniert nicht, ob es am Compiler liegt oder an MEINER DUMMHEIT oder an was auch immer, Fakt ist dass ich nicht das richtige auf dem Terminal sehe, PUNKT. Und bezüglich auf dem PC funktioniert es gleich wie auf dem uC -> dann hast du noch nie einen uC programmiert, ausser ev. einem Lauflicht...
Fux schrieb: > Es funktioniert nicht, ob es am Compiler liegt oder an MEINER DUMMHEIT > oder an was auch immer, Du könntest ja mal deinen Code zeigen, so wie er jetzt aussieht, nachdem du dir einen Lösungsvorschlag von oben rausgesucht hast. Und bitte ein bischen mehr als nur 1 Zeile, ok? > Und bezüglich auf dem PC funktioniert es gleich wie auf dem uC -> dann > hast du noch nie einen uC programmiert, ausser ev. einem Lauflicht... :-) Mit einiger Sicherheit hab ich schon mehr programmiert als du. Das kannst du mir ruhig glauben. Vom µC bis rauf zum Grossrechner. Jeder hat so seine Spezialitäten. Aber das Problem, an dem du zur Zeit strauchelst, ist keines. Dein Problem besteht im Kern nämlich darin, dass dir der UNterschied zwischen rein binärer Übertragung und Übertragung durch vorherige Umwandlung in eine Textrepräsentierung nicht klar ist. Dein Gerät am anderen Ende der Leitung möchte (ofenbar) ersteres, du machst aber zweiteres.
mag für dich ja kein Problem sein, für mich schon, denn alles was hier gepostet wurde gibt nicht das gewünschte Resultat. Ich mach mal einige Screenshot davon
Dann bitte sage mir welche Lösungsvorschlag ich nehmen soll und ich sende Dir das was rauskommt
Eigentlich könntest du gleich dein Programm zeigen. Dann sparst du dir unter Umständen die Screenshots
Das ganze Programm ist nicht nötig, ich habe nur dieser Befehl dazu:
printf("%x", 0xFC); wird beim PUC auf die UART gelegt, welche über einen
RS232 Converter von FTDI an meinem PC angeschlossen ist und auf dem
Terminal sichtbar ist
Fux schrieb: > Es funktioniert nicht... Aber nicht, weil es nicht funktioniert, sondern wiel du es falsch programmierst. Der Witz ist: du willst gar keine Hexzahl (und schon gar nicht in ASCII) übertragen, sondern einfach irgend einen Wert. Und blöderweise macht aber printf() aus einer Zahl eine ASCII-Darstellung. > ...auf dem PC funktioniert es gleich wie auf dem uC... Ja, das tut es. Ein PC ist auch nur ein Prozessor mit Peripherie. Genauso wie ein uC.
Fux schrieb: > Nochmals für alle, im Terminal Programm habe ich auf Hex umgestellt, und > dezimal soll dann 255 gleich Hex FF sein, denn das Modul kennt nur HEX > Kommandos > Ich brauche das f aber nicht als ASCII Zeichen sondern als HEX-Wert!!! Bevor du dich hier mokierst, kannst du dir selbst an die Nase fassen. Hexadezimal ist nur eine Darstellung dessen, was du brauchst. Übertragen wird das Byte in Form von 8 Nullen oder Einsen. Wenn du also nicht weiß, was du tust, brauchst du nicht beleidigend werden. Außer bei KHB, der kriegt ja nicht mal eine Schraffur hin.
Fux schrieb: > printf("%x", 0xFC); Probiers einfach mal mit printf("%c", 0xFC); Und wenns dann funktioniert, überleg dir warum.
Fux schrieb: > printf("%x", 0xFC); Was denkst du eigentlich, warum wir uns schon die ganze Zeit darüber lustig machen, dass es mit %x nicht funktionieren wird. Und was hast du daraus gelernt. Offenbar nichts.
Klaus Wachtler schrieb: > Wenn du also nicht weiß, was du tust, brauchst du nicht beleidigend > werden. Außer bei KHB, der kriegt ja nicht mal eine Schraffur hin. Ich fass mich schon an die eigene Nase. Vielleicht sollte ich den Schnittpunkt nicht mittels double berechnen, sondern in Hex. Was meinst du?
Ich fass mich schon an die eigene Nase. Vielleicht sollte ich den Schnittpunkt nicht mittels double berechnen, sondern in Hex. Was meinst du? -> Ich habe den Modulus aus dem Quadrat genommen und über eine ASCII Tabelle berechnet, dann mit putchar ausgegen und es funktioniert, vielen dank an alle
Karl heinz Buchegger schrieb: > Was meinst du? Das wäre einen Versuch wert. Es erhöht zumindest die Trefferwahrscheinlichkeit bei ==
Fux schrieb: > dann mit putchar ausgegen und wenn du das Zeichen gleich mit putchar ausgibst ohne mysteriöse Berechnungen?
Klaus Wachtler schrieb: > Fux schrieb: >> dann mit putchar ausgegen > > und wenn du das Zeichen gleich mit putchar ausgibst ohne mysteriöse > Berechnungen? Pfeif auf den putchar. Mich interessiert die mysteriöse Berechnung! In dem geerbten Code vor mir wird soviel abstruses Zeug berechnet, da kommts auf eine mehr auch nicht mehr an. Mehr als auch nicht funktionieren kanns nicht.
Also es funktioniert mit:
printf("%c", 0xFC);
printf("%c", 0x00);
printf("%c", 0x2C);
Resultat:
01.10.2010 14:37:25.073 [RX] - FC 2C
Sorry wenn ich da was übersehen habe, aber ok funktionier ja so, nur
wird mir 0x00 so nicht ausgegeben, hat ad jemand eine Idee? Und diesmal
bitte ohne Schnittpunktberechnung... :-)
Sorry für meine lange Leitung, aber ich werde ja schliesslich dafür
bezahlt... :-)
Evtl. unterdrückt dein Terminalprogramm die 0. Ansonsten nimm putchar...
Klaus Wachtler schrieb: > Evtl. unterdrückt dein Terminalprogramm die 0. Evtl. hat das auch mit der Art der Stringterminierung von C zu tun... > Ansonsten nimm putchar... Das wäre auch eine Idee... ;-)
Lothar Miller schrieb: > Klaus Wachtler schrieb: > >> Evtl. unterdrückt dein Terminalprogramm die 0. > > Evtl. hat das auch mit der Art der Stringterminierung von C zu tun... > > > >> Ansonsten nimm putchar... > > Das wäre auch eine Idee... ;-) 0 wird nicht unterdrückt. Aber mit putchar versuche ichs mal
Fux schrieb: > 0 wird nicht unterdrückt. Ich meinte, dass das Senden eines Strings, der aus zwei Nullen besteht, nämlich einer binären 0, die dort hinein geprinted wurde und der abschliessenden Stringende-Null, ganz einfach schon abgebrochen wird, bevor das erste Zeichen gesendet wird.
printf() bricht ab, wenn im Formatstring eine 0 vorkommt, aber nicht wenn mit %c eine 0 ausgegeben wird.
> printf() bricht ab
Ich meinte nicht, dass die Funktion printf() abbricht, sondern: wenn ich
mit %c eine 0 in den String ausgebe, dann ist der resultierende String
an dieser Stelle zu Ende.
Ich vermute mal das printf() ist für die serielle Schnitte in etwa so
umgesetzt:1 | sprintf(string, "%c", 0); |
2 | rs232_puts(string); |
Und nach dem sprintf() sieht der String so aus: 0x00 0x00 ^ ^- Stringende 0 '------ Zeichen 0 Und was macht rs232_puts() aus dieser Zeichenkette?
Schwer zu sagen. In so einer Konstellation hast du sicher recht.
Aber wer weiß, wie es wirklich aussieht bei ihm?
Er redet immer von printf.
Auch so ein Beispiel wie man viel reden kann, ohne irgendwas zu sagen.
Aber macht nix, er kommt schon damit klar:
> ...eigentlich habe ich mit C gar keine Probleme...
Fux schrieb: > Also es funktioniert mit: > > printf("%c", 0xFC); > printf("%c", 0x00); > printf("%c", 0x2C); > > Resultat: > 01.10.2010 14:37:25.073 [RX] - FC 2C Was identisch ist mit: putchar (0xFC); putchar (0x00); putchar (0x2C); Was beweist, dass Dein Modul das gar nicht als lesbare Hex-Werte will, denn Du könntest alle 3 Werte auch in dezimal hinschreiben. Das würde genauso funktionieren. Im Datenblatt sind Hex-Werte angegeben - für den Menschen - nicht für das Gerät. Wieso beherzigst Du nicht die Ratschläge, die Dir KHB bereits gestern gab?
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.