Datenkurve am PC anzeigen ist zu langsam

Deepdiver99 schrieb:
> Mein PC ist schnell genug.

Die RS232-Datenrate auch?

Naja, zuerst sollte man mal überprüfen, was wie lange dauert um 
rauszufinden was zu langsam ist ... Erst dann kann man beginnen zu 
optimieren

Die Baudrate ist auf 3.000.000 eingestellt.

Sobald vom STM32F4 mehr Datenblöcke geschickt werden fängt die Ausgabe 
der Kurve auf dem Bildschirm an zu stocken. Teilweise dauert es einige 
Sekunden bis es weiter geht. Dann aber alles auf einmal. Also am Empfang 
liegt es nicht. Meine CPU ist super schnell und 16GB RAM sollten auch 
reichen. Vermute mal das die Verarbeitung zwischen dem empfangen und der 
Ausgabe nicht effektiv ist. Wie wird sowas sonst in der Praxis gelöst? 
Bei anderen Systemen werden doch teilweise viel mehr Daten verarbeitet.

Deepdiver99 schrieb:
> Vermute mal das die Verarbeitung zwischen dem empfangen und der
> Ausgabe nicht effektiv ist.

Ich vermute, daß sich die Threads gegenseitig behindern, so wie du das 
beschreibst. Der Empfangsthread muß die Daten in einen Buffer schreiben 
können und parallel dazu muß ein anderer Thread unabhängig davon die 
Daten aus dem Puffer holen, sie verarbeiten und dann darstellen. Und 
wenn du sagst, daß während des Datenempfanges keine Aktualisierung der 
Darstellung erfolgt, dann wird dein Empfangsthread die anderen Threads 
blockieren.

Hallo,

wenn du Daten darstellst z.B. mit 1024 x 768 Pixeln, dann ist ein 
Bildschirm mit 1k x 16 bit vollgeschrieben, und da weder dein Auge noch 
dein Verstand mehr als 10 Bilder pro Sekunde erfassen kann, ist dafür 
eine Datenrate von 20 kB / s ausreichend, warum also überträgst du 300 
kB / s?

Es kann durchaus sein, dass die Empfangsinterrupts deine CPU-Leistung 
auffressen, besonders wenn der Treiber schlecht programmiert ist und 
z.B. für jedes Zeichen einen Interrupt auslöst. Ich halte es daher für 
möglich, dass die Sache mit niedrigerer Datenrate besser funktioniert, 
Baudraten sind nicht nach dem Prinzip viel hilft viel festzulegen, 
sondern das Gesamtsystem sollte ausgewogen sein. Jedenfalls kannst du 
das mal probieren. Am besten wäre es natürlich, wenn du zuerst mal 
messen würdest, welcher Thread wieviel CPU-Zeit verbraucht.

Du kannst natürlich auch mit Prioritäten spielen, aber das verdeckt eher 
ein bestehendes Problem als dass es gelöst wird.

Georg

10 fps könnten u.U. ruckelig wirken, mehr als 30 sind aber für diesen 
Zweck Rechenzeit- und Energieverschwendung. Um eine Begrenzung 
umzusetzen, muss man natürlich die Ausgabe vom Einlesen der Daten 
komplett entkoppeln und auch den Bildschirminhalt korrekt 
synchronisieren. Eine einfache Strategie wäre, die neuesten Daten 
anzuzeigen, die vorhanden sind (falls zwischen den Frames nicht genug 
reinkommt, um das Bild zu füllen, muss ein Teil der "alten" Daten 
verwendet werden, so dass das Bild scrollt). Alternativ könnte man alle 
Daten zeigen, ohne etwas zu überspringen; dann hinkt die Anzeige immer 
weiter hinterher. Irgendwann ist dann allerdings Schluss, weil der 
Buffer nicht beliebig groß sein kann.

> "Diese werden am PC „sortiert“ und als Kurve ausgegeben."

Bei einer hohen Datenrate muss man für eine sinnvolle Anzeige u.U. 
"richtig" synchronisieren - ähnlich wie bei einem Oszilloskop - was das 
Ganze natürlich komplexer macht.

Abdul K. schrieb:
> Benutz doch einfach das Programm von Alfred.

Alfred wer ?

Alfred war knapp daneben :)

Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"

Neueste Version 0.48e

Abdul K. schrieb:
> Der aus Mönchengladbach. Wirste hier finden.

Du kannst einen vielleicht in die Irre führen! Mann.... :-))

Albert schrieb:
> Alfred war knapp daneben :)
>
> Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle"
>
> Neueste Version 0.48e

Danke für den Link, Albert! Sieht sehr interessant aus, den Thread muß 
ich mir mal in Ruhe zu Gemüte führen...