www.mikrocontroller.net

Forum: PC-Programmierung SerialPort Rx Puffer Überlauf mit Vista aber nicht bei XP


Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,


habe folgendes Problem :

Ich habe mit VisualBasic.net eine Bedienoberfläche programmiert, mit der 
ich Daten von meiner Microcontrollerplatine über die RS232 empfange. Die 
Oberfläche zeichnet die Daten wie bei einem Oszilloskop über die Zeit 
auf.

Um dem PC genügend Zeit zu geben, die Daten einzulesen und auszuwerten, 
habe ich nach jeder kompletten "Frame" die vom µC gesendet wird, eine 
Pause in dessen Programm angehängt. Die Pausenzeit bis zur nächsten 
Controller Frame wurde so gewählt, das der Empfangspuffer des PC´s 
konstant bleibt und nicht überläuft. Ansonsten werden falsche Daten 
empfangen was man im Diagramm als Linienabrisse sofort erkennen kann.
Das alles wurde auf meinem Desktoprechner mit Windows-XP und einer 
On-Board Rs232 Schnittstelle programmiert. Prozessor ist ein Athlon64 
3000+ mit 2GB Ram

Wenn ich jetzt das Programm auf meinem Laptop laufen lasse (Intel Core 2 
Duo 3GB Ram mit dem Serial RS-232 Expresscard Adapter EX-1370 und 
Windows Vista Home Premium), läuft mir mit den selben Einstellungen der 
Empfangspuffer in windeseile voll.
Was mir dabei aber aufiel, ist das es scheinbar zu keinem Datenverlust 
führt wenn der Puffer überläuft, jedoch ist das Zeichnen alles andere 
als flüssig, vielmehr werden die Daten "Etappenweise" in der Picturebox 
gezeichnet, und irgendwann hängt sich das ganze dann komplett auf. Die 
Prozessorauslastung beider Kerne ist gerad einmal 20%.Auf Handshake 
Verfahren will ich aufgrund fehlender Pinbelegung am Controller 
verzichten , da es ja auch auf meinem Desktop-PC ohne klappt.

Wo könnte hier das Problem liegen ? An Leistungsdefiziten des Laptops 
kann es ja nicht liegen. Evtl. aber an der Seriellen Schnittstelle über 
die Expresscard ??


Danke fürs lesen
gruss Maggus ;)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann sehr wohl an der Schnittstelle in der ExpressCard liegen. Die 
wird nämlich mit recht hoher Wahrscheinlichkeit als USB-Seriell-Adapter 
implementiert sein - ja, das sieht die ExpressCard-Spezifikation vor.

Das kannst Du selbst herausfinden, indem Du mal im Gerätemanager 
nachsiehst, a) was für ein Devicetreiber verwendet wird und b) Dir mal 
die Eigenschaften des Gerätes ansiehst. Üblicherweise wird dort ein 
"Ort" genannt, und bei USB-Geräten steht dort korrekt "USB" ...

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst ja auch ohne zusätzliche Pins Handshake implementieren, und 
zwar auf Protokoll-Ebene. Du definierst also um die eigentlichen 
Nutzdaten noch einen Header am Anfang, bzw. eine Checksumme und ein 
spezielles Zeichen am Ende als Endeerkennung und zur Synchronisierung. 
Der Controller sendet dieses Paket zum Rechner. Wenn der PC das Päckchen 
ordnungsgemäß empfangen und geprüft hat (Längenangabe aus Header und 
Checksumme okay), gibt er dem Controller ein ACK, und der µC sendet das 
nächste Paket, andernfalls gibts ein NACK, und der µC sendet das gleiche 
Paket nochmal. Da brauchst du dann kein Timeout etc.

Eine andere Möglichkeit wäre, den Rx-Buffer einfach höher zu setzen. Du 
gehst davon aus, dass die Abläufe unter Vista die gleichen sind wie bei 
XP. Ist definitiv nicht so. Erstens hast du eine andere "Schnittstelle" 
vom PC-Prozessor bis zu deinen RS232-Pins (einmal fest aufm Board und 
einmal über Karte) und somit ein anderes Verhalten (Timing, Ansteuerung, 
etc.). Zweitens wird denke ich der Ablauf mit .NET unter Vista anders 
sein als bei XP.
Die Ruckler können z.B. auch auftreten, wenn du erstens die 
Datenverarbeitung nicht sauber von der Ausgabe getrennt hast, also die 
Ausgabe besser in einem eigenen Thread laufen lassen (z.B. mit der 
BackGroundWorker-Klasse in .NET). Zweitens wird Vista halt viel mehr 
Krimskrams im Hintergrund laufen haben als XP, da könnt ich mir 
vorstellen, das wegen Klickibunti die wichtigen Sachen wie 
Schnittstellen weniger Priorität bekommen haben.

Und dann kommts noch drauf an, wie du den Buffer ausliest (Ereignis oder 
Polling) und wie du bei Ereignissteuerung triggerst (jedes Byte oder 
nach einer bestimmten Anzahl Bytes das Ereignis auslösen).

Ralf

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Zitat von  Rufus

>Das kannst Du selbst herausfinden, indem Du mal im Gerätemanager
>nachsiehst, a) was für ein Devicetreiber verwendet wird und b) Dir mal
>die Eigenschaften des Gerätes ansiehst. Üblicherweise wird dort ein
>"Ort" genannt, und bei USB-Geräten steht dort korrekt "USB" ...

Devicetreiber :    OXCB950 Cardbus UART
Gerätetyp     :    Multifunktionsadapter
Hersteller    :    Enhanced Ports
Gerät         :    PCI Bus 13, Gerät 4


>Zitat von Ralf

>Wenn der PC das Päckchen
>ordnungsgemäß empfangen und geprüft hat (Längenangabe aus Header und
>Checksumme okay), gibt er dem Controller ein ACK, und der µC sendet das
>nächste Paket

Der Controller darf möglichst keine Unterbrechnungen bei seinem 
Programmablauf haben. Zweck der Oberfläche ist das darstellen von 
Reglergrössen. Der Controller wird später mal als Regelung für eine Art 
aktives Pendel verwendet. Mit der Oberfläche soll es möglich sein, die 
internen Abläufe Grafisch darzustellen. Und damit das µC Programm 
möglichst unterbrechnungsfrei laufen soll, hab ich die Sache mit der 
Kurzen Pause am Ende einer gesendeten Frame geschrieben. Dann kann man 
wenigstens mit festen Pausen Rechnen. Die Darstellung darf hierbei nicht 
den Controller behindern. Deshalb wäre dabei ein Pufferüberlauf evtl. 
sogar verschmerzbar , aber nicht wüschenswert.


Zum Quellcode :
If cp.ReadChar = 2 Then
            Try
                strString = ""
                Dim i As Integer = 0
                Do
                    intChar(i) = cp.ReadByte
                    i += 1
                    
                Loop While intChar(i - 1) <> 3
                Dim temp(3) As Byte
                newFrame.bytFC = intChar(0)
                temp(0) = intChar(4)
                temp(1) = intChar(3)
                temp(2) = intChar(2)
                temp(3) = intChar(1)
                newFrame.sngValue = System.BitConverter.ToSingle(temp, 0)

                strString += "FC:(" & Hex(intChar(0)) & ")" & "Value : (" & CStr(newFrame.sngValue) & ")" & vbCrLf

                ' Schreibt anhand des erhaltenen Funktionscodes an die entsprechende Eigenschaft den Übergebenen Wert
                setValues(intChar(0), newFrame.sngValue)
                

                Me.Invoke(Aktualisieren)

Ich reagiere auf jedes Empfangene Byte durch das Empfangen Ereignis der 
SerialPort Klasse. Nur Wenn das erste empfangene Zeichen (cp.ReadChar = 
2) ist, wird die Frame aufgenommen.
In Einer Schleife frage ich jedes folgende Byte ab, bis das Endzeichen 
erhalten wird (Loop While intChar(i - 1) <> 3).
So hab ich alle Bytes der Frame dann in dem Array ( intChar() ), das ich 
dann weiter verarbeite.

Das der Code nichts professionelles darstellt ist kein Geheimnis, aber 
er sollte funktionieren.Was er ja auch tut unter XP.Zumindest sollte er 
nicht das bewirken was es unter Vista bewirkt.

Ich bleib auf jedenfall dran, werde es mal an meinen alten XP Rechner 
ausprobieren. Sollte Vista das Problem sein, muss man mit den 
Konsequenzen eben klarkommen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich vermute mal das Problem wird sein das du beim empfangen gleich die 
Daten anzeigst. Soetwas sollte man vermeiden!. In PC mit mehr als 1GHz 
langweilt sich wenn du daten von einem µC mit ein paar Mhz kommen. 
Versuche mal das lesen ser Seriellen schnittstelle und das Anzeigen zu 
trennen.
Sobalt man etwas aus einem Programm anzeigt ist man von Windows 
abhängig, das vernichtet jedes Timing.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus wrote:
>>Zitat von  Rufus
>
>>Das kannst Du selbst herausfinden, indem Du mal im Gerätemanager
>>nachsiehst, a) was für ein Devicetreiber verwendet wird und b) Dir mal
>>die Eigenschaften des Gerätes ansiehst. Üblicherweise wird dort ein
>>"Ort" genannt, und bei USB-Geräten steht dort korrekt "USB" ...
>
> Devicetreiber :    OXCB950 Cardbus UART
> Gerätetyp     :    Multifunktionsadapter
> Hersteller    :    Enhanced Ports
> Gerät         :    PCI Bus 13, Gerät 4

OK, dann hast Du eine ausreichend hochwertige Karte gekauft. Dennoch 
gibt es einen Hardwareunterschied zwischen den Onboard-UARTs und der in 
dieser Karte verbauten - nämlich die Fifo-Größe. Die beträgt bei den 
Onboard-UARTs im PC 16 Byte (das ist der Standard-16550 von NSC), aber 
bei den UARTs von Oxford Semiconductor ganz erheblich mehr.

Der Empfangs-Fifo der UART wirkt sich auf zwei Arten auf den Empfang von 
Daten aus. Der Empfangs-Interrupt wird ausgelöst, wenn der Fifo voll 
ist, aber auch, wenn der Fifo nicht voll ist, und eine gewisse Wartezeit 
vergangen ist. Diese kann für das von Dir geschilderte Phänomen 
zuständig sein.

Abhilfe: Im Gerätemanager die Interruptschwelle für den Empfangs-Fifo 
der Oxford-UART auf den gleichen Wert stellen, wie auf dem PC mit 
Standard-UARTs, das dürfte 14 sein.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, eben klappts. Ich schreibs mal ausführlich für alle die den Post 
evtl. verfolgen :


Im "Gerätemanager/Anschlüsse(COM1)" unter dem Reiter FIFO´s gibts zwei 
Gruppen, nämlich

       FIFO Interrupt Trigger Levels und
       Receive FIFO Flow Control Thresholds

Wenn ich bei Interrupt Trigger Level den Schwellwert für Receiver auf 1 
setzte, läuft mein Programm so wie es soll. Vorher war hier der Wert 100 
eingetragen.

Ich interpretiere das jetz mal einfach so, das das Abarbeiten der 
Empfangenen Zeichen vom Controller erst ausgelöst wurde, wenn er 100 
Bytes Empfangen hatte.Ich war aber auch der Meinung, das ich das selbst 
in meinem Code festlegen kann ab wieviel Byte das Empfangs Ereignis 
ausgelöst wird. Aber vermutlich vergleiche ich hier Äpfel mit Birnen, 
kann das sein ?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Zitat von Peter
>
>Versuche mal das lesen ser Seriellen schnittstelle und das Anzeigen zu
>trennen.


Ich dachte hierfür sei der invoke Befehl (Me.Invoke(Aktualisieren)
). Dieser Startet nämlich das aktualisieren der Werte in der Form über 
einen eigenen Thread. VB.net lässt es auch garnicht zu, das ich die 
Daten direkt in die Form schreibe, sondern ich muss in diesem Fall den 
umweg über die Eigenschaften meiner Oszilloskopklasse gehen. Die Methode 
"Aktualisieren" die mit invoke ausgelöst wird, kümmert sich dann darum , 
das die vorhanden Daten (stecken jetzt ja in den Eigenschaften der 
Osziklasse ) in der Form gezeichnet werden.
Oder lieg ich hier evtl. auch falsch ?


Auf jedenfall funktioniert jetzt alles, vielen Dank nochmals ;)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn ich bei Interrupt Trigger Level den Schwellwert für Receiver auf 1
> setzte, läuft mein Programm so wie es soll.

Naja, das löst für jedes einzelne Zeichen einen Interrupt aus. Das 
entspricht dem Verhalten der Fifolosen uralt-UART 8250, wie man sie 
früher in PCs verwendet hatte. Bei hohen Datenraten ist das recht 
ineffizient, womit ich wörtlich Datenraten im Sinne von übertragene 
Bytes pro Sekunde meine, nicht die Baudrate an sich; man kann auch mit 
19200 Baud nur vier Zeichen pro Sekunde übertragen.

> Vorher war hier der Wert 100 eingetragen.

Naja, wie ich bereits riet, solltest Du mal nachsehen, mit welchem Wert 
der XP-Rechner arbeitet, dessen Onboard-Schnittstelle Du verwendest -ich 
tippe auf 14.

> Ich interpretiere das jetz mal einfach so, das das Abarbeiten der
> Empfangenen Zeichen vom Controller erst ausgelöst wurde, wenn er 100
> Bytes Empfangen hatte.

Wenn Du mit "Controller" den UART-Baustein in Deiner Karte meinst, ist 
das korrekt.

> Ich war aber auch der Meinung, das ich das selbst
> in meinem Code festlegen kann ab wieviel Byte das Empfangs Ereignis
> ausgelöst wird.

Nein, dazwischen sitzt noch ein Puffer, der von Windows verwaltet wird. 
Zugriff auf treiberspezifische Konfigurationsoptionen bietet die recht 
allgemein gehaltene API für serielle Schnittstellen nicht, das aber ist 
kein Fehler von Windows, sondern bei Betriebssystemen allgemein üblich.

> Aber vermutlich vergleiche ich hier Äpfel mit Birnen,
> kann das sein ?

Ach, das wird so oft gemacht ...

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Wert von WindowsXP übernommen, der stand in der tat auf 14, 
aber leider hatte ich dabei immernoch einen Überlauf. Zwar wesentlich 
langsamer, aber er war eben noch da.

Denke aber das die Einstellungen in Ordnung , solange ich nicht wieder 
Schwierigkeiten bekomme. Ich bin ja schon voll zufrieden das es erstmal 
so funktioniert. Bin in Sachen Programmieren kein profi und was die 
Hardware angeht auch nicht :)

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.