Gefunden für ascii bytes umrechnen - Zum Elektronik Forum |
| 1 - Beamer-Steuerung über RS232 -- Beamer-Steuerung über RS232 | |||
| |||
| 2 - ComPort Netzwerkbrücke -- ComPort Netzwerkbrücke | |||
| Ist das bekannt, dass SAFARI bei diesem Forum Fehler bei der Anmeldung hat? (Permanentes neues anmelden?)
Ok. Ich bin ein gewaltiges Stück weiter gekommen! Das Problem ist gelöst. (Soll ich noch ne Grafik hochladen? Wo und wie kann ich das Thema schließen?) Das VEGAMET soll mit einem normalen Ethernet-Kabel (RJ45 glaub ich) an ein Modem angeschlossen werden. Das ist der Gedanken von VEGA. An der Stelle wo ich das einsetzte gibt es kein Internet. Also habe ich nun ein Signal (15V bis 3V und -15V bis -3V) am Ethernet-Ausgang (RS232). Dies wandel ich mit einem MAX232 (IC Baustein) so um, dass meine XBEE dieses Signal übertragen können (0 bis +3V). Das Funktioniert!!! Der zweite XBEE empfängt und wandelt es mit RS232-USB-Converter in ein USB Signal.... etwas primitiv aber funktional: mit einem HyperTerminal sende ich nun Befehle an den VEGAMET und der antwortet mir zyklisch (ASCII basiert). Die Antworten logge ich mit dem RS232-DataLogger mit und Speicher sie. Diese Datei (die Permanent beschrieben wird) kopier ich mir zyklisch (mit einer Batch-Datei) an einem Ort, wo ich diese auch bearbeiten kann.... Das einzige Problem ist: Diese Log-Datei wird immer größer.... selbst wenn ich sie kopiere, neu Speicher und durch ei... | |||
3 - gelöschter Zustand einer SD Karte -- gelöschter Zustand einer SD Karte | |||
| Hallo,
wie im Titel bereits angedeutet würde ich gerne wissen welchen Zustand die Bits einer SD Karte haben wenn sie gelöscht sind. Ich würde gerne eine Karte unformatiert mit einem µC beschreiben und dazu dann leere Bytes von beschriebenen Bytes unterscheiden können. Es wird ASCII verwendet, also kommen niemals Zeichen wie 0x00 oder 0xFF im "Text" vor. Prinzipiell könnte es mir eigentlich egal sein da ich die Karte sowieso vor dem Einsatz initialisieren (also löschen) muss, da SDHC Karten mit FAT32 ausgeliefert werden. Dennoch wäre der "Ruhezustand" der Bits interessant zu wissen um das gleich ordentlich ausprogrammieren zu können. Wikipedia meint zwar, dass der Ruhezustand eines NAND Flash "1" ist, aber wird das vom Speichercontroller möglicherweise invertiert, sodass ich dann "0" zum Löschen schreiben soll? Kennt sich jemand in dieser Richtung aus? Grüße Simon ... | |||
| 4 - Clock/Data auslesen über LPT -- Clock/Data auslesen über LPT | |||
| So,
erstmal, damit ich nicht immer "er": er heißt auch Martin. Also Martin hat geantwortet - und zwar sehr ausführlich. Zitat : Hi, mein Studium läuft wieder von daher werden die Antworten nicht mehr so schnell kommen ! Das Radio startet in dem es ENA kurz auf High legt --> wie Wake-Up und dabei die Adresse mitgibt. Sollte sich der Tacho angesprochen fühlen so wird er ENA in Folge ebenfalls auf High ziehen --> Empfangsbereit. Das Radio gibt jetzt den Takt und die Daten auf die Leitung (jeweils 1Byte). Nach jedem gesendeten Byte wird ENA wieder auf Low gelegt. Die Daten werden als ASCII- Code gesendet, wobei nicht alle Zeichen der Norm entsprechen (Text und Zahlen passen aber). Sofern weitere Bytes gesendet werden legt der Tacho ENA wieder auf High und das senden der 8-bit geht von vorne los. Das letzte Byte ist eine Prüfsumme über alle gesendeten Bytes. Sofern Du nur empfangen möchtest ist das aber n... | |||
| 5 - Gerät via RS232 ansteuern -- Gerät via RS232 ansteuern | |||
| Hallo,
Nochmal genauer: sind das ASCII-Werte oder redest du von binären Werten in Hexadezimalschreibweise? uint8_t ist die per ISO-Standard (afaik 99) festgelegte Bezeichnung für eine acht Bit lange Ganzzahl ohne Vorzeichen. Sie entspricht damit genau unsigned char. Wird char nur als Datentyp für ein Zeichen benutzt (weswegen er auch so heißt), dann ist sogar das Vorzeichen egal, uint8_t, int8_t, signed char und unsigned char eignen sich also alle für einfache Zeichen. Nur bei Arithmetik kann es fies werden, wenn das MSB falsch interpretiert wird (Vorzeichenbit). Edit: Typischerweise gibt man Bytes so an, wie du es oben gemacht hast, also in Hexadezimalrepräsentation, also zur Basis 16. In C kann man eine Zahl als Hexadezimalzahl angeben, indem man ein 0x davorsetzt. 1B 53 06 00 00 11 02 00 00 00 13 00 --> USART_putc(0x1b); USART_putc(0x53); USART_putc(0x06); USART_putc(0x00); USART_putc(0x00); USART_putc(0x11); USART_putc(0x02); USART_putc(0x00); USART_putc(0x00); USART_putc(0x00); USART_putc(0x13); USART_putc(0x00); Das macht man so meist nicht, sondern legt solche Muster im ROM ab: static prog_char... | |||
| 6 - AVR Programmierung, SysEx-Daten? -- AVR Programmierung, SysEx-Daten? | |||
| Es gibt keine Hexacodes.
Das, was du meinst, sind zwei ASCII-Zeichen aus {0,...,9,A,...,F}, die ein Byte kodieren, und zwar zur Basis 16. Wie bereits gesagt wurde, kann ein AVR erstmal nichts Spezielles, außer die Hardware zur Verfügung zu stellen. Die Hauptfunktion eines µCs liegt in seinem Programm und ob dieses den Anforderungen gerecht wird (*), ist einerseits durch das Können und die Erfahrung des Programmierers, andererseits natürlich durch die Hardware eingeschränkt. Die Nebenbedingungen hier sind unter anderem folgende: 1. auf welche Art und Weise kommen die Daten in den µC? Bei MIDI jawohl mit einer asynchronen seriellen Schnittstelle (uart), was die meisten, wenn nicht alle, AVRs hardwaremäßig verstehen. 2. Wie schnell kommen die Daten: entweder werden Frames erst eingelesen und bei einer erkannten STOP-Sequenz verarbeitet oder der Abstand zwischen zwei Bytes ist so groß, dass man die Daten "on-the-fly" verarbeiten kann. Das hängt zum einen von der Baudrate ab, zum anderen von der Taktfrequenz des Prozessors und nicht zuletzt von den Fähigkeiten des Programmierers. Für so spezielle Sachen kann man ganz tief in die Trickkiste greifen und mit ein paar Vergleichsoperationen auskommen auf Kosten der Programmgröße. 3. Wie ... | |||
| 7 - Parser unter Bascom? -- Parser unter Bascom? | |||
Zitat : An den Kommata könnte man sich orientieren... Ja, das wäre die passende Lösung  .
Eine andere Möglichkeit wäre auch, beim String hinten anzufangen, vorausgesetzt, die Position der Daten verändert sich nicht. Da ich nicht weiß, wie man das mit BASIC umsetzen kann, oder ob man dort überhaupt so schön durch Strings iterieren kann wie in vernünftigen Sprachen, würde ich vorne beginnen und alle Zeichen durchrattern und mit dem ASCII-Wert für das Komma vergleichen. Bei positivem Vergleich dann einen Zähler inkrementieren. Hat dieser den passenden Wert (also 6), dann speicherst du den Anfang der Information (Offset vom Stringanfang) und suchst das nächste Komma, welches quasi das Ende der interessanten Information darstellt und speicherst ebenfalls diese Position. Alternativ kannst du dir auch ein paar Bytes in einem String reservieren und die passenden Informationen dort hineinkopier... | |||
| 8 - 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 ... | |||
| 9 - Thermometer mit Atmega8 -- Thermometer mit Atmega8 | |||
Zitat : Macht der Atmega das von selbst,die Bytes anzeigen ohne das ich die ändern muss??Da wirst du sehrwohl mit eingreifen müssen! Da das Byte als INT8 definiert ist, sind die in diesem einen Byte 256 kombinatorisch möglichen Bitmuster den Zahlen von -128 bis +127 zugeordnet. Dein Display erwartet sich aber für jede angezeigte Stelle ein ASCII Byte, auch für das ev. nötige Minuszeichen davor oder das Komma als Trennzeichen der Nachkommastelle genauso wie die Nachkommastelle ansich. D.h., Du mußt den nummerischen Wert des einen Bytes in 1-3 ASCII Bytes umwandeln und an die Anzeige schicken. Sollte der Wert negativ sein, so ist die Darstellung komplementär (das höchstwertigste Bitmuster stellt den kleinsten negativen Wert dar) und für das voranstehende Minuszeichen muß auch noch ein ASCII Byte ans Display geschickt werden. Wenn Du dann noch die Kommastelle anzeigen willst, dann müssen dafür ebenfalls Zeichen generiert werden. Schöne Grüße Selfman ... | |||
| 10 - 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 | |||
| 11 - HD44780 LCD Ansteuern -- HD44780 LCD Ansteuern | |||
| Hallo genausowas habe ich grade gemacht.
Das Problem, dass du hast: es sind maximal 8 Bytes erlaubt. Ich habe folgende Bytes genommen, damit es klappt: 1. [ Begrenzung auf einer Seite 2. ] Begrenzung auf der anderen Seite 3. Strich oben/unten, sonst leer 4. ein | 5. zwei || 6. drei ||| 7. vier |||| 8. fünf ||||| Damit habe ich eine ordentliche ProgressBar gezaubert. Allerdings läuft das Programmmodul dazu auf einem Prozessor, der hervorragend mit großen Zahlen rechnen kann, denn es sind Multiplikationen und Divisionen/Modulodivisionen notwendig. Die kompliziertere Version bekommt nur noch eine struct, anhand derer sie dann die Progressbar auf dem Display zeichnet. Damit kann man viele machen, die auch die Skalierung selbstständig übernehmen. Finde grade die Kamera nicht. Edit Zitat : Aber wenn es nicht geht oder zu aufwendig ist, dann muss ich eben mit ASCII Zeichen arbeiten, sieht zwar nicht schö... | |||
| 12 - UART Probleme -- UART Probleme | |||
| Es ist halt verdammt viel Code zum lesen und ich wollte nicht jemand qualifiziertes verschrecken .
also gut: UART.c Code : #include <avr/io.h> #include <inttypes.h> #include <AVR/io.h> //Definition der Ports #include <string.h> #include <AVR/interrupt.h> #include <AVR/signal.h> #define BAUD 9600UL #define UBRR_BAUD ((F_CPU/(16UL*BAUD))-1) uint8_t buffer; char *UARTText; char UARTzeiche... | |||
| 13 - LED-Matrix 8x64 ansteuern -- LED-Matrix 8x64 ansteuern | |||
| Das ist garnicht so einfach in den alten Datenbüchern noch etwas zu finden, aber die heutigen LCD-Controller müssten auch soetwas enthalten.
Hier http://hw.cz/pdf/elatec_lcd_family.pdf z.B. ist soetwas auf der vorletzten Seite abgebildet, allerdings nur als 5x7 Matrix. Ein alter Trick um Speicherplatz zu sparen ist es ein Tag-Bit mitabzuspeichern. Für eine 5x7 Zeichenmatrix z.B. brauchst du ja nur 7 Bit eines Bytes. Das 8.Bit muss man aber nicht wegwerfen, sondern man kann es verwenden, den Controller anzuweisen die übrigen sieben Bits zwei oder drei Scans tiefer auszugeben. Auf diese Art sehen auch Unterlängen einer 5x7 Matrix vernünftig aus. Ansonsten laufen die Teile als "ASCII Character Generator" herum (Es gibt auch andere, z.B. für das japanische Kata Kana). Ausserdem ist im Grafikchip eines jeden PC soetwas versteckt, aber ich weiß leider nicht wie man diesen ROM vom Computer her auslesen kann. Auch im Betriebssysten selbst und diversen Programmen sind solche Zeichengeneratoren abgespeichert. Kannst ja mal den Gockel ein bischen befragen. | |||
| 14 - RS232 buffern ca. 20Byte mit einem IC? -- RS232 buffern ca. 20Byte mit einem IC? | |||
| Moin,
wie perl sagte, entweder Hardwarehandschake benutzen, das ist recht datensicher. Wenn das nicht möglich ist, dann muss man sich das Softwarehandshake Xon/Xoff anschauen, das geht aber nur, wenn die beiden dafür verwendeten Wörter (eben die Bytes Xon und Xoff ) nicht im sonstigen Datenstrom vorhanden sind. Das geht z.B. in den meisten Fällen dann, wenn es sich um reine ASCII-Zeichen handelt (ok, und die paar Steuerzeichen, die man für ein Terminal eben benötigt).
Wenn es sich um rein binäre Daten handelt, also alle 256 Bytes im Datenstrom vorhanden sind, ist das schlecht. Da programmiert man, wenn man damit rechnen muss, dass der Empfänger die Daten nicht schnell genug verarbeiten kann, dann einen Puffer, der beispielsweise im mikrokontrollereigenem RAM liegt. Kommen Daten an, wird in der ISR nur das Byte abgeholt, in einen bestimmten Bereich im RAM kopiert und ein bestimmter Zeiger auf die nächste Position gesetzt. Weiterhin wird eine Flagge gesetzt, die dann im Hauptprogramm darauf hinweißt, dass Daten im Empfangspuffer liegen. Hat dein µC zuwenig RAM oder du willst sehr viel puffern, dann nimmst du einfach einen kleinen SRAM-Baustein, die du aus älteren Mainboards ausbau... | |||
| 15 - Datenübertragung zwischen C-Control M-Unit und Atmega 8 -- Datenübertragung zwischen C-Control M-Unit und Atmega 8 | |||
| Also ich hab zwar auch nie bascom programmiert, aber ich hab ne c-control hier rumliegen, die Staub ansetzt ^^
Ich hab jetz beim Einlesen in die Materie also einen ähnlich unbefangenen Blick auf die Dinge wie tvgucker. Als allererstes möchte ich dich auf die seite http://avrhelp.mcselec.com/bascom-avr.html verweisen, falls du die noch nicht kennst. Beim sende Programm scheint mir so weit alles in Ordnung zu sein, Beim Programm das die Daten auf dem LCD anzeigt ist mir Spontan folgendes ins Auge gesprungen. Du Definierst die Eingabevariable A als "String", Benutzt jedoch zum Lesen vom Port das commando "Inputbin", Das liest so viele Bytes wie es braucht vom Port, In dem Fall meines Erachtens nach die Länge des Strings, die bei deiner Definition Aber 0 ist. Ich würde da auf jeden Fall als erstes mal den Datentyp der Variable auf Byte ändern, weil du dann sicher sein kannst, dass er nur versucht 1 Byte vom Port zu lesen. Gibt es eigentlich einen bestimmten Grund warum du "inputbin" benutzt und nicht "Input" ? Meines Erachtens nach ist ... | |||
| 16 - Bascom AVR Frage zu Arraynamen in Variablen -- Bascom AVR Frage zu Arraynamen in Variablen | |||
| Ja, du hast mich korrekt verstanden.
Wie man das mit Basic macht, weiß ich leider nicht, in Assembler könnte ich dir weiterhelfen. Sonst legst du halt einfach die Tabellen ins EEPROM, da kann ich dir dann auch sagen, wie das geht (da kenn ich noch die Zugriffbefehle). Wenn mich aber nicht alles täuscht, sollte auch ein Array als Tabelle mit den Werten für die Zeichen reichen. Das Array ist dann eben im schlimmsten Fall (=alle ASCII-werte von 0-255) 256*5 Bytes groß. Edit: Dim Kode[255] As String * 5 Am Anfang muss dann die Tabelle mit den Werten gefüllt werden, die als Konstanten irgendwo im ROM rumliegen. Deshalb macht es mehr Sinn, direkt im OM zu bleiben, ohne 768 Bytes im SRAM zu verschwenden. Nur musste dann rausfinden, wie man mit Basic auf Zellen im ROM zugreifen kann. Bedenke auch, dass das ROM nicht byte- sondern word-organisiert ist! [ Diese Nachricht wurde geändert von: DonComi am 23 Feb 2007 14:41 ]... | |||
| 17 - LCD TFT SEG LCD-TV 2700 / Yokohama -- LCD TFT SEG LCD-TV 2700 / Yokohama | |||
| So, wollt' nur mal einen Zwischenbericht loswerden:
1. Der SEG gibt tatsächlich auf dem DVI-Port 'ne EDID (über die DDC-Lines) aus. 2. Diese EDID ist ziemlicher Müll. D.h. wenn ich sie mir mit einem Editor angucke, dann schaut das bspw. so aus: Zitat : Time: 22:07:57 Date: Sa Mrz 19, 2005 ______________________________________________________________________ ______________________________________________________________________ VIEWSONIC CORPORATION EDID Version # 75, Revision # 173 DDCTest For: VES ______________________________________________________________________ ______________________________________________________________________ 128 BYTES OF EDID CODE: 0 1 2 3 4 5 6 7 8 9 ________________________________________ 0 | 00 F... | |||
| 18 - unbekanntes Programm entdeckt -- unbekanntes Programm entdeckt | |||
| Das öffnen der Datei geht nicht, also hier das Listing:
MC68HC711E9 Bootloader ROM 1 **************************************************** 2 * BOOTLOADER FIRMWARE FOR 68HC711E9 - 21 Aug 89 3 **************************************************** 4 * Features of this bootloader are... 5 * 6 * Auto baud select between 7812.5 and 1200 (8 MHz) 7 * 0 - 512 byte variable length download 8 * Jump to EEPROM at $B600 if 1st download byte = $00 9 * PROGRAM - Utility subroutine to program EPROM 10 * UPLOAD - Utility subroutine to dump memory to host 11 * Mask I.D. at $BFD4 = $71E9 12 **************************************************** 13 * Revision A - 14 * 15 * Fixed bug in PROGRAM routine where the first byte 16 * programmed into the EPROM was not transmitted for 17 * verify. 18 * Also added to PROGRAM routine a skip of bytes 19 * which were already programmed to the value desired. 20 * 21 * This new version allows variable length download 22 * by quitting reception of characters when an idle 23 * of at least four character times occurs 24 * 25 **************************************************** 26 27 * EQUATES FOR USE WITH INDEX OFFSET = $1000 28 * 29 0008 PORTD EQU... |
Im transitornet gefunden: Ascii Bytes Umrechnen
|
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 7 Beiträge im Durchschnitt pro Tag heute wurden bisher 0 Beiträge verfasst 29 Besucher in den letzten 60 Sekunden alle 2.07 Sekunden ein neuer Besucher ---- logout ----su ---- logout ---- |
xcvb
ycvb
0.0878798961639