Gefunden für hex ascii umwandeln - Zum Elektronik Forum |
| 1 - Videoansteuerung CTR -- Videoansteuerung CTR | |||
| |||
| 2 - ASCII Hex - Converter? -- ASCII Hex - Converter? | |||
| Hallo Leute,
kennt jemand von euch ein Prog mit welchem man ASCII- Zeichen in Hex umwandeln kann und umgekehrt? ... | |||
3 - PWM mit Attiny2313 will nicht so ganz -- PWM mit Attiny2313 will nicht so ganz | |||
| Danke für deine Mühe; ich stelle gerade fest, dass es ein Fehler ist, aufgrund von zu hoher Motivation spätabends noch Programmieren zu wollen.
Hab mich jetzt mal halbwegs ausgeschlafen drangesetzt und plötzlich kam mir die Erleuchtung: Code : Gn = Waitkey() Ledg = Gn Wobei Gn einfach ein Byte ist 
So, jetzt habe ich auch mehr Speicher frei 
Wollte zuerst mit ASCIIs arbeiten, da d... | |||
| 4 - ASCII Coder/Encoder IC gesucht -- ASCII Coder/Encoder IC gesucht | |||
| Hi,
sry wenn ich mich dumm ausgedrückt habe, bin noch Anfänger. (Übrigens sehr netter Umgang hier -.-"). Zahlen kann man ja einfach z.B. per BCD Code verknüpfen und dafür gibt es ja entsprechende Coder/Encoder. Ich würde halt gerne Binäre Zahlensysteme in Buchstaben wandeln (möglichst einfach). Hex geht ja nur bis F und ich habe halt an ASCII gedacht... @PhyMaLehrer: Du hast mich richtig verstanden danke für die gute Antwort. (An sowas könnten sich gewisse Leute ein Beispiel nehmen.) ... | |||
| 5 - Temperatursensor, weitere Schaltungen über RS232 -- Temperatursensor, weitere Schaltungen über RS232 | |||
| Hi Truddel,
ich weiss es zufällig 
In dem case 'S': - Teil wird das gemacht. Zuerst wird der Sensor angetriggert, dass er eine Messung durchführen soll, kurz später werden dann 8 Bytes aus ihm ausgelesen, im Array aucData zwischengespeichert und auch direkt "roh" zum Debuggen als Hex-Dump an der RS232 ausgegeben ( vSendUartHexByte( y ) ). Danach folgt die Berechnung: iTemp = (INT)aucData[1] * 256; iTemp |= aucData[0]; -> iTemp hat jetzt schon den vorzeichenbehafteten Temperaturwert * 2, man könnte diesen also jetzt schon auf 0.5° genau ausgeben. Es wird mithilfe von 2 weiteren ausgelesenen Werten die Temperatur auf 1/10° genau ermittelt ( siehe Datenblatt!) und dann auf der RS232 ausgegeben. Für die Ausgabe eines einzelnen Zeichens wird immer die Routine vSendUartByte() genutzt. + . und - werden direkt ausgegeben, die Ziffern immer in einer Konstruktion vSendUartByte( x + 0x30 ), denn 0x30 ist der ASCII-Code für '0', 0x31 = '1' usw. \r und \n sind linefeed / carriage return, damit das auf dem PC-Terminal hübsch aussieht. Gruß Stefan ... | |||
| 6 - usart c18 compiler -- usart c18 compiler | |||
| Hallo Racingsascha, Ich habe die richtige Baudrate eingestellt . RxD und TxD sind auch korrekt angeschloßen . Ich muss noch dazu sagen , dass ich Probleme nur mit Flaot-Zahlen habe( String , Dezimal , Hex und Binäre funktionieren ). Mein compiler wandert bloß nicht Float zu ASCII jedenfalls habe ich noch nicht rausgefunden , wie man das machen
kann. Ich hahe versucht eine "ftoa.c" in meinem Projekt einzufügen aber der compiler meldet sofort eine Fehlermeldung . Mensch es muss irgendwie gehen  Ich kann mir kein compiler vorstellen , der im USART Schnittstelle keine Float darstellt.
mfg Sascha ... | |||
| 7 - avrasm2: LWRD-Funktion gibt nur 1 Byte zurück? -- avrasm2: LWRD-Funktion gibt nur 1 Byte zurück? | |||
| Auch das geht, wenn man weiss wie man den Debugger aus der Textverarbeitung aufruft.
Haben wir auch gemacht, aber das war dann kein Crossassembler. Die späteren Versionen der Textverarbeitung (auf x86 Rechnern laufend), konnte man auch regulär in einen Hex-Editor-Modus umschalten um die eigenen Files zu verhunzen. Ausserdem war das Betriebsysstem in der Lage Textdokumente zu erkennen und hat routinemäßig fremde Programme, die mit den Formatangaben etc. nichts anfangen können, die Files ohne diese lesen lassen. Die bekamen dann also nacktes ASCII präsentiert. Wenn man den Rucksack mit den Formatangaben auch haben wollte, musste man eine spezielle Open-Mode wählen. Wenn man für einen anderen Prozessor Code erzeugt, braucht man ja eh noch externe Hardware, z.B. um die EPROMs zu brennen. Dann kann man auch ASCII-Daten transportieren. Die JEDEC-Files, die viele Entwicklungspakete erzeugen, sind ja nichts anderes. ... | |||
| 8 - Morsezeichen -- Morsezeichen | |||
Zitat : GeorgS hat am 27 Apr 2009 14:05 geschrieben : Der komplette ASCII-Satz geht nicht, hex? ... | |||
| 9 - PDU-Mode -- PDU-Mode | |||
| Hallo Rambodieschen,
Zitat : Leider bin ich nicht so Erfahren in C programmieren. Dann, nimms mir nicht übel, mache doch erstmal was anderes. Du machst hier Klimmzüge, die nicht nötig wären. Schon allein die Tatsache, die Bytes erstmal in einen 8 Byte langen String aus Nullen und Einsen umzurechnen kostet Zeit und Speicher. Dann diesen, ich nenne es mal Binärstring wieder zu zerteilen, in Hex umzurechnen etc. ist völlig fehl am Platze, da es wiederum Zeit und Speicher verbraucht. Speicher deshalb, weil du von anfang an einen Puffer reservieren musst - dynamisch holt man sich auf µControllern i.d.R. keinen Speicher. Bedenke folgendes: 7 Bytes nehmen in dieser Kodierung nur noch 8 Bytes ein, klar. Das kann man mit 15 Byte Puffer und ein paar Schiebeoperationen erledigen, ohne komplexe Umrechnungen vorzunehmen. Allein die Tatsache, dass in deinem Quelltext noch | |||
| 10 - UART Probleme -- UART Probleme | |||
| Das ist doch einfach, jetzt leiste du mal was; ich gebe dir eine Hilfestellung:
1. Wieviel Speicher wird für den Zielstring benötigt? 2. Die Basis vom Hexadezimalsystem ist? 3. und nochmal richtig nett von mir: ein Nibble entspricht genau einem Zeichen im Hexadezimalkode! Was ist also naheliegend zu tun? 4. wenn die Zahl größer als 0x9 ist, dann werden andere ASCII-Zeichen benötigt, nämlich a, b, c oder A, B, C. Welche Prüfung mus also stattfinden? Edit: Zitat : [...] wird daraus 01010100 und danach soll das ganze in ein Hex umgewandelt werden [...] Bitte nicht vom String der einzelnen Bits ausgehen. Das wäre zwar möglich, aber blödsinnig .
Der Prototyp sollte so etwa aussehen: unsigned char *hex8(unsigned char arg, unsigned char *buffer); Oder, etwas schöner: uint8_t *hex8(uint8_t number, uint8_t *dest); | |||
| 11 - Beamer-Steuerung über RS232 -- Beamer-Steuerung über RS232 | |||
| Also, "Hex"-Werte sind genauso Zahlen wie ASCII-Kodes, Dezimalzahlen oder Oktalzahlen. Eben nur mit einer anderen Schreibweise und Basis.
Daher ist es doch logisch, dass &H80 das gleiche ist wie 128 (positive Ganzzahl). In Basic schreibt man "Hexwerte", genauer Zahlen zur Basis 16 mit dem Präfix "&H". Zur anderen Frage: Zitat : die drei verschiedenen Werte 1D 00 00 bis 1D 01 00 Wieso drei? Ich denke, nur das mittlere, also erste Byte ändert sich. Wenn dem so ist, dann testest du die Bytes links und rechts davon auf &H1D und &H00. Wenn das zutrifft, kannst du das Byte in der Mitte auswerten. In C ist das einfach, in Basic muss man, soweit meine Kenntnisse stimmen, den Klimmzug über "mid" machen: if mid(eingabestring, 1, 1) = "\x1D" And mid(eingabestring, 3, 1) = "\x00" then if mid(eingabestring, 2, 1) = "\x00" then led_aus elseif mid(... | |||
| 12 - Delay Befehle verursacht grosses .hex file -- Delay Befehle verursacht grosses .hex file | |||
| Dem widerspricht allerdings das hier
Zitat : AVR Studio meldet, dass das .hex file zu gross für meinen AVR (ATmega48)ist. Der mega8 hat 4kB Flashlänge, demnach hat der Fragesteller entweder versucht, die ASCII-Werte aus dem *.hex-Inhalt zu brennen (klappt logischerweise nicht!) oder aber der Kode ist wirklich so megalang. Als ich mit C @AVR-Studio angefangen habe, habe ich auch mal die delay-Sachen benutzt, und auch bei mir war anschließend der comp. Kode extrem lang; eben zu lang. Was ich machen würde (und auch gemacht habe): Eine Funktion schreiben, die das per Assembler macht, ähnlich Benedikts Kode oben und wo bereits fertig berechnete Werte zum Verzögern benutzt werden, und nicht erst, wie ebenfalls schon erwähnt, erst zur Laufzeit berechnet wird, was davon mal abgesehen auhc ziemlich lange dauern kann. ... | |||
| 13 - FIFO / Ringbuffer -- FIFO / Ringbuffer | |||
| hi,
du kannst die 4 ausgänge einfach an 4 eingänge der mcu hängen, dann warten bis der controllanschluss high ist, (pollen oder per interrupt) und dann den port lesen. dann brauchst du einen zähler, der eben bis 4 zählt oder den port prüft ob das bitmuster für # anliegt und dann abbricht bzw die daten weiterverarbeitet, ich würde die 4 ziffern erstmal in 4 variablen oder array speichern. (alternativ nach jeder ziffer verarbeiten) du brauchst dann eine routine die aus deinen binärdaten hex oder ascii zeichen macht wenn du sie ausgeben willst, ansonsten kannst du sie in bitfeldern speichern und nur bei der ausgabe konvertieren. wenn sie also nur intern verarbeitet werden und nicht gespeichert oder ausgegeben sind bitfelder einfach zu handhaben. da du nur 4 bit brauchst läßt sich das prima in einem 16Bit wort abspeichern. gruss ... | |||
| 14 - welcher Atmel für Torzähler? -- welcher Atmel für Torzähler? | |||
Zitat : emitterschaltung , hmpf, hab bisher immer mit kollektorschaltungen gebastelt, Na sowas: BC327, Emitter an Masse, Basis über 470Ohm an µP, Last zwischen Kollektor und Plus. Plus darf dabei auch viel grö0er als +5V sein ! Zitat : weil sowas wie nen spezifischen treiber für den drucker den ich verwende hab ich ja dann nicht Wenn dein Drucker nicht gerade ein GDI- oder reiner Postscript-Drucker ist, wird er wohl losrennen, wenn du ihm ASCII-Text + CRLF (hex 0d, 0a )schickst. Laserdrucker brauchen auch noch ein Formfeed (hex 0c) als Zeichen, daß die Seite fertig ist und gedruckt werden kann. Unter Win98 kannst du das ganz gut ... | |||
| 15 - RS232 IRDA -- RS232 IRDA | |||
| Ich habe als IRDA Empfänger hab ich einen von ALPINE genommen, die werden in Autos verbaut für die Autoradios. Den Empfänger hab ich dann an ein MAX232 angeschlossen. Der IC wandelt den TTL Pegel der vom Empfänger ankommt in ein RS232 Pegel (+/- 15V). Das geht dann anschließend Direkt an die Serielle Schnittstelle vom PC.
Am PC hab ich mir ein kleines Programm geschrieben das mit alles anzeigt was an der Seriellen Schnittstelle ankommt. einmal in ASCII und einmal in HEX. Das wars.... | |||
| 16 - HiFi Verstärkerändnisfragen: Integer-to-Char für LCD und Dallas DS1821 (Temp.Sens.) -- HiFi Verstärkerändnisfragen: Integer-to-Char für LCD und Dallas DS1821 (Temp.Sens.) | |||
| Hallo liebe Leute,
ich benutze einen ATmega8535 mit CodevisionAVR und habe ein paar kurze Fragen: 1. Muss ich zwangsläufig meine umständliche Integer-zu-Char-Umwandlung benutzen, um Int-Werte z.B. vom Temperatursensor auf einem LCD auszugeben? Es gibt ja nur String- und Char-Output-Befehle.. Habe nämlich Schwierigkeiten mit meiner Lösung, die ich bei einer einfachen Sekundenanzeige benutzt habe (nur zum Testen), hier kurz das main (Kommentare waren für Azubi-Kollegen): while (1) { sekunden++; //Sekündliche Erhöhung von sekunden um 1 delay_ms(1000); x=1; //Zählvariablen für die Umrechnung von i=0; //Int zu Char (String) werden initialisiert j=0; while(sekunden>=x) //Umrechnung von sekunden (Int) in zeit[] (Char-Array) { zeit[i]=((sekunden/x)%10)+0x30; //Jede einzelne Stelle der Integer-Variable wird mit //Hex-30 addiert, denn laut ASCII-Tabelle liegt |
Im transitornet gefunden: Hex Ascii Umwandeln
|
Zum Ersatzteileshop Bezeichnungen von Produkten, Abbildungen und Logos , die in diesem Forum oder im Shop verwendet werden, sind Eigentum des entsprechenden Herstellers oder Besitzers. Diese dienen lediglich zur Identifikation! gerechnet auf die letzten 30 Tage haben wir 12 Beiträge im Durchschnitt pro Tag heute wurden bisher 11 Beiträge verfasst 13 Besucher in den letzten 60 Sekunden alle 4.62 Sekunden ein neuer Besucher ---- logout ----su ---- logout ---- |
xcvb
ycvb
0.0317490100861