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? 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)? Viele Grüße Louis
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()).
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?
Gruß
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.
Louis schrieb: > Inwieweit spielt das eine Rolle? Übertragen wird ja nur die 1 und 0, > oder? HEX 14 = Binär 00010100 ASCII 14 = Binär 00110001 000110100 Dezimal 14 = Binär 00001110
> 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? Wie geht man da ran? Kann man das auch noch irgendwie anders überprüfen, als mit einem Oszi. Hab nämlich in etwa das selbe Problem. Gruß
serielle schnittstelle kann alles sein. wenn du eia-232 meinst, das ist standardisiert.
Ich meine wenn die Daten in einer verschiedenen Reihenfolge versandt werden. Beim Ansteuern meines Gerätes mit HTerm kann ich mit den abgegriffenen Strings, das Gerät nicht ansteuern. Ich denke, dass die Daten in einer bestimmten zeitl. Reihenfolge gesendet werden. Kann ich das nur mit dem Oszi überprüfen?
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
Hi Jo, danke für die Antwort, werde ich morgen gleich mal ausprobieren. Hast du mir da vielleicht noch ein Tipp zwecks einem geeignetem Programm wo man die zeitlichen Reihenfolge/Übertragung erkennen kann? Am besten natürlich ne Feeware:-) Gruß
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
Angehängte Dateien:
-
Screenshot.png
32 KB
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? Gruß
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.
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... Gruß
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.
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? Grüße
>Genau, dann klappts...Allerdings verstehe ich nicht, warum das >Senden aus dem File funktioniert. Zeig das File doch mal.
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.
>Sofern natürlich das File 1:1 bytemässig wirklich exakt den gleichen >Inhalt hat. Aber davon geh ich jetzt mal aus. Bei Asend vieleicht mal bei "Type" auf Hex oder Bin umschalten und die Leerzeichen weglassen?
Angehängte Dateien:
-
10000.png
32 KB
Hi zusammen, also ich hab jetzt den Typ auf Hex umgestellt, und siehe da, es funktioniert. Ich kann also nur bei Asend über Hex die Daten versenden. Allerdings kann ich den Befehl unter ASCII auch abspeichern (SaveOutput) und unter Send file problemlos verschicken. 1)Könnte es sein, dass das Terminal den Befehl dann automatisch in Hex umwandelt? 2) Warum klappt das nicht in ASCII oder in Bit? Bei ASCII liegts wohl an den nicht druckbaren Zeichen. Also dieses Quadrat am Anfang und das Carriage Return am Schluss. Beim Versenden mit ASCII hab ich also nur 271073BF verschickt. Mein Endgerät wusste also nicht wann der Befehl beginnt und wann er aufhört, so weit richtig?. Mit Hex hab ich nur "druckbare" Zeichen, also die komplette Bitfolge der einzelnen Zeichen für Befehlanfang und -Ende werden übertragen. Warum geht das aber nicht, wenn ich das mit Bit versende? Im Grund werden ja nur die binären Einsen und Nullen übertragen...Irgendwie kapier ich das immer noch nicht so ganz. Grüße
Louis schrieb: > Poste doch bitte einmal das gesicherte File. Dann sieht man mal, was da wirklich über die Leitung geht.
Hi KH, also hier das File, dass ich über "Save Output" gespeichert habe...evtl mit Notepad öffnen. Gruß
Zur Abkürzung: da steht drin °271073BF + CR
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ß
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
Hi Sascha, > Deshalb kannst du hier nur mit HEX-Werten arbeiten, was bei einer > Bearbeitung mit einem µC aber auch keine Rolle spielt. Weil sie beim uC als char oder int vorliegen? Gruß
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.
Hi Leute, danke für eure Tipps! Habt mir echt weiter geholfen! Grüße Louis
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.