Serielle Daten untersuchen

Louis schrieb:
> Was ist da los? Ob Hex oder ASCII ist ja egal,
> übertragen werden ja nur die binären Nullen und Einsen.
Ja, aber ob Hex/Binär oder ASCII macht da sehr wohl einen Unterschied...

> Kann es vielleicht sein, dass die Daten in einer bestimmten
> zeitlichen Reihenfolge verschickt werden?
Ich mache bei seriellen Übertragungen zwischen uCs gerne ein Timeout 
rein, das z.B. nach 500ms zuschlägt. Von Hand mußt du da dann schon 
schnell tippen...

Louis schrieb:
> Hi,
> ich hätte da 2 Fragen zur seriellen Schnittstelle, wäre nett wenn mir da
> jemand weiterhelfen könnte.
>
> 1) Über eine Software ist es mir möglich ein Gerät anzusteuern. Über das
> Hyperterminal habe ich die Strings der einzelnen Befehle abgefangen. Als
> ich allerdings über das Hyperterminal die Befehle an das Gerät senden
> wollte, tat sich nichts. Ich konnte das Gerät nicht wie mit der Software
> bspw. an- oder ausschalten. Was ist da los? Ob Hex oder ASCII ist ja
> egal, übertragen werden ja nur die binären Nullen und Einsen. Kann es
> vielleicht sein, dass die Daten in einer bestimmten zeitlichen
> Reihenfolge verschickt werden? Könnte man ja dann mit dem Oszi
> überprüfen, oder?

Die Daten werden wohl in einer bestimmten zeitlichen Reihenfolge 
verschickt. Wichtig zu wissen wäre aber, ob der Empfänger die Daten in 
einer bestimmten zeitlichen Abfolge erwartet (z.B. maximale Zeit 
zwischen zwei Bytes, maximale Zeit für den ganzen Befehl).
Und das siehst Du mit dem Oszi nicht.
Ausserdem kannst Du mit Hyperterminal nicht alle Zeichen senden (z.B. 
0x00 wird nicht gehen). Ev. Alternative HTerm.

>
> 2) Wenn ich nun die Daten über den UART eines Mikrocontrollers einlesen
> und bearbeiten will, in welcher Form liegen die Daten dann vor? Binär
> Null und Eins oder in Hex/ASCII? Kann man die Daten durch ein Befehl
> beliebig darstellen (Programmierung in C)?

Die liegen in der Regel als char oder als int vor. Diese können als 
Character oder als Zahl (dezimal oder hex, oder auch binär) dargestellt 
werden (z.B. mit printf()).

Louis schrieb:
> Danke für die schnelle Antwort!
> @Lothar:
>>> Ja, aber ob Hex/Binär oder ASCII macht da sehr wohl einen Unterschied...<<
> Inwieweit spielt das eine Rolle? Übertragen wird ja nur die 1 und 0,
> oder?

Was Lothar meint:
Wenn du vor dem Terminal sitzt machst es einen Unterschied.

Bei einer Binär-Übertragung musst du dann die Tasten drücken, die das 
gewünschte Bitmuster im ASCII Code haben. Und für so manches Bitmuster 
gibt es dann keine Taste, die du dafür drücken kannst.

Es sei denn natürlich, du benutzt ein Terminal wie zb HTerm, das man in 
einen Modus versetzen kann, dass man gezielt Bitmuster erzeugen kann.


ASCII Übertragung macht die Dinge da ein bischen einfacher. Du drückst 
die Taste '1', dann geht ein Bitmuster über die Leitung, und das 
angeschlossene Gerät versteht dann auch, dass das Zeichen '1' 
eingetrudelt ist und erzeugt für sich selber dann die entsprechende Zahl 
1.
Bei reiner Binärübertragung muss man im Terminal ein wenig tricksen, 
damit bitweise 00000001 über die Leitung geht, und das Gerät die bereits 
fertige Zahl 1 empfängt.

Mach das doch so:
Du nimmst drei serielle Schnittstellen.
Eine um das Gerät mit Originalsoftware zu beschicken, die anderen 2 zum 
sniffen.

Dann hängst du die RX-Pins der beiden übrigen Seriellen an das RX und 
das TX der zu beschnüffelnden Verbindung. Ein Programm, was dir parallel 
zu den Empfangsdaten auch einen Zeitstrahl anzeigt, gibt es zuhauf. Oder 
selber schreiben, vllt. kleine C-Progrämmchen die Textfiles generieren 
die z.B. in Excel importierbar sind.
mfg mf

Hallo,

FreeSerialPortMonitor z.B. http://www.serial-port-monitor.com/index.html
In der freien Version geht zwar nicht alles, aber zum mitloggen incl. 
Timestamp reichts alle mal.

Sascha

BinTerm

von http://www.MmVisual.de

Louis schrieb:
> Hallo zusammen,
> zunächst mal vielen Dank für die Tipps. Ich habs jetzt mal mit dem hTerm
> probiert. Wenn ich ein Befehl sende und den dann mit Hilfe des Terminals
> abgreife und über "Save Output" speichere, kann ich das Gerät durch
> "Send File" ansteuern. Wenn ich allerdings den Befehl wie im Bild in die
> Eingabeliste eingebe bzw. kopiere, und dann "ASend" verwende, passiert
> gar nichts. Kann mir evtl. hierbei jemand weiterhelfen? Was mache ich
> falsch?

Kann man so noch nicht sagen.
Sieh dir dein über "Save Output" abgegriffenes File noch mal in einem 
HEX Editor an. Es wäre möglich, dass da nicht darstellbare Sonderzeichen 
darin enthalten sind, die du an der Anzeige nicht siehst.
Auch fängt deine Mitschritft oben mit einem 'Quadrat' an (deutlicher 
Hinweis auf ein nicht darstellbares Zeichen) das du mit einem ? ersetzt 
hast.

Das Quadrat könnte jetzt daher kommen, dass das erste Zeichen einer 
Übertragung des öfteren mal verstümmelt ist. Wäre möglich, kann so sein, 
muss aber nicht so sein.

Bei der Entschlüsselung eines Protokolls fängt man im ersten Schritt 
immer damit an, sich zunächst die HEX-Bytes anzusehen. Da sieht man dann 
was tatsächlich Bytemässig über die Schnittstelle geht.
Hat man die HEX-Bytes vorliegen, dann vergleicht man mit einer ASCII 
Tabelle und sieht sich an, ab alle Bytes im ASCII Code druckbare Zeichen 
ergeben. Ausnahmen können höchstens noch Sonderzeichen wie ETX oder STX 
bzw. CR LF oder FF sein. Aber ausser diesen sollte nichts weiter 
enthalten sein. Sind Bytes mit gesetzten 7. Bit im Datenstrom, dann ist 
ASCII meistens aus dem Rennen, denn bei Gerätesteuerungen hat man es 
selten mit Kommandostrings mit Umlauten zu tun, sondern da wird ASCII 
verwendet und zwar so, wie Gott sich das so vorgestellt hat: Buchstaben 
A bis Z (auch in Kleinbuchstaben), Ziffern und ab und an einmal ein 
Sonderzeichen.
Das was dein hTerm Dump da suggeriert, deutet nicht besonders auf ASCII 
hin. Die wenigsten Firmen würden ASCII übertragung wählen und dann nur 
Ziffern hin und her schicken. Daher würde ich das ganze über Hex angehen 
und nicht über ASCII, wenn ich das entschlüsseln will.

Louis schrieb:
> Hallo KH,
> Danke für die Antwort. Also ich habs auch mal mit der Hex-Darstellung
> probiert, sprich:
> B0 32 37 31 30 37 33 42 46 0D
> Allerdings ohne Erfolg. Es will es einfach nicht klappen...

Und wenn diese Sequenz aus einem File heraus gesendet wird, dann 
funktionierts?

Wenn ja, dann schätze ich mal, das das Gerät sehr enge Timeouts gesetzt 
hat.

Louis schrieb:
> Genau,
> dann klappts...Allerdings verstehe ich nicht, warum das Senden aus dem
> File funktioniert. Mit den engen Timouts meinst du die zeitliche
> Reihenfolge in der die Bytes gesendet werden,oder?

Ganz genau.

Sofern natürlich das File 1:1 bytemässig wirklich exakt den gleichen 
Inhalt hat. Aber davon geh ich jetzt mal aus.

Louis schrieb:

>

Poste doch bitte einmal das gesicherte File.
Dann sieht man mal, was da wirklich über die Leitung geht.

Zur Abkürzung: da steht drin
°271073BF + CR

Louis schrieb:
> Die Frage ist jetzt
> nur, warum es mit HEX geht und mit ASCII nicht.
> Wird das nicht druckbare
> Zeichen "°" nicht von hterm gesendet, sodass mein Endgerät nicht weiß
> wann der Befehl kommt? Gruß
das Platzhalterzeichen, das in der ASCII Anzeige erscheint ist ja meist 
für alle "nichtdruckbaren" Zeichen das selbe, deshalb wird beim senden 
als ACSII entweder nicht's gesendet, oder eben dieses 
Platzhalterzeichen.
Deshalb kannst du hier nur mit HEX-Werten arbeiten, was bei einer 
Bearbeitung mit einem µC aber auch keine Rolle spielt.


Sascha

genau, und wenn du die Daten auf dem µC als String verarbeiten willst 
kannst du ja auch mit HEX-Werten arbeiten, solange du für die 
Kommunikation kein NULL-Byte brauchst.

Sascha

Louis schrieb:
> Genau, ist 10 Bytes (-->10 Zeichen jew. 1 Byte) groß, wie aus dem
> Screenshot zu sehen ist, da ist es schön zu sehen. Die Frage ist jetzt
> nur, warum es mit HEX geht und mit ASCII nicht. Wird das nicht druckbare
> Zeichen "°" nicht von hterm gesendet, sodass mein Endgerät nicht weiß
> wann der Befehl kommt? Gruß

Wenn du hTerm auf ASCII eingestellt hast und in die Zeile das hier 
eingibst:

B0 32 37 31 30 37 33 42 46 0D


dann sendet hTerm (weil ja auf ASCII eingestellt) das hier weg. (alle 
Zahlen sind Hexzahlen)

42 30 20 33 32 20 33 31 20 33 30 33 37 20 33 33 20 34 32 20 34 36 20 30 
44

also die ASCII Codes der einzelnen Zeichen, die den Text
B0 32 37 31 30 37 33 42 46 0D
bilden


Das ist aber genau das was du nicht brauchen kannst, du willst, dass 
über die Leitung die Bytes

B0 32 37 31 30 37 33 42 46 0D

gehen. Daher musst du hTerm mitteilen, dass du schon die Bytewerte hast 
und es nicht mehr für jedes Zeichen (zb 'B' zb '0' zb '3' zb 
Leerzeichen... ) die entsprechenden ASCII Codes heraussuchen soll.
Und genau das hast du mit der Umschaltung auf HEX gemacht.