Hallo,
ich habe in den letzten Tagen "versucht" die Standalone Webserver Demo
von STM auf dem Discovery-Board mit dem STM32F4 zum laufen zu bekommen
(PHY = DP83848C von TI)
(in den Beispielen unter "STM32F4x7_ETH_LwIP_V1.0.0")
während der Implementierung hab ich einen Fehler bei mir gesehen,
den (laut Internet suche) auch andere schon hatten
Im File "stm32f4x7_eth_bsp.c" wird ein Software Reset gestartet :
1
ETH_SoftwareReset();
und dann in der Zeile darunter wird gewartet, bis das Reset-Flag
zurückgesetzt wird :
1
while (ETH_GetSoftwareResetStatus() == SET);
nun kommt es ab und zu vor, das dieses Flag NIE zurückgesetzt wird
und damit die Software in einer Endlosloop hängt
im Internet hab ich keine abschließende Lösung für dieses Problem
gefunden und hoffe das sich hier jemand meldet, der sich damit auskennt
als Workaround gibt es folgende vorschläge von Usern :
1. den "Enable ETHERNET clock" nach dem Software Reset machen
2. den Pin PA8 als MCO konfigurieren (obwohl der nicht benutzt wird)
Mit dem Punkt-2 funktioniert es bei mir, nur warum weiss ich nicht :-(
Gruss Uwe
@Uwe B. (derexponent)
Ich habe seinerzeit auch die Standalone Webserver Demo
von STM auf dem Discovery-Board
Beitrag "Re: ST-Discovery-Net-IO Anfang"
benutzt.
Die GUI(Display-Init) wäre nicht gestartet ohne erfolgreiche LAN-Init;
Uwe B. schrieb:> nun kommt es ab und zu vor, das dieses Flag NIE zurückgesetzt wird> und damit die Software in einer Endlosloop hängt
Das kann ich daher so nicht bestätigen ?!
>mit stat.IP für meinen>Router umgeschrieben
kannst auch DHCP aktivieren
>Das kann ich daher so nicht bestätigen ?!
der Fehler ist ja auch nicht immer da
aber mach mal zum spass die Initialisierung
vom PA8 raus...dann hab ich bei mir den Fehler immer
IDE ist CooCox 1.7.0 (optimierung = NONE)
ARM GCC ist 4.7-2012-q4
(falls das noch eine Rolle für den Fehler spielt)
Uwe B. schrieb:> nun kommt es ab und zu vor, das dieses Flag NIE zurückgesetzt wird> und damit die Software in einer Endlosloop hängt
Die Antwort steht im Reference Manual RM0090 unter 28.4.4
"The application has to set the MII/RMII mode while the Ethernet
controller is under reset or before enabling the clocks."
Also ist das Beispiel von ST falsch.
Torsten S. schrieb:> or before enabling the clocks.
Also, zumindest das nützt wohl nichts.
Ohne dieses -ominöse- ( PA8 muss aktiviert werden, obwohl unbenutzt)
habe auch ich diesen "Fehler" !
vampire schrieb:> Also, zumindest das nützt wohl nichts.> Ohne dieses -ominöse- ( PA8 muss aktiviert werden, obwohl unbenutzt)> habe auch ich diesen "Fehler" !
Bei mir schon sonst geht gar nichts. (Wir sprechen doch vom
Waveshare-Modul mit RMII-Interface?) Also:
1
/* Reset ETHERNET on AHB Bus */
2
ETH_DeInit();
3
4
/* Software reset */
5
ETH_SoftwareReset();
6
7
/* Wait for software reset */
8
while(ETH_GetSoftwareResetStatus()==SET);
9
10
/* Enable ETHERNET clock */
11
RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC|
12
RCC_AHB1Periph_ETH_MAC_Tx|
13
RCC_AHB1Periph_ETH_MAC_Rx,
14
ENABLE);
Wenn man sich genau ans Manual hält könnte
SYSCFG_ETH_MediaInterfaceConfig(SYSCFG_ETH_MediaInterface_RMII);
zwischen ETH_SoftwareReset();
und
while (ETH_GetSoftwareResetStatus() == SET);
möglicherweise besser funktionieren.
Ja, -das- ist ja richtig!
Torsten S. schrieb:> /* Wait for software reset */> while (ETH_GetSoftwareResetStatus() == SET);
.nur hier hängt es, wenn PA8 nicht als
/* Configure MCO (PA8)*/
// possible BUG ?? UB (PA8 muss aktiviert werden, obwohl unbenutzt)
configuriert wird.
Habe ich in der weiter oben erwähnten Software ebenfalls drin. Da
allergings wird noch je nach
Auszug:***********************************************************
/* MII/RMII Media interface selection
--------------------------------------*/
#ifdef MII_MODE /* Mode MII with STM324xG-EVAL */
#ifdef PHY_CLOCK_MCO
GPIO_Init(GPIOA, &GPIO_InitStructure);
/* Output HSE clock (25MHz) on MCO pin (PA8) to clock the PHY */
RCC_MCO1Config(RCC_MCO1Source_HSE, RCC_MCO1Div_1);
#endif /* PHY_CLOCK_MCO */
SYSCFG_ETH_MediaInterfaceConfig(SYSCFG_ETH_MediaInterface_MII);
#elif defined RMII_MODE /* Mode RMII with STM324xG-EVAL */
SYSCFG_ETH_MediaInterfaceConfig(SYSCFG_ETH_MediaInterface_RMII);
#endif
******************************************************************
MII/RMII unterschieden;
vampire, dachte bei Dir läuft alles?
MCO und Eth_Link_EXTI sind genau wie ein WLAN-Kabel: nicht vorhanden und
deswegen überflüssig. Habs rausgeschmissen.
Vielleicht ist es genauso wichtig, nur die Pins zu initialisieren die
auch gebraucht werden und nicht einfach alle so wie im Beispiel. Soll
heißen:
@ Torsten S. (tse)
Torsten S. schrieb:> vampire, dachte bei Dir läuft alles?
Ja. Ich bezog mich hier auf die Frage von:
Uwe B. schrieb:> nun kommt es ab und zu vor, das dieses Flag NIE zurückgesetzt wird> und damit die Software in einer Endlosloop hängt>> im Internet hab ich keine abschließende Lösung für dieses Problem> gefunden und hoffe das sich hier jemand meldet, der sich damit auskennt>> als Workaround gibt es folgende vorschläge von Usern :> 1. den "Enable ETHERNET clock" nach dem Software Reset machen> 2. den Pin PA8 als MCO konfigurieren (obwohl der nicht benutzt wird)
wobei ich spez. den Punkt2 betrachtete;
Hi ihr beiden, hier nochmal mein Fehlerbild
>Vielleicht ist es genauso wichtig, nur die Pins zu initialisieren die>auch gebraucht werden
genau das hab ich gemacht...ich hab aus dem Beispiel von STM alles
rausgelöscht was nicht notwendig ist beim Discovery-Board
(u.a. auch den MII-Mode)
damit bleibt übrig :
im ETH_GPIO_Config :
@ Uwe B. (derexponent)
Es ist sogar noch krimineller:
-habe dein timeout rausgenommen und dies in ETH_GPIO_Config(void):
/* Configure MCO (PA8)*/
// possible BUG ?? UB (PA8 muss aktiviert werden, obwohl unbenutzt)
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_100MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL ;
// GPIO_Init(GPIOA, &GPIO_InitStructure); <------------ hier
also den PA8 Pin nur in der InitStructure;
wird auch hier nicht angesprochen(etwas weiter unten)
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_7;
für diese Pins wird die AF ja ausgewählt mit:
GPIO_PinAFConfig(GPIOA, GPIO_PinSource1, GPIO_AF_ETH);
GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_ETH);
GPIO_PinAFConfig(GPIOA, GPIO_PinSource7, GPIO_AF_ETH);
-während für PA8 die AF als MCO wohl festgelegt ist, so das mit der
GPIO_Init(GPIOA, &GPIO_InitStructure);
in diesem Block auch PA8 --> MCO inititiert wird(aber nicht
aktiviert!!!);
Wenn ich <-- hier drinlasse, habe ich die MCO Frequ. auf dem PA8;
Die Leitungslänge zum PHY ist kritisch und sollte möglichst kurz sein.
Bei mir hab ich jeder Datenleitung noch 47R in Reihe spendiert um das
s.g. ringing zu reduzieren.
Merkwürdigerweise muß bei mir ETH_BSP_Config() gleich an erster Stelle
in der main aufgerufen werden. Mach ich das nicht, schmiert das ext.
SRAM und LCD ab. Mag sein das der PHY nach der Initialisierung
ordentlich Saft braucht und die Spannungsregler kurz einknicken.
Hi Torsten,
>Clock-Enable (A,B,C)>Clock-Enable (SYSCFG)>Config (PA1, PA2, PA7)>Config (PB11, PB12, PB13)>Config (PC1, PC4, PC5)>ETH_SoftwareReset();>SYSCFG_ETH_MediaInterfaceConfig(SYSCFG_ETH_MediaInterface_RMII);>while (ETH_GetSoftwareResetStatus() == SET);>Clock-Enable (ETH_MAC, ETH_MAC_Tx, ETH_MAC_Rx)
hab ich gerade ausprobiert...geht auch nicht :-(
wenn ich PA8 wieder mit reinmache :
geht wieder alles ...ich glaube man muss nicht alles verstehen :-)
Danke trotzdem, ich werde jetzt einfach drüber hinwegsehen
und PA8 halt mit drin lassen
Gruss Uwe
Habe Uwes Beispiel für den KS8721 auf dem Olimex STM32F4-E407
modifiziert.
Wichtig: Mein E407 hat einen 8MHz-HSE-Quartz.
Wesentliche Änderungen: PA8 rausgeschmissen, Pins für das andere Gehäuse
angepasst und Interrupt-Handling deaktiviert (größter Unterschied
zwischen den beiden PHYs). Ich war angenehm überrascht, dass der Server
anlief und auch auf CGI reagiert. Toller Ausgangspunkt für verschärfte
Tests...
-> Vielen Dank an Uwe für das Coocox-Projekt! <-
Marcus H. schrieb:> Wesentliche Änderungen: PA8 rausgeschmissen, Pins für das andere Gehäuse> angepasst und Interrupt-Handling deaktiviert (größter Unterschied> zwischen den beiden PHYs). Ich war angenehm überrascht, dass der Server> anlief und auch auf CGI reagiert. Toller Ausgangspunkt für verschärfte> Tests...
Gut zu wissen das ich nicht der einzige bin der PA8 nicht braucht ;)
Marcus, meinst Du mit dem rausgeschmissenem Interrupt-Handling dieses
Link-Status-Detection Zeugs? Das geht auf Grund des nicht vorhandenem
INT-Pins im RMII-Mode onehin nicht.
@Torsten S.: Olimex ist so freundlich Ihre Schaltpläne als PDF und
EAGLE-Files ins Netz zu stellen. Und da ist der MDINT an den STM32
angesclossen. Im Datenblatt habe ich auch keinen Hinweis gefunden, dass
die PHY im RMII-Betrieb keine Interrupts kann.
Die Stabilität des Codes muss sich nun zeigen. Hardwaremäßig dreht's mir
beim E407-Board den Magen um - 2 Lagen für solche Signale. Ist aber
marginal vorhersagbarer als z.B. eine Fädellösung. ;)
Hat jemand mit einem LAN8710 gearbeitet?
Ich würde den gerne einsetzen bzw. hab noch ein paar hier.
Eigendlich dürfte im RMII dieser PHY gleich funktionieren oder sehe ich
das falsch?
Was müsste geändert werden?
@bastler: Aua, schubs net so.
Uwes Demo ist unter ausschließlicher Verwendung von PHY
Standardregistern zum Laufen zu bringen. Die komplette Parametrierung
läuft über Bootstrap-Widerstände. Weiterführende Funktionen (z.B.
Interrupt) kann man erstmal beiseite legen.
Vergleiche Deinen (fliegenden?) Aufbau mit einem funktionierenden (z.B.
Olimex STM32F4-E405, mit KS8721).
Ich hatte Uwes Code und die Datenblätter von DP/KS offen und bin die
Init im Debugger durchgesteppt und habe den Code Stück für Stück
angepasst.
Danke Marcus!
>Uwes Demo ist unter ausschließlicher Verwendung von PHY>Standardregistern zum Laufen zu bringen.
Das wollte ich hören bzw. lesen.
Mein Aufbau ist momentan (Halb-) fliegend.
Aber eine Antwort vom PHY hätte ich vorerst mal erwartet, wenn auch
keine Verbindung zur Außenwelt.
Das Olimex-Board hab ich mir gestern bestellt, bei den Preisen kann man
ja nicht meckern.
Vermutlich muss ich eh umschwenken auf den KS8721, da der LAN8710 in
QFN32 zwar lörbar ist, aber das Exposed Pad mach Probleme.
Nochmals Danke an die Forumseinträge, damit müsste es gelingen.
@Bastler: dann mal viel Spass mit dem E407.
Zu dem Board ein Hinweis: das Teil ist "kostenoptimiert". Ein genialer
Layouter entflocht hier einen 144-Pinner auf zwei Lagen. Das hat zur
Folge, dass alle Messungen auf diesem Board quasi ein
worst-case-Scenario darstellen.
Das Board funktioniert digital auf dem Labortisch. Analogsignale sind
mit Vorsicht zu betrachten.
Ich nehme diese Boards nur als Demonstratoren, danach geht es ASAP auf
Multilayer-PCB weiter.
Wenn man das so im Hinterkopf behält, ist das Preis-Leistungsverhältnis
mehr als gut. Die sogar in EAGLE gelieferten Schaltungsunterlagen haben
bei der Einarbeitung sehr geholfen.
Mein kompletter Versuchsaufbau zum Webserver-Test ist:
- E407 mit 8MHz HSE-Quartz (auf allen meinen STM32-Boards vom
F100..F407)
- USB-Kabel für E407 Power
- JTAG-Debugger
- USB-Kabel für Debugger
Mein Ziel ist es letztenendes den Webserver auf einem F107 zum laufen
zum bringen.
Ich bräuchte ein paar kleine Ethernet Module für Ansteuerungen.
Die STM Familie ist ja relativ kompatibel untereinander von daher bin
ich ganz zuversichtlich was die Machbarkeit angeht.
Ich hatte für erste Versuch den LWIP Stack von der ST Homepage
runtergeladen da dieser für den F107 angepasst ist.
Ich bin aber momentan zu blöd das Projekt in Coocox zu bekommen.
>Ich bin aber momentan zu blöd das Projekt in Coocox zu bekommen.
woran scheitert es denn genau ?
ich habe am LwIP-Stack so gut wie keine Ändereungen vornehmen müssen,
nur ein paar Kleinigkeiten um die Warnings zu beseitigen
der Rest lief dann sofort
Gruss
Das Projekt von hier lässt sich ohne Probleme compilieren nur das
Beispiel von der ST Hompage macht Probleme.
Vermutlich liegt es an den Pfadangaben.
Ich hatte noch keine Zeit (und Lust mehr) mich damit genauer zu
befassen.
CooCox hat einige Header nicht gefunden und al ich die entsprechenden
Ordner zugelinkt hatt gab es andere Fehler (weiß momentan nicht
auswendig).
Darum bin ich echt sehr dankbar ein "fertiges" Projekt hier gefunden zu
haben.
Uwe,
da sprichst Du ein sehr heißes Thema an: Die Umsetzung von Keil/IAR
Projekten nach Coocox. Ich stolpere regelmäßig über Nuancen bei den
ST-Bibliotheken und Coocox Bibliotheken. Ich glaube nicht, dass das nur
Pfadeinstellungen sind.
Man kann den Frust von unserem "Bastler" nachvollziehen.
Genau das macht Deine Website so wertvoll - Du gibst uns übersetzbare
Coocox Projekte.
Wenn Du zu Deiner Vorgehensweise was erzählen möchtest - das wäre ein
Thread den ich gespannt verfolgen würde. Vielleicht kann ich dazu auch
noch was beitragen, was eher Coocox/GCC betrifft. (Beispiel für 407er
Linkerskript Stack im CCM, Stack anpassen, Aligment für DMA).
Oder haben wir irgendwo einen passenden Thread "STM32 Coocox"?
Cheerio...
Hallo nochmals.
Ich hänge immernoch in
> while (ETH_GetSoftwareResetStatus() == SET);
Pins wie bereits hier erwähnt geändert, Ethernet Clock nach Reset, aber
nichts ...
Gibt es sonst noch was zu beachten?
Achso: Habe das STM32F4-Discovery und ein DP83848 Board von Waveshare.
Verdrahtet laut Anleitung.
Hallo Bastler,
ich schätze, irgendwas in Deiner Verdrahtung passt nicht. Die
verschiedenen RMII-PHY's laufen ansonsten wie ein Uhrwerk.
Oder ist es die PHY-Adresse?
Ich weiß nicht wie teuer Du Deine begrenzte Lebenszeit einschätzt.
Mein Tipp wäre, auf eine Hardware zu wechseln, die einfach tut.
Nur als Beispiel: STM32-E407 von Olimex. Derzeit begrenzt erhältlich
z.B. bei Farnell für ca. 60€. Sonst 40€ bei Olimex.
Grüße,
Marcus
P.S.: denk Dir doch mal einen Namen aus - dann ist das Gespräch nicht so
semi-anonym.
Schon wieder Werbung für Olimex.
Das Discovery + WaveShare-Modul tuns bei vielen anderen und bei mir
auch. Für kleines Geld und zuverlässig.
Bastler
Die Strippen zum PHY müssen so kurz wie möglich sein, sonst geht gar
nichts. Außerdem braucht AutoNegotiation eine ganze Weile. Probiers doch
mal fest auf 100M zu setzen:
Oh Torsten,
ich schrieb doch "nur als Beispiel".
Es geht doch nur darum, die Anzahl der möglichen Fehlerquellen
einzuschränken. Und dazu ist es halt schön, wenn man wenigstens eine
bekannte Ausgangsplattform hat. Das Entscheidende ist - auf dem E407
läuft der lwIP.
Aber ich freue mich, dass Du Bastlers Hardware kennst. Ich bin gespannt
zu verfolgen, wie Ihr beiden das Teil zum Rennen bekommt. Dann lernen
wir alle was draus.
Grüße,
Marcus
Das Olimex liegt schon hier, ich wollte es trotzdem mal so testen.
Aber Verständnisshalber:
Ist " while (ETH_GetSoftwareResetStatus() == SET);"
nicht auf den internen MAC bezogen?
Findend hier schon ein Austausch mit dem PHY statt?
Ich glaub ich hab da was verwechselt...
Hatte mehrere Baustellen, das ist nicht gut, da weiß man nicht mehr wo
was ist...
Ich schau es mir mal in RUHE an, bzw. passe ich die Pins aufs Olimex
Board an.
Ziel ist sowieso eine eigens Layout.
> Ich schau es mir mal in RUHE an, bzw. passe ich die Pins aufs Olimex> Board an.> Ziel ist sowieso eine eigens Layout.
Aha.
Marcus, Du bist wieder dran. ;)
@Torsten: Danke!
@Whoevermightbeinterested:
Im Anhang ein Schaltungsauszug, für eine KS8721 am STM32F407VG.
Basiert auf dem E407_RevB. Die beschriebenen Bauteile sind für den
Fertiger gut erhältlich.
Für das Layout geben die F407- und die KS8721-Doku Tipps, damit man weiß
weiß, welche Besonderheiten die einzelnen Signale haben (HF, Strom,
Rauschen, etc...).
Ich habe mir bei Ebay ein DP8xxxx Board bestellt und mit kurzen
Leitungen und einer >Lochraster an das STM32f4 Discovery rangelötet.
Alle Verbindungen sind richtig (mehrmals überprüft), Kontakt ist da, die
Leitungen sidn kurz und trotzdem bekomme ich es nicht zum
Laufen.....Habe es mit einer statischen IP und mit DHCP probiert. Bin
schon am Verzweifeln, mit stm32f107 ging es damals auf Anhieb. Weiß
jemand, wo man eine 100% funktionsfähige Demo für stm32f4discovery und
dp83848 bekommt?
mmax hat mich per PM nach meinem E407 Code gefragt:
Das von mir damals verwendete E407 gibt es in der Form nicht mehr.
Olimex hat eine neue Version mit einer anderen PHY rausgebracht. :(
Zum Glück verhalten sich die PHYs ziemlich ähnlich, mit
Herstellerspezifischen Sonderfunktionen.
Uwe hat damals eine sehr gute Vorlage gemacht, die nur gering angepasst
werden muss:
- Schaltplan / Pinout vergleichen und anpassen
- PHY-Datenblatt: ID, Register, Adressen vergleichen und anpassen
- Interruptverhalten? (im Zweifelsfal weg damit...)
Damit bekommst man Uwes Code auf so ziemlich jeder PHY zum laufen.
Grüße,
Marcus
P.S.: Und im Anhang, wie gewünscht, ein paar Codeschnippsel
Ich kriege mein discovery board mit der DP Phy einfach nicht zum laufen.
Die Software ist von hier:
Beitrag "Re: STM32 Fehler in Webserver Software von STM" und läßt sich
wunderbar kompilieren. Nach der Initialisierung bleibt die rote LED an
und das Board läßt sich nicht anpingen. Wenn ich netscan laufen lasse,
blinkt die grüne LED vom DP und die orange LED ist immer an (sieht erst
mal gut aus). Die Leutungen zw. der MCU und dem DP mehrmals überprüft.
Keine Leitung ist länger als 5cm. Trotzdem keine Chance... Jemand eine
Idee, was man machen könnte?
Hallo,
der Thread ist zwar schon etwas älter, aber da ich das selber Problem
hatte, muss ich die Lösung noch einmal preisgeben:
Bei mir lief die Software auch nicht durch. Nach den Tipps aus diesem
Thread habe ich dann PA8 auch wieder aktivert (was mir eigentlich nicht
passt, da dort ein anderes Signal drauf liegt). Aber siehe da: Auch bei
mir funktioniert es nun.
Die Lösung ist aber so einfach, dass sie wieder zu trivial war.
Ich hatte den folgenden Block auskommentiert:
Ich durfte gerade eine Webserverdemo für eine fremde Baugruppe mit
STM32F207 und KSZ8863MLL aufsetzen, unter Atollic TrueStudio 5.4.0.
Im Nachhinein alles kein Drama, muss nur die Resetschaltung und die
Pinstrappings passen.
Anschließend noch die F207 spezifischen Treiber auf die Hardware
anpassen und gut ist.
Fabian schrieb:> Das Problem ist nun aber nicht das Signal auf A8, sondern das> GPIO_InitStructure hier für die folgenden Ports eingerichtet wird.
Dieses Stück trickreiche Programmierung hat wahrscheinlich schon
Mannjahre gekostet - bin heute Nachmittag auch wieder zu viele Minuten
an der Stelle gehangen...
Alter Thread, ich weiß es, passt aber hier her.
Das ST Beispiel STM32F107_ETH_LwIP_V1.0.0 (stsw-stm32026.zip) als CoIDE
1.7.8 Projekt für ein Olimex STM32-P107 Board Rev.D mit STM32F107VC und
LAN8710A PHY im RMII mode geclockt vom MCO Pin des Controllers. Das
Programm startet im Webserver Modus mit DHCP. Über die Webseite können
die beiden LEDs des Boards geschaltet werden, eine Rückmeldung gibt es
aber nicht. Auf der ADC Seite wird der Wert 123 (etwa 1/4 des Balkens,
der auf 1/8 von 4096 = 512 (width=520) skaliert ist) angezeigt. Display,
ADC und SD-Karte, sowie die Auswertung der IRQ-Leitung vom PHY aus dem
Beispiel habe ich rausgeworfen. Ein fertig compiliertes HEX-File liegt
bei.
Kein Hexenwerk, aber vielleicht für jemanden hilfreich.
Gruß
Bernd
Was mich momentan beschäftigt, ist der enorme RAM Bedarf des lwIP
stacks.
Im obigen Beispiel sind insgesamt ca. 55 kb (von 64kb) belegt.
Ich habe mittlerweile von dem vorher geposteten Beispiel ausgehend auf
die "aktuelle" lwIP Version 1.4.1 umgestellt und mit freeModbus V1.5
einen kleinen Modbus Server laufen.
Bei meiner aktuellen Konfiguration sind insgesamt ca. 53kb RAM belegt.
Der RAM Bedarf des lwIP stacks hängt stark von der konfigurierten
Bufferanzahl und Größe ab. Es ist ein Kompromiss zwischen möglicher
Netzwerkgeschwindigkeit und RAM Verbrauch. Da neben anderen Effekten bei
zu kleinen Buffern u.a. eine zerwürfelte Übertragung aus mehreren
Datenpaketen nicht mehr zusammen gesetzt werden kann und ggf. neu
übertragen werden muss.
Die low level Empfags- und Sendebuffer (Rx_Buff (4x1520 Byte, Tx_Buff
(2x1520 Byte) in ethernetif.c belegen zusammen alleine etwa 9kb RAM.
1520 Byte sind dabei (so wie ich das verstanden habe) genug Platz für
einen kompletten Ethernetframe. Diese Einstellung stammt aus dem
Beispiel von ST.
In diese Buffer kopiert der DMA Daten.
Im lwIP Stack sind zwei große RAM Bereiche reserviert. Das ist auch
schön im Map file zu sehen.
Es wird eine dynamische Speicherverwaltung, im Prinzip ein Heap,
verwendet.
Im Beispiel wird dazu in mem.c das Array ram_heap der Größe MEM_SIZE
(definiert in lwipopts.h) verwendet. Hier sind das stolze 20 kb.
TCP_MSS steht auf 1460. Was recht großzügig ist.
Der zweite große RAM Bereich kommt aus ..\obj\memp.o
Mit PBUF_POOL_BUFSIZE = 1514 und PBUF_POOL_SIZE = 10 sind es gute 16 kb.
Die pbuf Buffer scheinen hier zu liegen.
Hier ist mir nun nicht ganz klar was in welchem der beiden Bereiche
liegt.
Vielleicht ist es mit den low level Buffern aus ethernetif.c auch etwas
doppelt gemoppelt.
Kann mir jemand einen Hinweis zu den beiden großen Speicherbereichen von
lwIP geben, was wo liegt?
Kann mir hier auch jemand Tipps zu vernünftigen Buffergrößen geben?
Am Ende sollen zwei Geräte miteinander Modbus TCP sprechen.
Da habe ich also eine gute Chance den vorhandenen Datenverkehr zu
analysieren bzw. zu bestimmen. Das sollte doch helfen?!
Hi Bernd,
ich finde es schön, dass Du in der heutigen Zeit 55kB als "enorm"
bezeichnest. ;)
Du hast eine Besonderheit der lwIP Speicherverwaltung schon beschrieben
- das Teil baut sich seine eigene Pufferverwaltung auf und läuft daher
auch auf Systemen ohne "malloc". Die maximale Speicherbelegung ist zur
Compilezeit bekannt, das macht die Firmware pflegeleichter.
Du kannst übrigens auch eine andere Speicherverwaltung verwenden.
lwIP reicht Paketpuffer durch alle seine Schichten durch. D.h. was die
DMA in den Empfangspuffer kopiert, wird nacheinander von
Headerinformationen befreit, bis z.B. das Paket beim HTTP-Handler
landet.
Wie groß die Puffer in Deiner Applikation sein müssen, kannst nur Du
wissen. Stichwort Datenrate und Paketverlust.
Für "Hello Worlds" kommst Du auch mit 20kB und weniger zurecht, in dem
o.g. F207 Beispiel hingen aber noch 256kB externes RAM dran.
Modbus TCP Applikation? Das sollte eher was kompaktes werden. Wenn's Dir
um Stabilität geht, dann versuche doch mal im "worst case"-Betrieb die
Pufferauslastung zu berechnen oder zu messen.
Oder ggf. bei verschiedenen Puffergrößen mit Wireshark die Performance
kontrollieren (Reaktionszeit, Datenrate, Paketverluste, Resend).
Grüße,
Marcus
Marcus H. schrieb:> Hi Bernd,> ich finde es schön, dass Du in der heutigen Zeit 55kB als "enorm"> bezeichnest. ;)
Bei 64kb vorhandenem RAM ist das schon viel, wenn alleine der Ip Stack
über 40kb braucht. Ich vermute nur, dass es wahrscheinlich auch mit
weniger in meinem Fall funktionieren würde.
> Du hast eine Besonderheit der lwIP Speicherverwaltung schon beschrieben> - das Teil baut sich seine eigene Pufferverwaltung auf und läuft daher> auch auf Systemen ohne "malloc". Die maximale Speicherbelegung ist zur> Compilezeit bekannt, das macht die Firmware pflegeleichter.> Du kannst übrigens auch eine andere Speicherverwaltung verwenden.
Ja, das ist mir auch bekannt, aber wie du schon sagst, hat es so den
Vorteil, dass man den maximalen Bedarf kennt.
> lwIP reicht Paketpuffer durch alle seine Schichten durch. D.h. was die> DMA in den Empfangspuffer kopiert, wird nacheinander von> Headerinformationen befreit, bis z.B. das Paket beim HTTP-Handler> landet.
Mir ist nur noch nicht ganz klar geworden, was in welchem der beiden
beschriebenen Bereiche landet. Der pbuf pool ist wohl in dem Array in
memp.o Aber warum muss der heap dann noch so groß sein?
> Wie groß die Puffer in Deiner Applikation sein müssen, kannst nur Du> wissen. Stichwort Datenrate und Paketverlust.> Für "Hello Worlds" kommst Du auch mit 20kB und weniger zurecht, in dem> o.g. F207 Beispiel hingen aber noch 256kB externes RAM dran.>> Modbus TCP Applikation? Das sollte eher was kompaktes werden. Wenn's Dir> um Stabilität geht, dann versuche doch mal im "worst case"-Betrieb die> Pufferauslastung zu berechnen oder zu messen.> Oder ggf. bei verschiedenen Puffergrößen mit Wireshark die Performance> kontrollieren (Reaktionszeit, Datenrate, Paketverluste, Resend).
Ja an sowas habe ich gedacht. Die Durchführung ist mir noch nicht ganz
klar. Aber ich probiere da erstmal.
Thread beobachten
Seitenaufteilung abschalten