mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART Daten binär übertragen


Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

Froh Ostern!!!

Ich moechte Daten per UART binär übertragen. Bis jetzt habe ich in ASCII 
gemacht. Es dauert hakt einbisschen.

Hat jemand eine Idee oder funktion. Die Funktionen, die ich habe, 
koennen nur:
.String
.Char
.Int
.Ul

Danke im Voraus.

Autor: Markus Müller (mmvisual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Übertragung über UART ist immer Binär. Der UART kennt kein ASCII.

Was suchst Du genau?
Ein Übertragungsprotokoll?

Wenn ja, dann schaue man die UU-Codierung an.

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,

danke fuer Deine Antwort,

Mein Problem ist, ich moechte ADC Werte uebertragen. Wenn ich den Wert 
z.B. 211 uebertagen moechte, dann uebertraegt die Werte "1" "5" "6" in 
Reihe und
nicht als Binaer "1001 1100". ich dachte als Binaer kann ich Viel und 
schnell uebertragen.

Autor: T. C. (tripplex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hängt davon ab wie das Terminal Programm die reinkommenden Werte 
anzeigt.

Autor: Randy N. (huskynet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein handelsüblicher UART funktioniert eigentlich so, dass man ihm genau 
ein Byte (also 8 Bit) übergibt und ihn anschließend darum bittet, dieses 
seriell und binär zu übertragen. Anschließend kann man ein neues Byte 
übergeben, die Übertragung wieder starten usw.

Da ein Char in der Regel einem Byte entspricht, wird diese Funktion 
nichts weiter machen, als dem UART genau diese 8 Bits des Chars zu 
übergeben und die Übertragung dann zu starten.

Ein String besteht aus mehreren Chars, deshalb wird diese Funktion 
wahrscheinlich die Char-Übertragungs-Funktion mehrfach aufrufen.

Ein Int besteht aus mehreren Bytes. Diese Funktion wird also die 
einzelnen Bytes des Int wieder mithilfe der Char-Übertragungs-Funktion 
einzeln übermitteln.


Meine Glaskugel (aufgrund aktueller Gegebenheiten eiförmig :-) ) sagt 
mir, dass du bis jetzt ASCII-Strings übertragen hast (mithilfe der 
String-Übertragungs-Funktion) und jetzt Binärdaten (also z.B. irgendein 
Array mit Bytes drin) senden möchtest. In diesem Fall müsstest du also 
nacheinander die einzelnen Bytes mithilfe der Char-Übertragungs-Funktion 
übertragen. Man sollte sich noch Gedanken machen, wie man einzelne 
Byte-Pakete dann voneinander trennt, aber dazu gibts viele fertige 
Protokolle, bzw. Ideen, die man verwenden kann.

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist das zweite Problem. Ich denke mit einem Protokoll aus der Seite 
des PC's werden die Daten vom Binaer in int oder Dezimal koenvertiert. 
Aber zuerst, wie kann ich die Daten binaer vom uC uebertragen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tetef El (tetef)

>nicht als Binaer "1001 1100". ich dachte als Binaer kann ich Viel und
>schnell uebertragen.

Sicher, aber wieviel Milliarden Messwerte willst du denn pro Sekunde 
übertragen? ASCII hat den Vorteil, dass es menschenlesbar ist. Das 
erleichtert das Debugging ungemein.

MfG
Falk

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wenn ich den Wert z.B. 211 uebertagen moechte, dann uebertraegt die Werte
>"1" "5" "6" in Reihe und nicht als Binaer "1001 1100".

Das kommt daher, das 0b1001 1100 = 156 ist, und nicht 211.

MfG Spess

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Übertragung findet immer binär statt. Es gibt nun mal nur 2 Zustände 
(high/low)=(1/0). Nur dein Terminalprogramm zeigt den Wert halt anderst 
an. Ist genauso beim Programmieren. In der Speicherzelle steht der Wert 
physikalische gesehen auch als 1 und 0. Trotzdem kann man 
binär/octal/dezimal oder wie auch immer drauf zugreifen. Mit einem 
Oszilloscope an der Schnittstelle kannst du die "Binärdaten" sogar sehen 
=)

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Spess,

was ich damit meinen moechte, anstatt 3 Byte: "1"+"5"+"6" kann ich durch 
"0b1001 1100" ein Byte uebertrage, somit spare ich 2 Bytes.


Hi flak,
Ich moechte das Maximum erreichen. Der Uc Controller verliert viel Zeit 
bei Datenuerbertragung. Das moechte ich vermeiden. Als Ueberlegung denke 
ich momentan an einem 2. uC und ein Groesse Speicher. Ich kann mit dem 
ersten uC messen und die Daten speichern und mit dem zweiten Daten 
uebertragen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tetef El (tetef)

>Ich moechte das Maximum erreichen. Der Uc Controller verliert viel Zeit
>bei Datenuerbertragung. Das moechte ich vermeiden.

Dann musst du auf jeden Fall mit Interrupts arbeiten, dann dann 
läuft die Datenübertragung parallel zum normalen Programm.

> Als Ueberlegung denke
>ich momentan an einem 2. uC und ein Groesse Speicher. Ich kann mit dem
>ersten uC messen und die Daten speichern und mit dem zweiten Daten
>uebertragen.

Ist wahrscheinlich nicht sinnvoll. Wer nichtmal EINEN uC sicher 
beherrscht, der ist mit zwei erst recht überfordert.

Schreib doch einfach mal, was du konkret machen willst, dann kann man 
dir helfen. siehe Netiquette.

MFG
Falk

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Flaker,

wer hat ueber "nicht beherschen" gesprochen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tetef El (tetef)

>Hi Flaker,

Wer soll das sein?

>wer hat ueber "nicht beherschen" gesprochen.

Deine Anfrage sagt das aus. Wer einen uC beherrscht, fragt sowas nicht.

MFG
Falk

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Falk,

Sorry, dass ich Deinem Name Falsch geschrieben habe. Es war aus 
versehen.

Ich habe ein Thema diskutiert mehr nicht. An Deiner Stelle, wenn ich 
eine Frage nicht verstehe, dann soll ich weiter fragen, um zu verstehen, 
was der Andere meinte, anstatt mit der Beleidigung anzufangen.

Froh Ostern.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tetef El (tetef)

>Ich habe ein Thema diskutiert mehr nicht. An Deiner Stelle, wenn ich
>eine Frage nicht verstehe, dann soll ich weiter fragen, um zu verstehen,
>was der Andere meinte, anstatt mit der Beleidigung anzufangen.

Geh mal davon aus, dass ich anhand einer Fragestellung bisweilen schon 
einschätzen kann, wieviel ein Fragesteller weiß oder auch nicht. Und 
wenn man das ausspricht ist das keine Beleidigung, sondern schlicht eine 
Feststellung.

Du bist nicht der Erste hier, der ganz tolle Ideen mit vielen 
Mikrocontrollern hat, aber mit deutlichem Nachholebedarf bei den 
Grundlagen.

Deshalb nochmal explizit meine Aussage.

"Schreib doch einfach mal, was du konkret machen willst, dann kann man
dir helfen. siehe Netiquette."

MFG
Falk

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tetef El schrieb:
> Ich habe ein Thema diskutiert mehr nicht. An Deiner Stelle, wenn ich
> eine Frage nicht verstehe, dann soll ich weiter fragen, um zu verstehen,
> was der Andere meinte, anstatt mit der Beleidigung anzufangen.

Hallo,

wenn du überhaupt irgendwas beherrschen würdest, hättest du gemerkt, das 
genau dieses Thema erst vor ein paar Tagen besprochen wurde: "Zahlen 
über UART senden". Im Gegensatz zu dir hat der Fragesteller allerdings 
die Antworten verstanden.

Ein UART überträgt Bytes, ob die für dich eine Zahl oder einen 
Buchstaben oder einen Teil einer grösseren Zahl darstellen, ist dem UART 
völlig egal. Das sind absolute Grundlagen der IT, also tu nicht so, als 
wärst du der grösste Programmierer aller Zeiten - das ist schlicht ein 
Irrtum. Du befindest dich noch in der Umgebung des Nullpunkts, und das 
ist keine Beledigung sondern eine Orientierungshilfe.

Gruss Reinhard

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Falk,

wenn Du meinst, ich habe Nachholebedarf, dann moechte ich von Deiner 
erheblichen Kenntnissen lernen.

Wir reden die ganze Zeit ueber die Datenuebertragung.

in meine Routine messe ich die Zeit 16bit und die Amplitude 10bit. ich 
moechte  diese Daten per UART uebertragen. Bediengung schnell wie 
moeglich.

Wie kann ich es am besten nach Deiner Meinung?

P.S. Meine Frage ist nicht ironisch

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tetef El schrieb:
> in meine Routine messe ich die Zeit 16bit und die Amplitude 10bit. ich
> moechte  diese Daten per UART uebertragen. Bediengung schnell wie
> moeglich.

Hallo,

das ist eine 5stellige und eine 4stellige Zahl und ein Trennzeichen wie 
CR, also 10 Zeichen. Wenn du es binär überträgst, sind es 2 Bytes + 2 
Bytes + eine erkennbare Trennung, das ist bei binär aber viel 
schwieriger. Wenn du z.B. FF FF als Trennung nimmst, sind 6 Bytes zu 
übertragen - das rechtfertigt in meinen Augen nicht den schwerwiegenden 
Nachteil, das Zeug unterwegs nicht lesen zu können. Aber wenn du meinst, 
6 Bytes geht und 10 Bytes geht nicht, ok, sowas ist mir aber noch nicht 
begegnet, normalerweise geht es um Grössenordnungen.

Gruss Reinhard

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tetef El (tetef)

>Wir reden die ganze Zeit ueber die Datenuebertragung.

Ach was!

>in meine Routine messe ich die Zeit 16bit und die Amplitude 10bit. ich
>moechte  diese Daten per UART uebertragen. Bediengung schnell wie
>moeglich.

>Wie kann ich es am besten nach Deiner Meinung?

Nun, indem du deine Zeit als 2x8 Bit und auch deine Amplitude als 2x8 
Bit versendest. Aber das ist nur die halbe Miete. Denn deine Gegenstelle 
(PC?) muss ja irgendwie erkennen, wo ein Datenblock anfängt. Und da 
haben wir das Problem.

Im ASCII könnte man so senden

Z12345
A1234

Z markiert den Anfang der Zeit
12345 ist der 16 Bit Zeitwert
A markiert den Anfang der Amplitude
1234 ist der Amplitudenwert

Macht im schlimmsten Fall 13 Zeichen (jede Zeile wird ja mit einem 
Return (0x0D) abgeschlossen).

Binär muss man sich was einfallen lassen. Denn dort kann man zwischen 
einem ASCII A, welches binär 0x41 bzw. dezimal 65 und dem Messwert 65 
nicht unterscheiden!
Dazu gibt es verschiedene Möglichkeiten.

Man definiert ein spezielles Muster, z.B. 0x55 am Anfang und 0xAA am 
Ende, das man als Kennung immer sendet. Natürlich kann das auch in den 
Daten direkt vorkommen, denn die Zeit ist ja als 16 Bit Zahl definiert, 
aber die Kennung erscheint periodisch in einem festgelegtem Rahmen. Z.B. 
so

0x55 0x11 0x22 0x33 0x44 0xAA

0x55 Startkennung
0x11 0x22 Zeitwert
0x33 0x44 Amplitude
0xAA Endekennung

Deine Software muss aus dem Datenstrom nun immer die Zeichen lesen und 
prüfen, ob sie 0x55 und 0xAA im Abstand von 5 Bytes findet. Wenn ja, 
dann ist der gelesene Datenblock gültig. Wenn nein, muss sie weiter 
suchen.

Man braucht für diese binäre Übertragung zwar nur 6 Bytes im Vergleich 
zu 13 bei ASCII, dafür ist die Auswertung komplexer. Du solltest dich 
erstmal mit der ASCII-Variante beschäftigen. Wenn du die sehr gut 
beherrschst, kannst du über eine binäre Übertragung nachdenken.

MfG
Falk

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>in meine Routine messe ich die Zeit 16bit und die Amplitude 10bit. ich
>moechte  diese Daten per UART uebertragen. Bediengung schnell wie
>moeglich.

Warten, bis UDRE H ist
hi(Zeit) nach UDR
Warten, bis UDRE H ist
Lo(Zeit) nach UDR
Warten, bis UDRE H ist
hi(ADC) nach UDR
Warten, bis UDRE H ist
hi(ADC) nach UDR

Allerdings hast du jetzt ein neues Problem: Dein PC weiss nicht, wann so 
ein Block anfängt. Also musst du dir etwas einfallen lassen, wie du das 
ganze synchronisierst. Sollte dir aber nicht schwerfallen.

MfG Spess

PS: Meine Meinung über deine Fähigkeiten deckt sich mit denen von Falk 
und Bensch.

Autor: Gast 23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abgesehen davon daß ich über die Fähigkeiten genauso wie die Vorposter
denke, "so schnell wie möglich" etc. verrät viel....

Viel interessanter wäre doch zu wissen:
Wieviele Messwerte müssen pro Zeiteinheit übertragen werden,
(schafft das die Übertragung?) habe ich überhaupt so viele Werte?
Und muß die Info "Zeit" überhaupt übertragen werden?

Wenn hier mehr Info was rüberkommt, gibt es sicher auch, wie ich das 
Forum
einschätze, konstruktive Vorschläge.

Noch frohe Rest-Ostern!

Autor: tetef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Spess53,


P.S.: Behalt Dein Kommentar für Dir.

Wenn Du verbesseren wills, dann mach es, weil Du davon ueberzeugst bist, 
und nicht um Deine Arogant zu zeigen.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>P.S.: Behalt Dein Kommentar für Dir.

Ja. Du mir auch.

MfG Spess

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tetef schrieb:
> Wenn Du verbesseren wills, dann mach es, weil Du davon ueberzeugst bist,
> und nicht um Deine Arogant zu zeigen.

Mit so überwältigender Dankbarkeit haben wir garnicht gerechnet.

Reinhard

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chips und Cola. Ich werde langsam fett...

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich dachte als Binaer kann ich Viel und schnell uebertragen.

Um auf den Ursprung zurueckzukommen... Was bedeutet viel und schnell ? 
Geht es um Megabytes und Megabytes pro sekunde ? Oder was ?

Wie schon bemerkt braucht man fuer Daten, die groesser als ein Byte sind 
ein Protokoll. Ob ASCII als Dezimal, oder ASCII als Hex, oder binaer ist 
eigentlich egal. Erst mal ein protokol.

Und dann kann man noch die Baudrate einstellen. Solange die Baudrate 
hinreichend tief ist sollte man sich noch nicht ueber binaer oder ASCII 
unterhalten.

Eine Entscheidung ist allerdings, sollten die Daten auf ein Terminal 
oder eh zu einem speziell geschriebenen Programm. Ich bin nun seit 30 
Jahren im Geschaeft und verwende immer dasselbe binaere Protokol, das 
geht. Ein Kollege, gleichlange in Geschaeft, sendet seit 30 Jahren an 
ein Terminal. Das geht auch.

Autor: DAF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kannst Du uns Deine Protokoll zeigen.

MfG

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein binaer Protokoll :

Feld  Groesse  Bedeutung
1      >=1     SYN = Synchronisation
2      1       Start
3      1       Laenge der Meldung ohne SYN
4      1       Woher - ID
5      1       Wohin - ID
6      1       Befehl
7      >=0     Daten
8      2       CRC

Das Protokoll ist Master-Slave bustauglich. Falls es nur um eine 
Punkt-zu-Punkt Uebertragung geht, kann man Feld 4 & 5 weglassen. Es gibt 
einen Master und dem gehoert der Bus. Nur der Master darf senden. Die 
Slaves duerfen nur antworten. Dazu kommt noch, dass jeder Befehl sofort 
beantwortet wird. Es ist nur ein Befehl aufs mal ausstehend. Ein Befehl 
wird beim Angefragten erkannt wenn die Wohin-ID passt. Wenn der CRC beim 
Angefragten nicht passt wird der Befehl verworfen. Wiederholungen sind 
Sache des Masters.
Die Slaves sollten zustandslos sein was die Kommunikation betrifft.

Die sofortige Antwort bedingt, dass die zu antwortenden Daten immer 
bereit sind. Also nicht noch schnell eine Floatberechung anwerfen wenn 
die Anfrage kommt.

Wenn man andere Anforderungen hat, muss man allenfalls die Struktur 
etwas anpassen.

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry Leute für mein Benehmen. Ich hatte einen harten Tag.

hi gleicher Tag,

ich benutze ein Programm (LabView), um die die Daten zu bearbeiten und 
arbeite auch mit der Baudrate 115200.
Meine Ersten Gedanken waren, dass ich die Auflösung auf 8bit einstelle. 
Und weil ich immer zwei Werte übertragen muss habe ich die Datenmenge so 
berechet:

Mein Format sieht so aus: wert1;wert2(CR)(LF) und dafür brauche ich 5 
Bytes pro Zeile.
1 Byte für wert1
1 Byte für ;
1 Byte für wert2
1 Byte für CR
1 Byte für LF
115200 b/s ---> 14400 B/s ---> 2880 Zeilen bzw. points(x,y).

wenn ich die Wete als ASCII übertrage, dann benutze mehr als 5 Bytes pro 
Zeile:
z.B. 155;144(CR)(LF) (9Bytes) d.h. für jedes Zeichen ein Byte, und das 
ist, was ich vermeiden möchte.
 Wahrscheinlich habe ich ein Denkfehler!!!

Danke im Voraus.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Tetef El (tetef)

>ich benutze ein Programm (LabView), um die die Daten zu bearbeiten und
>arbeite auch mit der Baudrate 115200.

;-)
LabView ist bei "normaler" Programmierung nicht sonderlich schnell, auch 
auf den dollsten QuadCore!

Beitrag "Quad Core Notebook ?"

>Mein Format sieht so aus: wert1;wert2(CR)(LF) und dafür brauche ich 5
>Bytes pro Zeile.
>1 Byte für wert1
>1 Byte für ;
>1 Byte für wert2
>1 Byte für CR
>1 Byte für LF
>115200 b/s ---> 14400 B/s ---> 2880 Zeilen bzw. points(x,y).

Irrtum. Du willst hier per ASCII übertragen. Dort kannst du mit einem 
Zeichen nur eine 4 Bit Zahl darstellen, nämlich 0..F. Ausserdem sind 
115200 Baud = 11520 Bytes/s, siehe Baud.

>wenn ich die Wete als ASCII übertrage, dann benutze mehr als 5 Bytes pro
>Zeile:
>z.B. 155;144(CR)(LF) (9Bytes) d.h. für jedes Zeichen ein Byte, und das
>ist, was ich vermeiden möchte.
> Wahrscheinlich habe ich ein Denkfehler!!!

Aber sicher ;-)

Siehe oben und mein Posting.

Beitrag "Re: UART Daten binär übertragen"

Ergo.

Vergiss tierische Performance bei LabView. Mach es per ASCII, das ist 
für dich Herausforderung genug. Mit ASCII brauchst du 13 Byte/Messreihe, 
macht bei 115200 Baud 886 Messwerte/s. Da hat LabView mehr als genug zu 
tun.

MFG
Falk

Autor: tetef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Falk,

noch eine Frage:

was hälst von Datenübertragung per Ethernet. Die Übertragung liegt 
zwischen 10Mbit und 100Mbit. Ich frage mich, ob ich die Daten per TCP 
übertrage, dann werde ich mein Ziel erreichen. für meine Anwendung sind 
886 Werte/s zu wenig.

Danke

Autor: gass (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USB an sich mach 12Mbit bzw 480Mbit

frage ist ob das Gerät erstmal so viel daten verkraftet bzw liefern kann

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da wärs halt interessant zu wissen, woher (welcher µC ...) die Daten 
eigentlich kommen.

Wenn das z.B. ein Atmega8 ist, wären SPI/UART schon so ziemlich die 
schnellste verfügbare Schnittstelle, wenn das ein dicker Arm mit 
Ethernet, USB-OTG und PCI-e usw on-board ist, wäre der UART eher die 
langsamste.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  tetef (Gast)

>was hälst von Datenübertragung per Ethernet.

Is ne dolle Sache ;-)

> Die Übertragung liegt
>zwischen 10Mbit und 100Mbit.

Oder sogar 1Gbit/s

> Ich frage mich, ob ich die Daten per TCP
>übertrage, dann werde ich mein Ziel erreichen. für meine Anwendung sind
>886 Werte/s zu wenig.

Ethernet allein löst das Problem nicht. Man braucht auch die passende 
Software. Und wie gesgat, LabView war nie dafür gedacht, größere 
Datenraten per graphischer Programmierungen zu erreichen. Das können nur 
spezielle M odule im LabView, die von aussen gesteuert werden.

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann locker per USB-RS232 Umsetzer 1 Mbit/s übertragen, macht dann 
nach obiger Rechung ~8000 Messungen/s. Das muss die Software erstmal 
schlucken. Bei unpassender Programmierung geht da auch ein Quadcore in 
die Knie. Bei passender reicht ein 286er mit 12 MHz ;-)

MFG
Falk

Autor: Leandro Leandro (tetef)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Man kann locker per USB-RS232 Umsetzer 1 Mbit/s übertragen, macht dann
> nach obiger Rechung ~8000 Messungen/s.

Das ist geil. Kann ich irgendeinen Umsetzer nehmen oder kannst Du mir 
einen empfehlen.

Danke

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: stephan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe keine Ahnung was LabView an Performance hat, aber ein Blick auf 
"Logview" kann auch nicht schaden. www. logview.info
Ist genau für sowas gemacht.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>1 Byte für wert1
>1 Byte für ;
>1 Byte für wert2
>1 Byte für CR
>1 Byte für LF
Was machst du dann wenn du z.B. sowas empfängst:
CR ; ; CR LF LF CR ; ; CR LF ; ; ; CR LF CR ; ; CR LF
Das ist eine gültige Sequenz, wenn die Daten wert1 und wert2 binär 
übertragen werden. Nur: wie erkennst du jetzt den Anfang und das Ende?

Und da ist immer noch eine recht wichtige Frage offen:
>> ich dachte als Binaer kann ich Viel und schnell uebertragen.
> Um auf den Ursprung zurueckzukommen... Was bedeutet viel und schnell ?
Dabei ist es komplett unwichtig, was du willst.
Von Interesse ist ausschliesslich, was du brauchst.

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Vergiss tierische Performance bei LabView.

Da muss ich widersprechen, auch wenn's jetzt Offtopic ist. Ich arbeite 
seit ein paar Jahren beruflich und privat sehr viel mit LabVIEW. Und 
über mit 115200 Baud reinkommende Daten lächelt LabVIEW nur milde.

Hab gerade ein kleines Testtool gemacht, um hier nicht mit 
Phantasiezahlen rumzuwerfen. Dort werden 1.000.000 Arrayeinträge (int32) 
durch Multiplikation erstellt und dann aufsummiert. Das Ganze dauert mit 
LV6.1 (alte, langsamere Version) auf einem 2,7GHz Core schlappe 17ms.

Natürlich ist LabVIEW langsamer als zum Beispiel C/C++. Aber für das 
Empfangen von UART-Daten ist es mehr als ausreichend.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Daniel R. (lordziu)

>> Vergiss tierische Performance bei LabView.

>Da muss ich widersprechen, auch wenn's jetzt Offtopic ist.

Das darfst du ;-)

> Ich arbeite
>seit ein paar Jahren beruflich und privat sehr viel mit LabVIEW. Und
>über mit 115200 Baud reinkommende Daten lächelt LabVIEW nur milde.

Ach ja? Klar, der Treiber puffert das schon gut ab, VERLOREN gehen die 
Daten so schnell nicht. ABER!!! Man kann vergessen, dass man mit der 
"normalen" graphischen Programmierung riesige Datendurchsätze packt. Das 
Problem wurde bereits in dem alten Thread klar, hab ich nun schon 
mindestens dreimal geschrieben.

Beitrag "Re: UART Daten binär übertragen"

>Hab gerade ein kleines Testtool gemacht, um hier nicht mit
>Phantasiezahlen rumzuwerfen. Dort werden 1.000.000 Arrayeinträge (int32)
>durch Multiplikation erstellt und dann aufsummiert. Das Ganze dauert mit
>LV6.1 (alte, langsamere Version) auf einem 2,7GHz Core schlappe 17ms.

Was hat das mit einem UART zu tun? WIE sieht das Programm auf? Ist das 
eine direkte Funktion in LabVieW? Klar, die ist sehr schnell, weil 
direkt in C impementiert. Oder wird diese mittels Schleife auf normalen 
Funktionsblöcken zusammengebaut? Dort kommt der LabView Interpreter ins 
Spiel und dann ist Ende im Gelände. Nix mit 1 Million Werte in 17ms 
summieren.

MFG
Falk

>Natürlich ist LabVIEW langsamer als zum Beispiel C/C++. Aber für das
>Empfangen von UART-Daten ist es mehr als ausreichend.

Aber nicht kontinuierlich mit tausenden von Datensätzen pro Sekunde 
unter nahezu Echtzeitbedingungen + ein wenig Verarbeitung.

MFG
Falk

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Das darfst du ;-)

Danke.

> Ach ja? Klar, der Treiber puffert das schon gut ab, VERLOREN gehen die
> Daten so schnell nicht. ABER!!! Man kann vergessen, dass man mit der
> "normalen" graphischen Programmierung riesige Datendurchsätze packt.

Wie gesagt, natürlich ist LabVIEW nicht so schnell wie C oder C++. Aber 
nochmal: Für 115200 Baud reicht es locker. Ich habe selbst eine 
Applikation, die mit dieser Datenrate kontiniuerlich ADC-Werte von einem 
AVR empfängt. Dort empfange ich die Daten und rechne nebenbei noch 200 
FFT's pro Sekunde. Das ganze wird dann in mehreren Diagrammen angezeigt.
Mein Rechner, auf dem das läuft, hat nur 1,5 GHz und die Prozessorlast 
liegt irgendwo bei 30%. Wie sollte das denn funktionieren, wenn LabVIEW 
- wie du sagst - dafür zu langsam ist?

> Was hat das mit einem UART zu tun?

Nix, hab ich auch nicht geschrieben. Geht nur darum, dass man locker 
100.000 Werte oder 500.000 Werte oder noch mehr pro Sekunde verarbeiten 
kann. Ob die vom UART kommen oder aus einer Datei oder von USB ist ja 
völlig egal.

> Ist das
> eine direkte Funktion in LabVieW? Klar, die ist sehr schnell, weil
> direkt in C impementiert. Oder wird diese mittels Schleife auf normalen
> Funktionsblöcken zusammengebaut?

Wo ist da der Unterschied? LabVIEW ist in C geschrieben. Wenn ich eine 
grafische for-Schleife ausführe, wird die vom Interpreter genauso an 
einen C-Aufruf weitergeleitet, wie ein expliziter C-Call-Aufruf.

Sag mir doch mal ein konkretes Beispiel, wo LabVIEW zu langsam wird. Ich 
klick das hier mal schnell zusammen und messe dann die Zeiten. 
Vielleicht lieg ich ja auch falsch. Lass mich gerne belehren.

Grüße,
Daniel

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Daniel R. (lordziu)

>nochmal: Für 115200 Baud reicht es locker.

diese Aussage ist so gar nix wert. Hab ich schon mehrfach erklärt warum.

>Applikation, die mit dieser Datenrate kontiniuerlich ADC-Werte von einem
>AVR empfängt.

Wieviel Messwerte pro Sekunde? Wieviel Bytes pro Sekunde?

>liegt irgendwo bei 30%. Wie sollte das denn funktionieren, wenn LabVIEW
>- wie du sagst - dafür zu langsam ist?

Zahlen. Dann reden wir weiter.

>Nix, hab ich auch nicht geschrieben. Geht nur darum, dass man locker
>100.000 Werte oder 500.000 Werte oder noch mehr pro Sekunde verarbeiten
>kann.

Das bezweifle ich.

> Ob die vom UART kommen oder aus einer Datei oder von USB ist ja
> völlig egal.

Jain, ist aber hier nicht das Thema.


>> Ist das
>> eine direkte Funktion in LabVieW? Klar, die ist sehr schnell, weil
>> direkt in C impementiert. Oder wird diese mittels Schleife auf normalen
>> Funktionsblöcken zusammengebaut?

>Wo ist da der Unterschied? LabVIEW ist in C geschrieben. Wenn ich eine
>grafische for-Schleife ausführe, wird die vom Interpreter genauso an
>einen C-Aufruf weitergeleitet, wie ein expliziter C-Call-Aufruf.

Tja, hier liegt dein Verständnisproblem. Es ist ein GEWALTIGER 
Unterschied, ob eine spezielle Funktion als komplettes Modul in C 
geschrieben wurde und dann direkt als Maschienencode läuft oder ob der 
Interpreter dazwischen hängt.

http://de.wikipedia.org/wiki/Interpreter

>Sag mir doch mal ein konkretes Beispiel wo LabVIEW zu langsam wird. Ich
>klick das hier mal schnell zusammen und messe dann die Zeiten.
>Vielleicht lieg ich ja auch falsch. Lass mich gerne belehren.

Deine oben beschriebene Funktion. 1 Million Werte in einem Array 
erzeugen und aufsummieren. In C sieht das ungefähr so aus.
long my_array[1000000];
long sum=0;

// Mit Zufallzahlen füllen
for (i=0; i<1000000, i++) {
    my_array[i]=rnd(1);
}

// Aufsummieren
for (i=0; i<1000000, i++) {
    sum += my_array[i];
}

Mach das mal in normaler graphischer Labviewprogrammierung und miss die 
Zeit. Poste auch mal einen Screenshot des Programms unter Beachtung der 
Bildformate.

MFG
Falk

Autor: Lord Ziu (lordziu)
Datum:
Angehängte Dateien:
  • preview image for lv.jpg
    lv.jpg
    31,5 KB, 294 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:

> Wieviel Messwerte pro Sekunde? Wieviel Bytes pro Sekunde?

Etwa 10.000 Bytes pro Sekunde, kontinuierlich.

>
>>liegt irgendwo bei 30%. Wie sollte das denn funktionieren, wenn LabVIEW
>>- wie du sagst - dafür zu langsam ist?
>
> Zahlen. Dann reden wir weiter.

Ja, du hast völlig Recht. Wenn die Prozessorauslastung 32% beträgt statt 
28%, dann ändert das den Sachverhalt "das LabVIEW die Auswertung locker 
schafft" natürlich grundlegend... ^^

>
>>Nix, hab ich auch nicht geschrieben. Geht nur darum, dass man locker
>>100.000 Werte oder 500.000 Werte oder noch mehr pro Sekunde verarbeiten
>>kann.
>
> Das bezweifle ich.
>

> Jain, ist aber hier nicht das Thema.

Full ACK.

> Tja, hier liegt dein Verständnisproblem. Es ist ein GEWALTIGER
> Unterschied, ob eine spezielle Funktion als komplettes Modul in C
> geschrieben wurde und dann direkt als Maschienencode läuft oder ob der
> Interpreter dazwischen hängt.
>
> http://de.wikipedia.org/wiki/Interpreter

Danke für den Link, aber ich hab in meinem Informatikstudium schon ganz 
gut verstanden, was ein Interpreter ist.

> Deine oben beschriebene Funktion. 1 Million Werte in einem Array
> erzeugen und aufsummieren. In C sieht das ungefähr so aus.
> long my_array[1000000];
> long sum=0;
>
> // Mit Zufallzahlen füllen
> for (i=0; i<1000000, i++) {
>     my_array[i]=rnd(1);
> }
>
> // Aufsummieren
> for (i=0; i<1000000, i++) {
>     sum += my_array[i];
> }
>

Siehe Bild, Ausführungszeit 206 ms. Aber nur, weil ich die Zufallszahlen 
nur in Gleitkommazahlen generieren kann und noch multiplizieren und 
casten muss. Wenn ich einfach den Schleifenzähler als Wert reinschiebe, 
dauert es 17 ms. (LV 6.1, auf 2,7 GHz Prozessor)

Du sagst ja selbst, dass nur Zahlen gelten. Wie lange dauert denn die 
Ausführung in C, um das mal zu vergleichen?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Daniel R. (lordziu)

>Etwa 10.000 Bytes pro Sekunde, kontinuierlich.

Das ist schon recht viel.


>> Zahlen. Dann reden wir weiter.

>Ja, du hast völlig Recht. Wenn die Prozessorauslastung 32% beträgt statt
>28%, dann ändert das den Sachverhalt "das LabVIEW die Auswertung locker
>schafft" natürlich grundlegend... ^^

Lass mal gut sein, für die coolen Sprüche bin ich hier zuständig. Lesen 
und verstehen will gelernt sein.
Warum hab ich wohl nach der Datenrate gefragt?

>Danke für den Link, aber ich hab in meinem Informatikstudium schon ganz
>gut verstanden, was ein Interpreter ist.

Ach ja? Und dann lieferst du so einen Screenshot ab? Und dass, OBWOHL 
ich nochmal auf die Bildformate verwiesen habe?
Reife Leistung!

>Siehe Bild,

Nein Danke, bin schon Brillenträger. Sowas tu ich mir nicht an.

>Du sagst ja selbst, dass nur Zahlen gelten. Wie lange dauert denn die
>Ausführung in C, um das mal zu vergleichen?

Keine Ahnung, hab hier keinen C-Compiler für den PC. Ich würde mal 
tippen irgendwas im einstelligen Millisekundenbereich, ggf. weniger.

MfG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sooo, hab nir doch noch mal den "screenshot" angesehen. Und er bestätigt 
VOLL meine Aussage.

Das ist KEINE Schleife in Labview, sondern einzelne Module, welche nur 
mit Parametern gefüttert werden. Das ist nahezu identisch mit einem 
C-Programm, nur bissel LabView Runtime Zusatzaufwand. Dass das relativ 
zügig geht ist klar.

Programmier es mal WIRKLICH als Schleife, mit dem Schleifenkonstrukt im 
LabView, elementarer Array Zugriff etc. Dann sieht das alles ganz anders 
aus. Und das ist auch der Punkt, warum es bei vielen Programmen mit der 
Leistung hapert. Man kann es bisweilen besser machen, aber nicht immer.

MFG
Falk

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>
> Ach ja? Und dann lieferst du so einen Screenshot ab? Und dass, OBWOHL
> ich nochmal auf die Bildformate verwiesen habe?
> Reife Leistung!
>

Och. Dafür, dass ich auf meinem Arbeits-PC hier kein Grafikprogramm 
installiert habe, ist es auf die Schnelle nicht schlecht.

>
> Das ist KEINE Schleife in Labview, sondern einzelne Module, welche nur
> mit Parametern gefüttert werden. Das ist nahezu identisch mit einem
> C-Programm, nur bissel LabView Runtime Zusatzaufwand. Dass das relativ
> zügig geht ist klar.
>
> Programmier es mal WIRKLICH als Schleife, mit dem Schleifenkonstrukt im
> LabView, elementarer Array Zugriff etc. Dann sieht das alles ganz anders
> aus. Und das ist auch der Punkt, warum es bei vielen Programmen mit der
> Leistung hapert. Man kann es bisweilen besser machen, aber nicht immer.
>

Vielleicht solltest du dir den Thread nochmal von vorne durchlesen. Es 
geht hier nicht darum, die Geschwindigkeit von LabVIEW bei bestimmten 
Konstrukten mit der Geschwindigkeit von textuellen Programmiersprachen 
zu vergleichen.
Es ging darum, ob LabVIEW schnell genug ist um die UART Daten 
verarbeiten zu können. Daran zweifelst du. Siehe dein Posting von weiter 
oben:

Falk Brunner schrieb:
> Vergiss tierische Performance bei LabView. Mach es per ASCII, das ist
> für dich Herausforderung genug. Mit ASCII brauchst du 13 Byte/Messreihe,
> macht bei 115200 Baud 886 Messwerte/s. Da hat LabView mehr als genug zu
> tun.

Und deine Aussage ist eindeutig nicht zutreffend. 886 oder 10000 
Messwerte pro Sekunde zu verarbeiten (inkl. Berechnungen und graphischen 
Darstellungen) ist ohne Weiteres möglich.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht compiliert LabView den Kram? Ich kenne das Programm nicht, 
aber wenn alle Bindungen statisch vorhanden sind, kann man prinzipiell 
den Ablauf auch komplett übersetzen.

Autor: tetef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Falk,
ich habe den "USB-RS232 Umsetzer" besorgt. Ich kann mein USBRS232 Port 
nur bis 128000 b/s einstellen. den Umsetzter habe ich bei LOGILINK 
bestellt, ein USB2.0toRS232. Wie bzw. was soll ich tun, damit ich die 
1Mb/s erreiche?
Danke

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Passenden Treiber installieren und passendes Terminalprogramm benutzen. 
Beides muß gleichzeitig vorhanden sein!

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wie viele Messwerte werden denn überhaupt benötigt?
Und warum muss da immer eine Zeit übertragen werden?
Kann man nicht einfach sagen das die Werte einen Abstand von 1ms haben?

Wenn man kontinuierlich eine Zeit sendet , stimmt was nicht.... oder die 
gemessenen Werte liegen wirklich weit auseinander.

und wenn man dann nur noch 10Bit übertragen muss wird beim ersten byte 
das oberste bit gesetzt und beim zweiten nicht. schon kann man sich zu 
jedem beliebigen Zeitpunkt Synchronisieren. :)

Autor: tetef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Abdul,

Ich habe einen neuen Umsetzer gekauft. Die Übertraung lauft gut(bis 
460800).

wenn ich die BR 921600 benutze, dann bekomme ich kommische ascii 
Zeichen.

weiss jemand, woran das liegt??

Hallo ICH,

Ich übertrage keine Zeit. Es sind nur 2 berechneten Werten.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tetef schrieb:
> wenn ich die BR 921600 benutze, dann bekomme ich kommische ascii
> Zeichen.
> weiss jemand, woran das liegt??

Hallo,

da wird dir kaum was anderes übrigbleiben, als ein Oszi zu nehmen (oder 
einen Protokoll-Analysator) und die Signale an beiden Enden zu 
überprüfen. Wenn die allerdings ok sind, kann es eben einer der 
Beteiligten schon intern nicht.

Asynchrone Übertragungen erfordern i.d.R. eine Abtastung mit 8x oder 16x 
Baudrate, die beiden Systeme müssen also wenigstens 7.69 MHz Takt haben. 
Ist das nicht der Fall, wird die Synchronisierung unsicher. Das ist auch 
der Fall, wenn die Quarzfrequenz nicht ganzzahlig auf 7.69 MHz geteilt 
werden kann - wenn du z.B. 10 MHz hast, kannst du also mit 10 oder mit 5 
MHz sampeln, aber in beiden Fällen ergibt das rund 30 % Timingfehler, 
viel zu viel für eine korrekte Übertragung. Das muss ein Entwickler aber 
wissen, wenn er 921600 als Einstellung zulässt.

Gruss Reinhard

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> eine Abtastung mit 8x oder 16x
> Baudrate, die beiden Systeme müssen also wenigstens 7.69 MHz Takt haben.

??? Die Baudrate ist doch die Abtastfrequenz, oder bin ich jetzt total 
neben dem Dampfer??!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Udo R. S. (Gast)

>> eine Abtastung mit 8x oder 16x
>> Baudrate, die beiden Systeme müssen also wenigstens 7.69 MHz Takt haben.

>??? Die Baudrate ist doch die Abtastfrequenz, oder bin ich jetzt total
>neben dem Dampfer??!

Daneben ;-)
Siehe Baudratenquarz

MFG
Falk

Autor: Udo R. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ne ne.
Die Boudrate ist die max. Änderung des Signals pro Sekunde, damit gleich 
der Abtastfrequenz. Bei binären Signalen und einer Datenleitung also 
gleich der Bruttobitrate.
Wenn Reinhard meint, daß man zur Erzeugung einer bestimmten Baudrate 
einen 8 oder 16 fachen Systemtakt braucht ist daß etwas anderes, dann 
hat er sich aber missverständlich ausgedrückt.
Der Ausdruck:
>eine Abtastung mit 8x oder 16x Baudrate
ist auf jeden Fall nicht richtig.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>>> eine Abtastung mit 8x oder 16x
>>> Baudrate, die beiden Systeme müssen also wenigstens 7.69 MHz Takt haben.

Korrektur: muss heissen 7.37 MHz. Dann klappt's auch mit dem 
Baudratenquarz.

Gruss Reinhard

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Udo R. S. schrieb:
> ne ne.
> Die Boudrate ist die max. Änderung des Signals pro Sekunde, damit gleich
> der Abtastfrequenz. Bei binären Signalen und einer Datenleitung also
> gleich der Bruttobitrate.
> Wenn Reinhard meint, daß man zur Erzeugung einer bestimmten Baudrate
> einen 8 oder 16 fachen Systemtakt braucht ist daß etwas anderes, dann
> hat er sich aber missverständlich ausgedrückt.
> Der Ausdruck:
>>eine Abtastung mit 8x oder 16x Baudrate
> ist auf jeden Fall nicht richtig.

Nur für die Akten:
Ein Baud ist die Symbolschrittgeschwindigkeit - also eine zeitlich 
gleichgeteilte Einteilung auf der Zeitachse.
Ein Symbol kann aus mehreren Bits bestehen. Auch wieder eine ganzzahlige 
Einteilung!
Oftmals wird 1 Baud aber als 1 Bit/Sek. beschrieben. Das kann stimmen, 
muß es aber wirklich nicht!
Und warum nun vielfach sampeln? Ist doch einfach: Der Sender und der 
Empfänger laufen asynchron. Der Empfänger muß also sich irgendwie auf 
den Sender einstellen. Typische digitale PC-Systeme haben aber keine 
Möglichkeit ihren lokalen Takt linear in der Phase zu verstellen. 
Außerdem, was wäre dann mit mehreren gleichzeitig arbeitenden 
Kommunikationsleitungen? Würde aufwändig mit FIFO usw.
Also:
Sender kann mit 1xfachen Takt laufen, Empfänger meist mit 8x oder 16x 
Takt.
Damit die blöden User dann im Datenblatt nicht völlig durcheinander 
kommen, wird das gleich so implementiert, das der Takt immer ein 
bestimmtes Vielfaches sein muß. Schließlich will der Hersteller 
möglichst wenig Supportanfragen.

Falk kann das nun in seinen Artikel einarbeiten... Klingt dann 
vielleicht auch besser :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.