Atmega8 - RS232 - ASCII zu DEZIMALWERT

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.