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
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?
"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.
"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.
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
Meines Wissens nach hat Win intern noch einen extra Buffer. Bei mir gehen erst nach genau 4096byte Daten verloren, wenn ich nichts auslese
> 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.
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
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.
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.