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.
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.
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.
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.
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.
