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.
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.
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.
Das hängt davon ab wie das Terminal Programm die reinkommenden Werte anzeigt.
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.
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.
@ 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
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
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 =)
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.
@ 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
@ 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
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.
@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
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
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
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
@ 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
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.
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!
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.
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
>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.
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.
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.
@ 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
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
USB an sich mach 12Mbit bzw 480Mbit frage ist ob das Gerät erstmal so viel daten verkraftet bzw liefern kann
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.
@ 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
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
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
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.
>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.
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.
@ 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
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
@ 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.
1 | long my_array[1000000]; |
2 | long sum=0; |
3 | |
4 | // Mit Zufallzahlen füllen
|
5 | for (i=0; i<1000000, i++) { |
6 | my_array[i]=rnd(1); |
7 | }
|
8 | |
9 | // Aufsummieren
|
10 | for (i=0; i<1000000, i++) { |
11 | sum += my_array[i]; |
12 | }
|
Mach das mal in normaler graphischer Labviewprogrammierung und miss die Zeit. Poste auch mal einen Screenshot des Programms unter Beachtung der Bildformate. MFG Falk
Angehängte Dateien:
-
lv.jpg
31 KB
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?
@ 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
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
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.
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.
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
Passenden Treiber installieren und passendes Terminalprogramm benutzen. Beides muß gleichzeitig vorhanden sein!
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. :)
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.
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
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??!
@ 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
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.
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
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 :-)
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.