Hallo liebe Forengemeinde. Ich habe mal eine frage bezüglich HTerm. Ich empfange über einen COM Port Daten von einem Mikroprozessor, die Daten sind aufgeteilt in ein Highbyte und einem Lowbyte. Diese werden alle nacheinander ohne Trennzeichen oder ähnliches gesendet und auch empfangen. Das sieht ungefähr so aus: 010401ff01450167 usw... Die ersten beiden zahlen ist das Highbyte, die zwei folgenden Lowbyte, und so weiter. Diese Daten möchte ich mit der Taste "save output" speichern und in Excel bearbeiten, einen Grapfen bilden. Nun möchte ich High und Lowbyte zusammen in einer Zeile stehen haben, und das alles untereinander. Also so: 0104 01ff 0145 0167, usw. Neben der Taste kann man noch einige save output Optionen vornehmen, ebensp etwas von mfsting. Was muss ich dort eingeben, damit mir die Daten in meinem gewünschten Format gespeichert werden? Vielen Dank schonmal, würdet mir echt helfen. Liebe grüße, Daniel
Icke ®. schrieb: > Setz einfach "New line every .. characters" auf zwei. Funktioniert nur auf dem Bildschirm.
Harald schrieb: > Funktioniert nur auf dem Bildschirm. Richtig. Das ist ja mein Problem. Das was ich auf dem Bildschirm sehe, wenn ich newline every x character mache, hatte ich gerne in der erstellten Datei.
Warum nicht ein z.B. Pythonscript schreiben was dir die Daten in dein gewuenschtes Format konvertiert?
Hallo Aniel, Aniel schrieb: > Diese Daten möchte ich mit der Taste "save output" speichern und in > Excel bearbeiten, einen Grapfen bilden. wenn Du Deine Daten sowieso in Excel zum Karpfen aufbereiten willst, wieso liest Du die Quelldatei nicht gleich mit VBA ein? Das ist gerade mal eine Schleife mit byteweisem Einlesen + Dateihandling (Aufmachen und Schließen).
Hallo. Vielen Dank für eure Antworten. Hab mal nach VBA gesucht und auch einiges gefunden. Nur steige ich da irgendwie nicht so recht durch. Hätte evtl. Jemand einen Beispielcode, der soetwas kann? Bin mir c und konsorten nicht vertraut... Bin ein mittelmäßiger Avr-Assembler programmierer :-D Ich mag es einfach zu wissen, was mein kleiner Chip macht, deswegen hab ich noch scheu vor C und C++, ebenso Basic.
Hallo, Aniel schrieb: > Ich mag es einfach zu wissen, was mein kleiner Chip macht, deswegen hab > ich noch scheu vor C und C++, ebenso Basic. dann laß doch Deinen kleinen Chip gleich selber das NewLine mitschicken bzw \r\n wenn es sowieso für Windows ist. Gruß aus Berlin Michael
Aniel schrieb: > Bin mir c und konsorten nicht vertraut... Dann mach's in C, ist auch kein Problem ;-) - Zwei Zeichen einlesen - Zwei Zeichen rausschreiben - \r\n rausschreiben - wieder von vorne bis eof
Hallo Aniel, Aniel schrieb: > Ich mag es einfach zu wissen, was mein kleiner Chip macht, deswegen hab > ich noch scheu vor C und C++, ebenso Basic. Das ist eine durchsichtige Schutzbehauptung aus dem Paket Arbeitsvermeidungsstrategie. Anbei erhältst Du ein lauffähiges, aber unfertiges Stück Code zum Spielen. In Excel machst Du folgendes: => Taste ALT F11 Einfügen Neues Modul Den Rest kannst Du Dir anhand der Hilfe in VBA erarbeiten. Das ist nur noch Umsetzen von ein bisschen Logik, die Du ja als AVR-Programmierer beherrschst. Alles wesentliche, also Dateihandling und Zellzugriff ist schon drin. Achtung: Die VBA-Hilfe im VBA-Editor ist nicht mit der Excel-Hilfe identisch!
1 | Sub log_lesen() |
2 | Dim y As Long 'Zeilenzähler in Excel-Tabelle |
3 | Dim beit As Byte 'Puffer für gelesenes Byte der Eingabedatei |
4 | Dim ffile As Long 'Handle für den Dateizugriff |
5 | Dim hier As Object 'Object, um Zellwerte beschreiben zu können |
6 | |
7 | Set hier = ThisWorkbook.Sheets("Tabelle1") 'hier ist eine Objectvariable
|
8 | |
9 | ffile = FreeFile() 'Handle holen |
10 | Open "E:\hilfe\transfer.txt" For Binary Access Read Lock Read As ffile |
11 | |
12 | y = 1 |
13 | Do Until EOF(ffile) |
14 | Get ffile, , beit |
15 | 'Das gelesene Byte als Attribut "Value" in die mit der Cells-Methode spezifizierte Zelle schreiben |
16 | hier.Cells(y, 1).Value = beit |
17 | y = y + 1 |
18 | Loop |
19 | |
20 | Close ffile |
21 | |
22 | End Sub |
:
Bearbeitet durch User
Vielen lieben Dank für deine Antwort :-) Ich probiere es demnächst mal aus. Bis dahin habe ich das Problem auf andere Art ersteinmal umschifft... Ich wandele die Werte in den Registern in Ascii-Zahlen um und schicke die über UART an den PC. Hinter jedem Wert hänge ich CR+LF an. Nur ist jetzt mein Baudrate nicht mehr ausreichend. 115200 Baud ist nun zu langsam. Hoffe, das sich das mit einem Bluetooth Modul und einer Baudrate annähernd 1000000 lösen lässt. Mal schauen, sonst habt ihr mir schon gute Ideen gegeben, z.b. wusste ich bislang nichts von VBA :-)
Hallo, Daniel schrieb: > Ich wandele die Werte in den Registern in Ascii-Zahlen um und schicke > die über UART an den PC. Hinter jedem Wert hänge ich CR+LF an. > Nur ist jetzt mein Baudrate nicht mehr ausreichend. 115200 Baud ist nun > zu langsam. Hoffe, das sich das mit einem Bluetooth Modul und einer > Baudrate annähernd 1000000 lösen lässt. UART über USB-RS232/TTL-Adapter? FTDI, CP2102, CH340 usw. können da auch bis 921600 bzw. 500kBit/1Mbit. Uaf der PC-Seite hängt es vom terminalprogramm ab, ob diese Baudraten setzen kann. 500kBit mit FTDI-USB-Adapter und einem Mega32 mit Baudratenquarz habe ich selbst schon in einem alten VB6.0-Programm genutzt. Gruß aus Berlin Michael
Aniel schrieb: > Ich empfange über einen COM Port Daten von einem Mikroprozessor, die > Daten sind aufgeteilt in ein Highbyte und einem Lowbyte. > Diese werden alle nacheinander ohne Trennzeichen oder ähnliches gesendet > und auch empfangen. Das sieht ungefähr so aus: 010401ff01450167 usw... > Die ersten beiden zahlen ist das Highbyte, die zwei folgenden Lowbyte, Daß dieses "Protokoll" inhärent kaputt ist, ist Dir klar?
Rufus Τ. F. schrieb: > Daß dieses "Protokoll" inhärent kaputt ist, ist Dir klar? Wie meinst du das? Denke mir, solange ich weiß, wie ich die Daten interpretiere, ist das doch ok oder nicht? Bitte um Aufklärung :-)
Entschuldigung wenn ich ein zweites Mal schreibe... Ist das evtl. So gemeint, falls ein Byte bei der Übertragung ausfällt, ich alle folgenden nicht mehr richtig interpretieren kann? Dann wäre der Ansatz in Ascii umzuwandeln und mit Zeilenumbruch zu versehen tatsächlich besser, da ein Zeilenumbruch nach einem kompletten umgewandelten 16 Bit wert kommt.
Daniel schrieb: > Ist das evtl. So gemeint, falls ein Byte bei der Übertragung ausfällt, Auch. Aber das Problem tritt bereits auf, wenn Du das sendende Gerät vor dem Start von HTerm bereits einschaltest. Woher willst Du wissen, welches der empfangenen Bytes welche Bedeutung/welchen Stellenwert hat? Du kannst Deine Daten nur dann halbwegs zuverlässig empfangen, wenn Du immer erst HTerm (und die Aufzeichnung damit) startest und dann Dein sendendes Gerät einschaltest. Deutlich besser ist die Verwendung eines eindeutigen Trennzeichens, um einzelne Telegramme/Datensätze voneinander zu trennen. Anhand Deiner Beschreibung ist nicht eindeutig zu erkennen, ob Du Binärdaten sendest oder eine hexadezimale Text-Repräsentation der Daten. In letzterem Falle liegt Deine "ASCII-Konvertierung" ja schon vor, da ist dann nur noch das Trennzeichen erforderlich: Statt
1 | 010401ff01450167 |
so:
1 | 0104\n |
2 | 01ff\n |
3 | 0145\n |
4 | 0167\n |
etc.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.