Hallo zusammen, ein Kollege hat mich gebeten mal "schnell" einen RS232-Sniffer zu bauen, der die tatsächlich gesendeten Werte auf der RS232 mitliest und als tatsächlichen Dezimalwert ausgibt. Anbei der Code in Assembler (AVR Studio). Gruß, Heiko.
Heiko Haedicke schrieb: > und als tatsächlichen Dezimalwert ausgibt. könnte eine Ausgabe als Hex- und evtl. auch als ASCII-Wert nicht besser sein?
Was ist bloß immer so schwer daran, einen Quelltext übersetzungsfähig zu benennen, also *.c, *.asm usw.? Du sendest je Byte immer 4 Byte, d.h. Du verlierst sehr schnell Daten. Du müßtest mindestens mit der 4-fachen Baudrate senden, um wirklich alle Daten zu schniffen. So eignet sich das Programm bestenfalls, wenn die Bytes mit der Hand eingetippt werden.
Hallo, ich fang mal oben an :-) Die Anforderung hier war ganz klar - Dezimale Ausgabe - in der Form, wie sie das Programm hergibt. Googeln hat auf die Schnelle nichts gebracht, daher dachte ich mir - Poste ich das Ergebnis mal hier hin, da die Frage nach einem solchen Programm sehr häufig zu finden ist, aber eher weniger Lösungen. Egal, nun ist es online. Bzgl. der Benamung der angehangenen Datei. Was ist an Copy und Paste so schwer? Ich hätte auch das ganze AVR Studio Projekt posten können..? ;-) Bzgl. der GEschwindigkeit, ja, hier könnte man während der Laufzeit für die Ausgabe auf eine höhere Geschwindigkeit umschalten. Für unsere Belange reicht es aber völlig aus. Ich denke, am interessantesten ist eher die Umwandung des Wertes in 3 Zeichen. Den Rest kann man ja nach Anforderung "drumherum" schreiben. Gruß, Heiko.
Heiko Haedicke schrieb: > Bzgl. der Benamung der angehangenen Datei. > Was ist an Copy und Paste so schwer? > Ich hätte auch das ganze AVR Studio Projekt posten können..? ;-) Du hättest aber auch einfach das Asm-File (mit der Endung .asm) ganz einfach hoch laden können, so wie das tausende vor dir auch gemacht haben. Der Vorteil? Bei einem *.asm File klinkt dich die Forensoftware ein und schaltet zb Syntax Coloring zu. > Ich denke, am interessantesten ist eher die Umwandung des Wertes in 3 > Zeichen. Den Rest kann man ja nach Anforderung "drumherum" schreiben. Na ja. Wenn mans braucht. Die Idee der Zerlegung kommt ja auch im Tutorial an allen Ecken und Enden vor. Was mich aber tatsächlich interessieren würde: Wo kommt die Aufgabenstellung vor, eine UART Übertragung in Form von Dezimalzahlen mitzuprotokollieren? Im Regelfall ist es ja so, dass man da nicht einfach nur Bytes rüber schickt und jedes Byte ist für sich alleine genommen eine Zahl (zb ein Messwert) darstellt, sondern im Regelfall hat man es ja mit einem komplexeren Protokoll zu tun, bei dem die 'Auswertung' in Dezimal dann eher hinderlich ist.
> Du hättest aber auch einfach das C-File (mit der Endung .c) ganz einfach > hoch laden können, so wie das tausende vor dir auch gemacht haben. > Der Vorteil? > Bei einem *.c File klinkt dich die Forensoftware ein und schaltet zb > Syntax Coloring zu. DAS ist ein Grund, da gebe ich Dir recht. Gelobe Besserung! >> Ich denke, am interessantesten ist eher die Umwandung des Wertes in 3 >> Zeichen. Den Rest kann man ja nach Anforderung "drumherum" schreiben. > > Na ja. Wenn mans braucht. Jep. Ich brauchs nicht :-) > Was mich tatsächlich interessieren würde: Wo kommt die Aufgabenstellung > vor, eine UART Übertragung in Form von Dezimalzahlen > mitzuprotokollieren? Im Regelfall ist es ja so, dass man da nicht > einfach nur Bytes rüber schickt und jedes Byte ist für sich alleine > genommen eine Zahl (zb ein Messwert), sondern im Regelfall hat man es ja > mit einem Protokoll zu tun, bei dem die 'Auswertung' in Dezimal dann > eher hinderlich ist. Hier wird irgendeine exotische Hardware angesteuert, die eine ganz bestimmte Initialisierung für verschiedene Befehle verlangt die mit 9K6 zum Gerät gesendet werden. Diese Befehlskette soll während der Entwicklung überwacht werden. Diese Sequenz möchte der Entwickler in Dezimal sehen, um mehr geht es nicht.
Heiko Haedicke schrieb: > Ich denke, am interessantesten ist eher die Umwandung des Wertes in 3 > Zeichen. Kommt drauf an bei welchem Level in der Maschinencode-Programmierung man angelangt ist. Ich meine damit, wieviel Erfahrung jemand damit hat. Der Umgamg von Binär- und Hexwerten, also die Ausgabe und Nutzung aller Grundrechenarten, sollte schon zum Handwerkszeug eines Maschinensprache-Programmierers gehören. Das Wissen dazu kann man sich sicher vielerorts im Netz mit gut dokumentierten Beispielen holen. Da schliesse ich mich den Worten von Karl-Heinz (kbuchegg) an: > Na ja. Wenn mans braucht. Die Idee der Zerlegung kommt ja auch im > Tutorial an allen Ecken und Enden vor.
Heiko Haedicke schrieb: > Diese Sequenz möchte der Entwickler in Dezimal sehen, um mehr geht es > nicht. Dezimal ist eher unüblich. Hat mich schon zu 8bit-Zeiten genervt, wenn derartige Werte vorgegeben wurden (Progs in Magzinen). Heute nervt mich auch die RGB-Angabe in dez. (CSS tec.) Ich selbst denke und rechne seit vielen Jahren auch in Hex ;-) wenn ich den Compi in MC programmiere. Nicht so beim Einkauf ;-)
Natürlich ist die Idee der Zerlegung nicht neu. Ich behaupte ja auch nicht das Rad neu erfunden zu haben. Mein Umstieg auf die AVR's ist nicht all zu lange her und ich habe mich immer gefreut möglichst vollständige Beispiele zu finden, egal wie unnütz diese unterm Strich auch waren/sind.
Heiko Haedicke schrieb: > Natürlich ist die Idee der Zerlegung nicht neu. > Ich behaupte ja auch nicht das Rad neu erfunden zu haben. > > > Mein Umstieg auf die AVR's ist nicht all zu lange her und ich habe mich > immer gefreut möglichst vollständige Beispiele zu finden, egal wie > unnütz diese unterm Strich auch waren/sind. Passt schon. Das ist schon ok. Mich hat nur diese Dezimalitis gewundert. Denn gerade für den angepeilten Zweck, Kommandosequenzen zu überwachen, ist das meistens die absolut sinnloseste und umständlichste Form, die man sich vorstellen kann. Auf der Ebene ist man mit Hex normalerweise am besten bedient. Und gerade für den PC gibt es ja dann auch einen schönen Satz an Port-Sniffern, die genau das perfekt können.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.