|
Anzeige
|
STM32F746 Discovery Schlafmütze
Gast
#4545728
Mit dem EMAC Treiber unter LWIP hab ich den seltsamen Effekt das ich nach einer Weile erst das Board anpingen muß um Zugriff auf den HTML Server zu erhalten. Da mbed rtos nicht in Frage kommt vermute ich das die Defaulteinstellungen des LAN8742A Chips nicht stimmen. Weiß einer welches Bit in welchem PHY Register zu setzen ist um diesen Effekt abzuschalten? m.f.G. Dieter Gräf F7 kann Daten cachen. DMA nach SRAM1/2 muss das beachten, sonst gibt es seltsame Effekte. Abhilfen: - DCACHE nicht einschalten, was aber den Zugriff auf Daten im Flash enorm verlangsamt - Sicherstellen, das DMA Buffer nur aus dem DTCM Ram genommen werden - Cache Flush an der richtigen Stelle Beschrieben z.B. unter http://chibios.org/dokuwiki/doku.php?id=chibios:articles:cortexm7_dma_guide Was spricht gegen RTOS Mbed? Hast Du einen Blick auf Ethernut SVN Head geworfen? https://sourceforge.net/projects/ethernut/files/
Gast
#4545817
Uwe B. schrieb: > - DCACHE nicht einschalten, was aber den Zugriff auf Daten im Flash > enorm verlangsamt Es sei denn, man greift per ITCM auf den Flash zu und lässt den ART an, dann brauchts den D-Cache nicht. Ist laut irgendeiner AppNote angeblich sogar minimal schneller - jedenfalls kann der D-Cache sich dann auf den SRAM konzentrieren. Glaube aber kaum dass es daran liegt. Ist wohl eher ein Problem mit dem Network Stack: Dieter Graef schrieb: > um Zugriff auf den HTML > Server zu erhalten. Das ist doch eine sehr vage Fehlerbeschreibung. Reagiert der IP-Stack denn auf den TCP-Verbindungsaufbau? Kommt da überhaupt was zurück? Dieter Graef schrieb: > vermute ich das die > Defaulteinstellungen des LAN8742A Chips nicht stimmen. Du meinst dass der irgendwann nur noch ICMP Pakete, aber keine IP Pakete mehr durchlässt? Klingt unwahrscheinlich, da der PHY sich den Payload der Frames gar nicht anschauen sollte...
Gast
#4545833
Dr. Sommer schrieb: > Ist laut irgendeiner AppNote PS: Habe sie gefunden (AN4667): http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00169764.pdf Auf S. 27 sieht man dass Ausführung aus dem Flash per ITCM+ART ganze 0,064% schneller ist als per AXI+DCache, also praktisch gleich. Dr. Sommer schrieb: > Uwe B. schrieb: >> - DCACHE nicht einschalten, was aber den Zugriff auf Daten im Flash >> enorm verlangsamt > > Es sei denn, man greift per ITCM auf den Flash zu und lässt den ART an, > dann brauchts den D-Cache nicht. Ist laut irgendeiner AppNote angeblich > sogar minimal schneller - jedenfalls kann der D-Cache sich dann auf den > SRAM konzentrieren. Ich rede von Daten im Flash! Und Daten bekommt der F7 nicht aus dem ITCM. Mit einem fundierten Gegenbeweis lasse ich mich aber ueberzeugen... Codezugriff ueber ITCM mit ggf aktivierten ART braucht aber Code, der nach 0x00200000 gelinkt ist. Das ist zumindestens gewoehnungsbeduerftig.
Gast
#4545853
Uwe B. schrieb: > Ich rede von Daten im Flash! Achso, sag das doch :o) Normal greift man ja nicht auf viele Daten im Flash zu, aber bei einem Webserver kann das wohl anders aussehen... Uwe B. schrieb: > Das ist zumindestens gewoehnungsbeduerftig. Na, eine andere Zahl ins Linkerscript zu schreiben ist jetzt keine große Umgewöhnung. Nur der J-Link ist verwirrt wenn man ihm sagt dass er an Adresse 0x00200000 flashen soll (erkennt/erkannte er nicht als Flash), aber dem kann man mit einer AT> Anweisung aushelfen:
Dann kann man wie gewohnt ganz "normal" programmieren, man sollte halt bloß den ART einschalten. Bei über Http ausgelieferten Daten über die Latenz von Flash zu meckern erscheint mir als ein Luxusproblem... Praktisch wird sich das abschalten des Cache nicht auswirken.
Gast
#4545881
Dr. Sommer schrieb: > Du meinst dass der irgendwann nur noch ICMP Pakete, aber keine IP Pakete > mehr durchlässt? Klingt unwahrscheinlich, da der PHY sich den Payload > der Frames gar nicht anschauen sollte... stimmt tatsächlich er wacht auch mit web auf wenn man geduldig den Refreshknopf drückt. bei Ping siehts so aus: Ping wird ausgeführt für 192.168.2.26 mit 32 Bytes Daten: Antwort von 192.168.2.23: Zielhost nicht erreichbar. Antwort von 192.168.2.26: Bytes=32 Zeit=1005ms TTL=255 Antwort von 192.168.2.26: Bytes=32 Zeit=3ms TTL=255 Antwort von 192.168.2.26: Bytes=32 Zeit=5ms TTL=255 da werd ich wohl lwip durchforsten müssen. Dr. Sommer schrieb: > Achso, sag das doch :o) Normal greift man ja nicht auf viele Daten im > Flash zu, aber bei einem Webserver kann das wohl anders aussehen... Der Server holt sich die Daten von der SD Karte das fand ich am bequemsten. m.f.G. Dieter
Gast
#4545886
Dieter Graef schrieb: > stimmt tatsächlich er wacht auch mit web auf wenn man geduldig den > Refreshknopf drückt. Na sowas. Schau dir doch mal mit Wireshark an was passiert wenn du das erste mal (erfolglos) die Seite aufrufst. Kommt da irgendwas zurück? Dieter Graef schrieb: > Der Server holt sich die Daten von der SD Karte das fand ich am > bequemsten. Das ist auf jeden Fall langsamer als der interne Flash... Vielleicht ist die Karte in einem Standby Modus oder wird gar abgeschaltet? Setz doch mal Breakpoints in die Zugriffsfunktion und rufe dann die Website auf...
Gast
#4545969
Ich hätt im wirklichem Leben Sleepmodedebugger werden sollen.Immer schön Kaffetrinken und 2 mal am Tag eine Taste drücken. Jetzt kommts: mit den Optionen #define LWIP_DEBUG und #define NETIF_DEBUG LWIP_DBG_ON kommt der Fehler nicht. Was mach ich denn nu? m.f.G. Dieter
Gast
#4546175
Dr. Sommer schrieb: > Vielleicht ist > die Karte in einem Standby Modus oder wird gar abgeschaltet? Setz doch > mal Breakpoints in die Zugriffsfunktion und rufe dann die Website Wie immer hat Dr. Sommer recht.Es ist die SD Karte. Den Treiber hatte ich von der 1Bit SPI Fraktion übernommen und nur auf 4 Bit getrimmt. Ich werd mal gucken ob ich nicht bei jedem fopen direkt bei der Karte gucken muß ob sie noch 4Bit kann. m.f.G. Dieter
Gast
#4546711
Problem gelöst: Man muß bei der Statusabfrage welche vor jedem open aufgerufen wird nicht nur den Vorhandenseinpin abfragen sondern den Kartenstatus direkt abfragen, dann wacht sie wieder auf. m.f.G. Dieter
Gast
#4546909
Ergebnis hier: https://developer.mbed.org/users/DieterGraef/code/SDFileSystem/ m.f.G. Dieter Antwort schreiben |
Anzeige
|
