www.mikrocontroller.net

Forum: PC-Programmierung schnelle serielle Schnittstelle


Autor: Dr. H. Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche maximale Geschwindigkeit kann für die serielle Schnittstelle
angenommen werden, wenn man unter Windows arbeitet und welchen
Mikrocontroller benötigen wir dafür?

Wir bauen an einem Protoypen eines Medizingerätes und möchten data
monitoring betreiben. Eine Idee wäre, die bisher analogen Messwerte,
die digital verarbeitet werden, einem zweiten Mikrocontroller
zuzuleiten, welcher als Puffer arbeitet und Daten an den PC sendet.
Bisher erledigt dies der Hauptptouessor, der jedoch schon ab 9600 Baud
in Schwierigkeiten kommt.

Dr. Fischer, Univ-Klinikum Würzburg

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die in PCs verwendeten seriellen Schnittstellen unterstützen 115200
Baud. In Ausnahmefällen (mit speziellen Schnittstellenkarten) sind auch
höhere Baudraten möglich.

Wenn das verwendete Übertragungsprotokoll mit großen Datenblöcken
arbeitet, ist auch unter Windows ein Erreichen der genannten Baudrate
ohne weiteres möglich; heikel wird es, wenn ein Protokoll verwendet
wird, das intensives Bearbeiten der Handshakeleitungen, knappes Timing
oder gar ein Pingpong-Verfahren (an den PC gesendete Daten müssen von
diesem bestätigt werden) erfordert.

Der zu verwendende Microcontroller sollte demnach über
a) eine serielle Schnittstelle verfügen
b) über eine Schnittstelle zur Anbindung an die hier nicht näher
beschriebene Hardware verfügen
c) ausreichend schnell für die hier nicht näher beschriebenen
Anforderungen sein

Welche Datenmengen sollen übertragen werden?
Was für ein Hauptprozessor ist das, der bereits bei 9600 Baud "in
Schwierigkeiten" kommt, was macht der denn sonst noch?
Wie könnte die Schnittstelle des angedachten zusätzlichen Prozessors
zur Hardware aussehen?

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die in PCs verwendeten seriellen Schnittstellen unterstützen 115200
Baud. In Ausnahmefällen (mit speziellen Schnittstellenkarten) sind auch
höhere Baudraten möglich."

Also selbst mein steinalter 386er mit dem guten alten 16550er
Schnittstellenbaustein konnte schon 460,8kBit/s. Von Ausnahmefällen
kann also nicht die Rede sein.


"Wenn das verwendete Übertragungsprotokoll mit großen Datenblöcken
arbeitet, ist auch unter Windows ein Erreichen der genannten Baudrate
ohne weiteres möglich; heikel wird es, wenn ein Protokoll verwendet
wird, das intensives Bearbeiten der Handshakeleitungen, knappes Timing
oder gar ein Pingpong-Verfahren (an den PC gesendete Daten müssen von
diesem bestätigt werden) erfordert."

Häh? Einmal Handshake, einmal Pingpong?
Jedenfalls wird da, zumindest bei 460,8kBit/s, unter Windows nichts
heikel. Bei den schnellen PCs heute ist das doch erst recht kein
Problem.


"Der zu verwendende Microcontroller sollte demnach über
a) eine serielle Schnittstelle verfügen
b) über eine Schnittstelle zur Anbindung an die hier nicht näher
beschriebene Hardware verfügen
c) ausreichend schnell für die hier nicht näher beschriebenen
Anforderungen sein"

Mit Allgemeinplätzen kommt der Herr Fischer nicht weiter, soweit war
ihm das wohl auch klar.


Zu überdenken wäre eventuell der Einsatz einer anderen Schnittstelle,
z.B. USB. Heutzutage werden ja zumindest viele Notebooks nicht mehr mit
seriellen Schnittstellen ausgestattet, so daß das durchaus ein Argument
ist.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Also selbst mein steinalter 386er mit dem guten alten 16550er
Schnittstellenbaustein konnte schon 460,8kBit/s. Von Ausnahmefällen
kann also nicht die Rede sein."

O doch. Das ist ein Ausnahmefall. Der externe Takt des 8250/16450/16550
beträgt bei den üblichen seriellen Schnittstellen nämlich 1.8432 MHz,
und daraus können diese Schnittstellenbausteine eben nicht mehr als
115200 Baud erzeugen. Ein Blick in deren Datenblatt kann da Aufklärung
bringen.
Dein steinalter 386er hat da eine eindeutig nicht standardkonforme
Schnittstellenkarte gehabt.

"Häh? Einmal Handshake, einmal Pingpong?
Jedenfalls wird da, zumindest bei 460,8kBit/s, unter Windows nichts
heikel. Bei den schnellen PCs heute ist das doch erst recht kein
Problem."

Schon wieder O doch. Wenn das Protokoll so aussieht, daß der PC als
Bestätigung für jedes empfangene Byte ein Quittungsbyte zurückschicken
soll, dann liegt die erzielbare effektive Datenübertragungsrate unter
Windows in der Größenordnung von 1 kByte/sec, egal, was als Baudrate
eingestellt wird.
Das gleiche Phänomen tritt auf, wenn beispielsweise nach der
Übertragung jedes Bytes an den Handshakeleitungen gewackelt werden
soll.
Das hat insgesamt damit zu tun, daß ein Usermodeprogramm unter Windows
nicht schneller als im Millisekundentakt auf externe Ereignisse
reagieren kann, was wiederum mit der Granularität des Windowschen
Schedulers liegt.
Wollte man schnellere Reaktionszeiten erzielen, müsste man den Usermode
verlassen und auf Devicetreibereebene mit der Schnittstellenhardware
kommunizieren.

Nur wenn große Datenblöcke übertragen werden sollen sind höhere
Datenraten erzielbar, da die derzeitigen Schnittstellenbausteine über
relativ große Empfangs- und Sendepuffer verfügen (naja, 16 Bytes
halt).

Deine 460.8 kBit/sec werden übrigens auch von derzeitiger PC-Hardware
nicht unterstützt; ich frage mich, was für Schnittstellenkarten Du da
verwendest.

"Mit Allgemeinplätzen kommt der Herr Fischer nicht weiter, soweit war
ihm das wohl auch klar."

Wie soll man bei einer so detailliert formulierten Frage, wie der Herr
Fischer sie gestellt hat, eine präzisere Antwort geben?

Der Einsatz von USB ist allerdings in der Tat ratsam, setzt allerdings
voraus, daß auch PCs und Betriebssysteme verwendet werden, die damit
was anfangen können. Erfahrungsgemäß sind öffentlich-rechtliche
Forschungs- und Bildungseinrichtungen veritable Computermuseen, so daß
dort teilweise noch ohne USB ausgekommen werden muss ... (mich
schauderts).

In Microcontrollerschaltungen werden FT232 und FT245 von
www.ftdichip.com sehr gerne verwendet, was auch an der Einfachkeit der
Programmierung der PC-Seite liegt.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also bei 16bytes fifo..etwas prozessorlast und windows wirst du ziemlich
schnell probs bekommen mit byte-verlusten... zumindest haben werden
deshalb bei uns in der firma auf den prüfständen überall karten mit
64bytes an fifo verbaut...

hängt davon ab wie gross deine packerl sind die du da verschickst und
in welchen abständen sie reinkommen...

73

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meines Wissens nach hat Win intern noch einen extra Buffer. Bei mir
gehen erst nach genau 4096byte Daten verloren, wenn ich nichts auslese

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Meines Wissens nach hat Win intern noch einen extra Buffer.

Den kannst Du mit der Funktion SetupComm sogar noch in der Größe
verändern.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tjo aber wenn du win beschäftigst und es nix vom fifo holt ist nix mit
großem buffer...

aber dann musst du auch einen realtime prozess haben der richtig
rechenleistung frisst...

73

Autor: René König (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans, das ist, mit Verlaub, Quark. Die serielle Schnittstelle wird über
Interrupts gesteuert. Da kann ich Windows beschäftigen wie ich will;
solange keine andere Kernel-Komponente auf einem ausreichend hohen
DIRQL läuft, wird immer aus dem FIFO gelesen. Die Wahrscheinlichkeit,
daß da was verloren geht, geht gegen Null; mir ist das jedenfalls noch
nicht vorgekommen.

Ein Realtime-Prozess nutzt Dir nicht die Bone, denn Dein Prozess liest
sowieso nichts aus den FIFOs. Das Lesen übernimmt der Treiber, und auf
dessen Priorität hast Du keinen Einfluss. Mach die Buffer ausreichend
groß, und gut ist's.

BTW: Rechenzeit verschlingen kann auch ein Nicht-Realtime-Prozess. Und
wenn das tatsächlich beim Zugriff auf die Serielle passiert, verwendet
wohl jemand Polling. Das macht aber sogut wie niemand, ist mir auch
noch nicht untergekommen. Das ist also auch kein Problem.

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.