Hat jemand von euch Erfahrungen mit der Kombination STM32F107 + Hal + Externer MAC (DP83867E). Es wird kein RTOS benutzt. Ich habe einen FPGA per SPI angebunden, der Daten als Master in den STM32 schiebt. Wenn ein Datenpaket da ist wird das in eine lockfree queue geschrieben und im main thread gesendet. Ich komme auf maximal 300 Kilobyte/s Transferrate. Der PC ist schnell genug. Wenn jemand schonmal so etwas gemacht hat mit diesem Prozessor wäre ich für einen Hinweis dankbar was man so zu erwarten hat oder ob das schon gut ist.
Du hast vergessen zu erwähnen welches Protokoll du verwendest. Aber ich vermute mal UDP da du von Paketen sprichst. Natürlich könnte man auch per TCP Pakete schicken, aber das ist sicherich aufwendiger im Handling. Die Datenrate deines SPI ist auch noch relevant. Da der F107 nicht zu den schnellsten gehört (max 72 MHz) wäre an der Taktfrequenz sicherlich noch eine Steigerung möglich, sowohl in in der Arbeitsgeschwindigkeit des Controllers als auch in der Taktfrequenz des SPI. Immerhin könnte man bei einem F407 die SPI Taktrate auf 84 MHz setzen und den Controller mit 168MHz laufen lassen. Allerdings kann ich zu der Kernfrage, ob 300kB/sec schon "gut" ist, keine genaue Aussage machen. Klingt jedenfalls schon mal nicht schlecht für den F107. Hmmmm, wie soll man diese Aussagen verstehen? Martin schrieb: > Es wird kein RTOS benutzt. Martin schrieb: > im main thread gesendet
:
Bearbeitet durch User
Wastl schrieb: > Du hast vergessen zu erwähnen welches Protokoll du verwendest. Die Paketgrösse ist sicherlich auch mitbestimmend wie schnell die Übertragung läuft. Der Overhead von LwIP ist ggf. nicht zu vernachlässigen.
Du benutzt das DMA vom STM32...? Wartet der STM32 auf Bestätigung vom PC oder sendest du die Pakete als endloser Strom raus?
Also hier noch die fehlenden Infos: * Der FPGA schreibt Daten mit 10 MHz zum STM32. Theoretische maximale Datenrate ist hier also schonmal auf 1,25 MByte/s begrenzt unter der Annahme, dass der FPGA pausenlos sendet. Der STM32 kann dem FPGA per Pin aber sagen aufzuhören. Damit habe ich eine Flusskontrolle realisiert, damit ich dem FPGA sagen kann, dass der FIFO im STM32 gerade kurz davor ist voll zu sein. * Der STM32 wird mit seiner maximalfreuqenz betrieben und der PHY über RMII verbunden. * Ich verwende bewusst kein UDP, sondern TCP. Die Daten sind bereits im FPGA verarbeitet und werden vom PC erwartet. Die Reihenfolge ist relevant, da es im Datenpaket keine Sequenznummer gibt und Verluste nicht toleriert werden sollen. Bevor ich da selbst etwas per UDP bastel kann ich auch direkt TCP nehmen, was all meine Anforderungen schon unterstützt. Ich habe jetzt mal mit dem MEMP_NUM_TCP_SEG, TCP_WND und TCP_MSS gespielt. Es scheint tatsächlich eine erheblichen unterschied zu machen wie hoch man MEMP_NUM_TCP_SEG setzt. Eine Erhöhung auf 300 hat mir die Datenrate jetzt auf 700 kByte/s erhöht, was immerhin etwas mehr als die Hälfte der maximalen SPI Datenrate ist. Was ich mit Paketen übrigens meine sind meine Telegramme, die ich über TCP sende. Das sind Pakete fester länge, die im FPGA erstellt werden.
Angehängte Dateien:
Interessehalber habe ich gerade mal mit UDP gespielt, Grundlage meiner Versuche ist das hier: Beitrag "UDP-Netzwerke(l)n mit kleinen Mikrocontrollern und WizNet W5100/W5500" Das Ganze auf einen STM32F103 implementiert und getestet mit folgenden Parametern - Ethernet Controller W5500 (nicht W5100) - F103 Core Takt 72 MHz - SPI Takt 36 MHz zum W5500, DMA Transfer - Block-Grösse 1024 Bytes - UDP Transfer an PC ohne Handshake Ergibt für den einzelnen Transfer also etwa 2.5 MByte/sec für ein einzelnes UDP Paket.
Schau mal ob dein Sender überhaupt das tcp-window richtig nutzt und brauchbares Flow-Control implementiert. Zum Einstieg in das Thema: https://www.youtube.com/watch?v=sIxv3YO2eYw Es gibt jede Menge beliebig schlechte IP-Stacks. Oder stell mal hier ein *.pcap rein.
:
Bearbeitet durch User
Wastl schrieb: > - Ethernet Controller W5500 (nicht W5100) Einen externen IP-Stack zu nutzen ist wohl kaum vergleichbar... Da könnte man den W5500 auch direkt an den FPGA anbinden. Vermutlich hat der lwIP nicht genug Pufferspeicher. MEMP_NUM_TCP_SEG, TCP_WND und TCP_MSS zu erhöhen ist sicher sinnvoll. Trenn doch mal die ganze FPGA-Kommunikation ab und sende immer wieder das gleiche Datenpaket. Versuch zu prüfen ob lwIP lange auf ACK-Pakete wartet.
Martin schrieb: > Es scheint tatsächlich eine erheblichen unterschied zu machen wie hoch > man MEMP_NUM_TCP_SEG setzt. Natürlich. Mit dem extremen Wert 1 machst du jeden Computer zur Schnecke. Es geht ja darum, die nächsten n IP Pakete schon "im Voraus" zu senden, während auf ein ACK gewartet wird. Je länger die Antwortzeiten sind, umso mehr MEMP_NUM_TCP_SEG sind nötig, damit es nicht zu Übertragungspausen kommt.
:
Bearbeitet durch User
Wastl schrieb: > Hmmmm, wie soll man diese Aussagen verstehen? > > Martin schrieb: >> Es wird kein RTOS benutzt. > > Martin schrieb: >> im main thread gesendet
Wastl schrieb: > Wastl schrieb: >> Hmmmm, wie soll man diese Aussagen verstehen? >> >> Martin schrieb: >>> Es wird kein RTOS benutzt. >> >> Martin schrieb: >>> im main thread gesendet Es ist nur der Hinweis, dass ich kein freeRTOs oder ähnliches nutze. Das lesen der SPI Daten läuft per DMA und interrupt. Wenn ein Interrupt stattfindet wird aus dem completion handler, also aus dem Interrupt selber heraus, das Datenpaket auf eine MPSC queue geschoben und sofort der nächste Transfer gestartet. Interrupts sind eine Art Thread.
Martin schrieb: > kein UDP, sondern TCP Sendet nur der Microcontroller Richtung PC oder antwortet der PC drauf? Es gibt in TCP jede Menge Gemeinheiten, die die Datenrate bei einseitigem Datentransfer einbrechen lassen. Ein paar Ideen: Die Daten in möglichst großen Paketen versenden, am besten die MTU komplett ausreizen. Ansonsten wird dich gerade Windows als Empfänger mit "Delayed Ack" ärgern. (Windows wartet eine gewisse Zeit bevor es den ACK sendet, fall noch Daten mitkommen sollen, Linux auch, das merkt aber irgendwann, das der PC nix senden will) Der lwIP wartet möglicherweise auf das ACK bevor er das nächste Packet versendet. Unter Linux kann man delayed ack auch per setsockopt abschalten. Ich weis nicht, welche API Du verwendet, wenn du auf der raw api bist, dann hilft eventuell ein "tcp_output(pcb)" nachdem du die Daten geschrieben hast. Der lwip wird dann alle noch Ausstehenden daten versenden, egal ob noch ACKs ausstehen. MEMP_NUM_TCP_SEG muss dann aber groß genug sein. Es gibt bei der lwip api die möglichkeit den zusätzlichen Kopiervorgang der Daten von "Applikation" -> "LwIP" zu unterbinden. Mann muss sich dann Gedanken über die Speicherverwaltung machen, spart sich aber einen Kopiervorgang. So als Zahlen, wir haben ein System wo der lwIP auf dem Mikrocontroller läuft und ein externes System die Daten per Parallelschnittstelle an liefert. Das ganze in einem RTOS mit diversen Tasken, also noch gut Overhead durch Task-Kontextwechsel sowie die Kommunikation mit dem externen System. Unser Mikrocontroller ist ein Cortex-M4 mit 100 MHz: Ich habe Dir mal ein aktuelles Log von unseren Tests angehangen. Das Thema mit der MTU sieht man sehr gut im "Socket_SendTo_TCP/single packet" dort gibt es einen gehörigen Sprung zwischen 1025 und 1460 Datengröße. Die wesentlich niedrigere Geschwindigkeit auf der "RecvFrom" Seite hängt mit unserem Testaufbau zu sammen.
Was mir noch einfällt. Der lwIP hat verschiedene Varianten vom IP Checksum Algorithmus implementiert. Die liefern je nach System unterschiedliche Performance. Wie sieht es mit dem Ethernet Checksumen Algorithmus aus? Macht das der MAC im F107 oder macht Ihr das in Software?
Ich kann dir nur sagen das es nicht am LWIP liegt. Ich habe damit bei zwei unterschiedlichen µC Herstellern (TI und Atmel) die 100 MBit/sec annähernd erreicht. Das TI Teil hatte 128 kByte und lief bei ca. 72 MHz, Atmel bei 300 MHz und 256k. Die Buffergrössen sind wichtig wenn mehrere Router dazwischen hängen, aber auf so niedrige Werte bin ich nie gekommen. Vermutlich liegt es an der SPI Kommunikation oder Bugs. Schau dir mal das Timing mit einem Osci an.
Moin, Martin schrieb: > Ich komme auf maximal 300 Kilobyte/s Transferrate. > Der PC ist schnell genug. Daraus und aus der Existenz dieses Threads schliesse ich mal, dass dir diese Transferrate bei Weitem nicht ausreicht. Was ich an dem Projekt anders gemacht haette: Kein TCP verwenden, sondern UDP. Das dann auch gleich im FPGA erzeugen und nicht ueber die CPU laufen lassen. Zusaetzlich dann halt einen kleinen Ethernetswitch bzw. im FPGA sowas in primitiv implementieren. Natuerlich ohne MAC-Tabellen oder so einen Kram. Wenns wirklich gute Gruende geben sollte, warum das Netz, in dem diese UDP Pakete unterwegs sind, so scheisse sein muss, dass da Pakete verschuett' gehen, gibts auch fuer UDP einiges an "Erweiterungen", die das merkbar/korrigierbar machen (RTP, 2d-FEC) und die sich immernoch deutlich leichter im FPGA bauen lassen, als TCP. Dann ist die ganze Geschichte in der CPU voellig entspannt und geht Datenratenmaessig bis zum Maximum, was Link und Paketgroesse hergeben. Gruss WK
Andreas M. schrieb: > Es gibt bei der lwip api die möglichkeit den zusätzlichen Kopiervorgang > der Daten von "Applikation" -> "LwIP" zu unterbinden. Mann muss sich > dann Gedanken über die Speicherverwaltung machen, spart sich aber einen > Kopiervorgang. Dann muss allerdings das Zeug solange liegen bleiben bis TCP-Retransmits von den Daten ausgeschlossen sind.
G. K. schrieb: > Dann muss allerdings das Zeug solange liegen bleiben bis TCP-Retransmits > von den Daten ausgeschlossen sind. Ja klar. An die Info kommt man aber ran, wenn man weiß wie.
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.