Hallo, Ich suche ein Board mit Cortex-M4 und der Möglichkeit, dass ich Ethernet nutzen kann, um über TCP/IP zu kommunizieren (zB Webserver/Client). Im Grunde ist die Sache klar: soweit ich das verstanden habe, brauche ich irgendein Board, welches den MAC-Teil implementiert und kann dann irgendein PHY Breakout Board wie z.B. das DP83848 nutzen, korrekt? Als Board würde ich z.B. ein STM32F407 nehmen. Nun bin ich etwas unerfahren in dem Thema und habe ein paar Fragen. Wenn ich LwIP nutze, was soweit ich das sehe die Standard Lösung für TCP/IP für so ein Board ist, wie viel RAM und ROM verbrauche ich damit grob? Was wäre eine geeignete (= einfache und effiziente) Möglichkeit, um Daten während der Ausführung des Programmes auf dem Mikrocontroller rauszuschreiben? Ich würde gerne nachvollziehen, was das Programm auf dem Board gemacht hat :) Habt ihr sonst noch Hinweise oder Empfehlungen für mich? Im Prinzip hätte ich gerne ein nicht allzu teures Setup (also kein 200€ Entwicklerboard). Und wenn ich das richtig sehe, dann ist ein STM32F407 recht verbreitet, d.h. ich habe gute Chancen, Tutorials/HowTos, Antworten auf meine sicherlich aufkommenden Fragen und funktionierende Tools zu finden, richtig?
>Im Grunde ist die Sache klar: soweit ich das verstanden habe, brauche >ich irgendein Board, welches den MAC-Teil implementiert und kann dann >irgendein PHY Breakout Board wie z.B. das DP83848 nutzen, korrekt? Ja. >Als Board würde ich z.B. ein STM32F407 nehmen. Nimm ein Nucleo Board, da gibt es viele wo Ethernet schon komplett drauf ist. Kein basteln notwendig, eine Fehlerquelle weniger.
Danke, ich gucke mir die Nucleos mal an. Ich verstehe nicht so genau wo die Unterschiede zwischen den beiden Reihen im Detail liegen. Die Nucleos sind hauptsächlich mir Arduino Shields kompatibel, oder? Aber ich vermute mal, es wird sowieso keinen Unterschied für mich machen. Letztendlich brauche ich weder OS, noch ganz spezielle Schnittstellen (außer Ethernet natürlich). Danke!
Muz123 schrieb: > Als Board würde ich z.B. ein STM32F407 nehmen Das ist aber kein Board, sondern ein Mikrocontroller bzw. eine Gruppe davon. Als Board würde ich mir an deiner Stelle ein Nucleo-144 holen, z.B. mit einem F446ZE.
Muz123 schrieb: > Danke, ich gucke mir die Nucleos mal an. Ich verstehe nicht so genau wo > die Unterschiede zwischen den beiden Reihen im Detail liegen. Welche Reihen von was? > Die Nucleos sind hauptsächlich mir Arduino Shields kompatibel, oder? Das ist nur ein zusätzliches Bonus-Feature. So richtig kompatibel sind sie aber nicht, da viele Pins nur 3,3V unterstützten und mit anderen Funktionen belegt sind. Nur wenige Shields passen dazu. Die "normalen" Anschlüsse sind die doppelreihigen Stiftleisten, heißen Morpho-Connector.
Stefanus F. schrieb: > Welche Reihen von was? Er meint die Reihe von Discovery(ies) und die Reihe von Nucleos. So schwer?
Dumpfbacke schrieb: >> Welche Reihen von was? > Er meint die Reihe von Discovery(ies) und die Reihe von Nucleos. Es gibt zahlreiche Nucleo-64 Boards, die sich im Prinzip nur durch den aufgelöteten Mikrocontroller unterscheiden. Siehe https://www.st.com/content/ccc/resource/technical/document/user_manual/98/2e/fa/4b/e0/82/43/b7/DM00105823.pdf/files/DM00105823.pdf/jcr:content/translations/en.DM00105823.pdf Bei der Nucleo-144 Reihe ist das auch so, wobei nicht alle Boards mit Ethernet Anschluss bestückt sind. Siehe https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf
Muz123 schrieb: > Letztendlich brauche ich weder OS LwIP passt gut zur Nutzung mit RTOS. Es geht aber auch ohne, da lwIP komplett asynchron programmiert ist. Ohne RTOS kann man aber nur das "raw" API nutzen. Das ist sowieso am Effizientesten, aber umständlicher zu bedienen als das auch von Linux/Unix bekannte Socket-API.
Stefanus F. schrieb: > Bei der Nucleo-144 Reihe ist das auch so, wobei nicht alle Boards mit > Ethernet Anschluss bestückt sind. > > Siehe > https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf Ähhm, ja, das von mir oben erwähnte F446ZE-Nucleo hat natürlich keinen. Stattdessen dann eben ein Nucleo mit F429ZI oder F439ZI nehmen.
Ich habe mit dem Ti msp432 gute Erfahrungen: https://www.mouser.at/ProductDetail/Texas-Instruments/MSP-EXP432E401Y?qs=j%252B1pi9TdxUbU%2FFmadQLPsg Der uC hat die Ethernet Phy bereits integriert. Bei den Beispielen, die mit dem Board kommen, ist ein Webserver und ein Client bereits dabei. Neben lwip kannst du auch den Ti eigenen Stack verwenden. Neben Freertos ist auch das Ti eigene rtos dabei. Ein einfacher Webserver und Client braucht ca 50 MB, RAM, ohne Rtos.
Der Link oben geht nicht, gemeint ist das 40 € MSP-EXP432E401Y Board. Debuggen kannst du wie gewohnt über rs232 Terminal
udok schrieb: > Ein einfacher Webserver und Client braucht ca 50 MB, RAM, ohne Rtos. Wow! Ich kenne andere Embedded Webserver, die mit 4kB auskommen.
udok schrieb: > Ich habe mit dem Ti msp432 gute Erfahrungen: > https://www.mouser.at/ProductDetail/Texas-Instruments/MSP-EXP432E401Y?qs=j%252B1pi9TdxUbU%2FFmadQLPsg > > Der uC hat die Ethernet Phy bereits integriert. > > Bei den Beispielen, die mit dem Board kommen, ist ein Webserver und ein > Client bereits dabei. Neben lwip kannst du auch den Ti eigenen Stack > verwenden. > Neben Freertos ist auch das Ti eigene rtos dabei. > > Ein einfacher Webserver und Client braucht ca 50 MB, RAM, ohne Rtos. kB bitte. 50MB hat der MSP432 nicht. Ich stimme dem zu. Bei meinem Arbytegeber habe ich mehrere Designs mit TI TIVA TM4C129 am Laufen. Diese Serie ist sehr sehr ähnlich zum MSP432, bietet aber mehr Auswahl. Und das TI RTOS ist auch sehr in Ordnung. Anderer Vorschlag: PIC32. Ist zwar kein ARM, aber in der gleichen Leistungsklasse. Der Microchip Stack ist nach meiner Erfahrung deutlich besser als lwIP. Als Tipp: Lass die alten PIC32MX6xx/7xx liegen und nimm PIC32MZ EF. Damit bekommst Du fürs gleiche Geld einfach Faktor 2.5 mehr Rechenleistung. fchk
Christopher J. schrieb: > Muz123 schrieb: >> Als Board würde ich z.B. ein STM32F407 nehmen > > Das ist aber kein Board, sondern ein Mikrocontroller Stimmt, habe mich etwas unglücklich ausgedrückt :) Und ja, ich meinte Discovery Boards vs Nucleo Boards. Ich gucke mir eure Vorschläge später mal im Detail an, vielen Dank jedenfalls schon mal! > Ein einfacher Webserver und Client braucht ca 50 MB, RAM, ohne Rtos. Das ist schon relativ viel, zur Not aber okay. Wie kommt man denn dann z.B. auf die 4 KB, oder überhaupt in die Region deutlich unter 50 KB?
Ich würde mich jetzt einfach für ein F429ZI oder F439ZI entscheiden. Ich kann aber nirgends ablesen, wie viel RAM so ein Ding jetzt hat. 144 Pins, 2MB Flash, usw, usf. Aber RAM? Ich finde nur allgemeine Datenblätter wo für eine ganze Serie, zB F429/F439 "up to X MB" steht. Außerdem: Brauche ich einfach Micro-USB B? Es ist etwas verwirrend, weil an manchen Stellen etwas von Micro-USB AB steht.
Oh, zum RAM ich habe mich wohl verlesen / etwas im Datasheet Jungel verirrt. Es sind 256 KB. Sorry.
Angehängte Dateien:
-
snip.png
24 KB
Muz123 schrieb: > Es sind 256 KB. Und die sind ziemlich segmentiert.
Muz123 schrieb: > Wie kommt man denn dann z.B. auf die 4 KB Mit kleinen Puffern und kleinen Window-Sizes (im Extremfall 1, wie bei µIP). HTTP Responses werden während der Auslieferung blockweise generiert. Schön bunte HTMl Seiten liefert man damit aber wohl eher nicht aus. 8bit Quelltext und ein paar Screenshots: http://stefanfrings.de/net_io/index.html Bitte nicht nachmachen. Der knappe Speicher nervt kollossal, heute macht man so etwas mit 32bit Controllern.
> Und die sind ziemlich segmentiert. Oh. Mangels Erfahrung: Was sind die konkreten Auswirkungen? Kann ich das effizient nutzen bzw wird das irgendwie wegabstrahiert? Oder muss ich dann unschöne Dinge tun, wie, statt Speicher ganz normal auf dem Stack oder per malloc zu allozieren, selbst die Adressen auf den übrigen RAM Blöcken managen? > Mit kleinen Puffern und kleinen Window-Sizes (im Extremfall 1, wie bei µIP). > Mit kleinen Puffern und kleinen Window-Sizes (im Extremfall 1, wie bei µIP). Zur Einordnung, kann man damit sinnvoll arbeiten? Ich brauche keinen schicken Webserver, der Webserver ist eigentlich nur Mittel zum Zweck und es werden Daten kommuniziert. Ist aber eher als Proof of Concept zu verstehen, daher ist es auch egal, ob die Kommunikation jetzt X mal so lange dauert :) Wenn man dafür 50 KB RAM einspart (und man sie braucht), könnte man das überlegen. Das ist nichts, was ich direkt im ersten Schritt machen will, aber ich könnte es im Hinterkopf behalten.
Muz123 schrieb: >> Mit kleinen Puffern und kleinen Window-Sizes (im Extremfall 1, wie bei µIP). > kann man damit sinnvoll arbeiten? Ja kann man. Schau Dir das bereits genannte Ethernet-IO Projekt an (http://stefanfrings.de/net_io/index.html). Es funktioniert sehr zuverlässig. Gut genug für Alarmanlagen in Ferienhäusern und Beleuchtungsanlagen in Produktionshallen. Ich habe davon 8 Produkte verkauft ohne eine einzige Reklamation. Für mich war es nur ein Hobby-Projekt, die Firma Chip45 verkauft diese Dinger als Modul. Kleine Puffer bewirken, dass mehr Ethernet Pakete übertragen werden müssen, was die Performance herab setzt. Im lokalen Netz merkt man das kaum, bei längeren Strecken übers Internet aber schon. Wenn die Windows-Size kleiner ist, als von der Gegenstelle erwartet, entsteht nach jeden einzelnen Paket ein Delay von 200ms, bis es quittiert wird und damit die Übertragung des nächsten Paketes ermöglicht. Bei Webseiten sieht das in der Praxis so aus, das die Webseite Stückweise geladen wird, mit sichtbaren Pausen (200ms) zwischen den Paketen. Bei den Seiten meiner Ethernet-IO Firmware sind das 2-4 Stücke. Der Effekt ist unter Windows wesentlich stärker ausgeprägt, als unter Linux. Bei selbst geschriebenen Programmen, die mit dem µC kommunizieren, kannst du im Client die Option TCP-NODELAY setzen, dann wird jeden Paket vom Client sofort quittiert, so dass die 200ms Pausen entfallen. Bei UDP gibt es keine Verzögerungen, weil UDP nicht auf Quittierungen wartet.
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.