Hallo. Implementiere gerade Ethernet auf einem STM32F4. Soweit läuft die Kommunikation per UDP zwischen Windows-PC und STM32 stabil. Nur für meine Gefühle etwas langsam. Eine komplette Kommunikation liegt so bei 1-2ms. (1xUDP PC->STM32 & 1x UDP STM32->PC) Die Firmware hab ich schon "vermessen". Die Antwort geht nach weniger als 100us wieder zurück. (Nur wenige Bytes). Wo bleibt die Zeit? Kann man da was verkürzen? Vielen Dank schon mal. Pepe.
Pepe schrieb: > Wo bleibt die Zeit? Da würde ich mal ganz stark auf Windows tippen. > Kann man da was verkürzen? Keine einzelnen Bytes. Möglichst viel Nutzinformation in eine Übertragung.
Karl H. schrieb: > Möglichst viel Nutzinformation Habe ich schon möglichst versucht. Aber leider hat das Zusammenfassen bei meiner Anwendung (Ansteuerung von einzelnen Achsen) bald seine Grenzen erreicht. Gibt's irgendwelche Erfahrungswerte, wo man da zeitlich raus kommen könnte?
Ich denke im allgemeinen versucht man, die zeitkritischen Sachen auf dem Microcontroller zu machen (die sind für sowas schliesslich da) und den PC mit all seinen Störmöglichkeiten nur für die zeitunkritisch(er)en Aufgaben zu verwenden...
@Andreas K. Ausgangssituation sind Achscontrollerkarten, die direkt im PCI Bus stecken und somit Responsezeiten <200us haben. Jetzt sind wir dabei auf eine Ethernet-Lösung umzuziehen, da es mit den Karten ziemliche Einschränkungen gibt. Einen ziemlich großen Teil der Aufgaben haben wir schon im Mikrocontroller, aber es bleiben dummerweise noch einige Punkte, die nicht dort laufen können. Da z.B. auf dem PC noch ne Bildverarbeitung läuft und wir live auf die Ergebnisse reagieren müssen, können die Mikrocontroller nicht vollständig autark laufen.
Muss es Windows sein? Man könnte ja auch mal ein kleines schlankes Linux probieren.
Karl H. schrieb: > Da würde ich mal ganz stark auf Windows tippen. Vermutlich, hängt aber auch stark davon ab, welche APIs man unter Windows verwendet. Meiner Erfahrung nach bekommt man die beste Performance mit overlapped Socket I/O in Verbindung mit I/O completion routines.
Hallo, ich hab mal eine Wireshark Datei angehängt. PC W7 sendet Multicast Antwort von neun WizNet5500 angebunden über SPI 8MHz an ATXmega8E5@32MHz Responstime 219µs <= 285µs Auf Adapter prüfen ob Interruptdämpfung aus ist. Heißt von Adapter zu Adapter unterschiedlich oder man kann es nicht einstellen. UDP wird über Interrupt an Adapter übertragen. (Meines Wissens) Hat bei mir ca. 30% Geschwindigkeitsgewinn gebracht bei kontinuierlichem Stream.
@ThomasF Wie hast Du die Sende/Empfangsroutine unter Windows implementiert? Scheint wohl bei mir das größte Problem zu sein.
@Pepe Ist in C#. Wie hast Du gemessen? Im Programm habe ich noch keine Zeitmessung für die Antwortzeit durchgeführt. Bei mir kommt es auf einen kontinuierlichen Stream an. PC->MC. 9 * 724 Byte im 10ms Intervall. (Gemessen im Programm 1.2ms bis alle Daten gesendet wurden.( SockData.SendBufferSize = 0; kein Sendepuffer damit das Ergebnis nicht verfälscht wird)
Hab im Programm gemessen. Da komme ich auf Zeiten von 1.5-3ms. Rein im Wireshark habe ich 600-700us. Interruptdämpfung heißt bei meinem Treiber Interuptdrosselung. Geh davon aus, dass dies das gleiche ist. Hat aber auch nach Neustart keinen Unterschied gebracht.
Ich habe für diesen Zweck einen eigenen Adapter. Alles abgewählt außer Internetprotokoll V4. Ist ein "Intel(R) Gigabit-CT-Desktopadapte" angebunden über PCI-Express.
Ich hab den Stream mal aufgezeichnet. Im Wireshark sind es ca. 600µs (1.2ms ist der Durchschnitt)
Wenn du weniger als 1ms brauchst, brauchst du eine andere Schnittstelle und ein anderes Betriebsystem. Denn beide sind nicht für Verarbeitungsintervalle unter 1ms vorgesehen. Sicher kann man die ein oder anderen Tricks anwenden. Aber du wirst ganz schnell auf andere Ursachen stossen, die das Timing zumindest zeitweise versauen. Linux, Mac OS und Solaris sind dafür IMHO auch nicht besser geeignet.
Stefan U. schrieb: > Wenn du weniger als 1ms brauchst "Brauchen" ist relativ. Mir geht's um eine Optimierung der Responsezeit, weil jede Millisekunde, die ich nicht "auf der Strecke" verliere, muss ich nicht mehr aus meiner Anwendung rausquetschen oder kann einfach schneller werden.
Pepe schrieb: > Einen ziemlich großen Teil der Aufgaben haben wir schon im > Mikrocontroller, aber es bleiben dummerweise noch einige Punkte, die > nicht dort laufen können. Da z.B. auf dem PC noch ne Bildverarbeitung > läuft und wir live auf die Ergebnisse reagieren müssen, können die > Mikrocontroller nicht vollständig autark laufen. Du kannst weder unter einen normalen Windows oder Linux Reaktionszeiten von 1ms erwarten. Wenn ihr das aber für eure Aufgabe braucht, dann sollte ihr gleich auf Echtzeitsystem setzen oder das Konzept ändern. Eventuell gibt es ein paar Tricks um das irgendwie zu schaffen, aber eine Garantie das es immer funktioniert wird wohl niemand für die Produktion geben können.
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.