Hallo, ich habe einen Lwip-Stack auf dem LPC2468 Board heruntergeladen, an sich läuft alles gut, was mich aber ärgert, das der Prozessor ca.25 Sekunden braucht, bis er in die Main-Routine springt.Ich weiss nicht vielleicht ist das eine normale Verzögerung, die die Bearbeitung des Startup-Codes und die Initialisierung einiger Modulen braucht, bis er dazu kommt meine LED zu steueren. Vielleicht aber auch nicht, was meint ihr denn?
Auf einem MCB2300 (LPC2368) dauert es gefühlte 2s mit und 3s ohne angeschlossenem Netzwerkkabel bis die Initialisierung ab- geschlossen ist. uIP und LwIP verhalten sich da gleich. Ich vermute das es die PHY (DP83848) ist die diese Zeit benötigt. Ohne Netzwerkcode läuft main() praktisch sofort los. Wird bei dir vielleicht nicht auf den Quarz+PLL umgeschaltet? Dann läuft der Chip mit dem internen RC-Oszillator. Ich meine der arbeitet mit 4MHz.
Kannst du vielleicht deinen Startup-Code hochladen, das wäre super. Danke.
Nador Rif wrote: > ich habe einen Lwip-Stack auf dem LPC2468 Board heruntergeladen, an sich > läuft alles gut, was mich aber ärgert, das der Prozessor ca.25 Sekunden > braucht, bis er in die Main-Routine springt.Ich weiss nicht vielleicht > ist das eine normale Verzögerung, die die Bearbeitung des Startup-Codes > und die Initialisierung einiger Modulen braucht, bis er dazu kommt meine > LED zu steueren. Vielleicht aber auch nicht, was meint ihr denn? Ist bei dir DHCP aktiv? Hört sich an, als ob der der Stack probiert eine IP zu bekommt und anschließend mit Timeout abbricht. Gruß Jörn
Im opt.h ist folgendes über DHCP zu finden:
1 | /* ---------- DHCP options ---------- */
|
2 | |
3 | #ifndef LWIP_DHCP
|
4 | #define LWIP_DHCP 0
|
5 | #endif
|
6 | |
7 | /* 1 if you want to do an ARP check on the offered address
|
8 | (recommended). */
|
9 | #ifndef DHCP_DOES_ARP_CHECK
|
10 | #define DHCP_DOES_ARP_CHECK 1
|
11 | #endif
|
Muss ich vielleicht DHCP_DOES_ARP_CHECK auf null setzen?
Hi die 2-3s kann ich bestätigen bei aktiviertem DHCP, angeschlossenem Netzwerkkabel und eigenem Low-Layer Ethernettreiber auf einem SMSC Netzwerkchip. Die Zeit braucht einfach die Autonegotiation bis das Interface oben ist. Matthias
>Muss ich vielleicht DHCP_DOES_ARP_CHECK auf null setzen? Nee, hat leider nichts gebracht. >die 2-3s kann ich bestätigen bei aktiviertem DHCP, angeschlossenem >Netzwerkkabel und eigenem Low-Layer Ethernettreiber auf einem SMSC >Netzwerkchip. Die Zeit braucht einfach die Autonegotiation bis das >Interface oben ist. Und wo vergeht bei mir die ganze Zeit?
Nador Rif wrote: >>Muss ich vielleicht DHCP_DOES_ARP_CHECK auf null setzen? > Nee, hat leider nichts gebracht. > >>die 2-3s kann ich bestätigen bei aktiviertem DHCP, angeschlossenem >>Netzwerkkabel und eigenem Low-Layer Ethernettreiber auf einem SMSC >>Netzwerkchip. Die Zeit braucht einfach die Autonegotiation bis das >>Interface oben ist. > Und wo vergeht bei mir die ganze Zeit? Vllt. wartet Dein Code ja auf einen nicht antwortenden DHCP-Server? 25s klingt eigentlich nach so was...
Hier mal ein LwIP Beispiel ohne RTOS. Ich glaube das habe ich aus der LPC2000 Gruppe von Yahoo. Ich habe die EMAC Initialisierung für den 2368 Rev. B angepaßt. Das Projekt läßt sich mit einem installierten Yagarto einfach mit 'make' übersetzen.
let wrote: > Hier mal ein LwIP Beispiel ohne RTOS. Ich glaube das habe ich > aus der LPC2000 Gruppe von Yahoo. > > Ich habe die EMAC Initialisierung für den 2368 Rev. B angepaßt. > Das Projekt läßt sich mit einem installierten Yagarto einfach > mit 'make' übersetzen. Danke dir, das ist aber der LWIP-Stack, den ich benutze. Ich glaube, ich weiss jetzt woran es liegt, ich habe den Stack auf den LPC2468-Embedded Artists Board portiert, der benutzte Ethernet Controller da ist KSZ8001, deswegen musste ich den EMAC.c dafür anpassen.Ich glaube irgendetwas stimmt da nicht, es wäre echt Klasse wenn jemand, der sich damit auskennt einen Blick dareinzuwerfen(siehe Anhang) , vilelen vielen Dank!
Ich habe auch noch was gemerkt, wenn ich 30 UDP-Pakete sende maht der uC dicht, ich komme langsam zur Verzweiflung!
Zu deiner PHY kann ich leider nichts sagen. Naja, zur Dallas PHY eigentlich auch nicht, die Funktioniert mit dem Code einfach ;). Wobei sich da sicher noch das eine oder andere optimieren läßt. Aber wie verschickst du denn UDP Pakete? Gibst du den verwendeten pbuf jedesmal wieder frei?
Du findest im Anhang die Initialisierung und die Send-Routine.
Ich mache das mit einem udp_connect()/udp_send() und beim pbuf_alloc() gebe ich PBUF_RAM als Typ an.
1 | IP4_ADDR(&ip, sGlblArgCmdSetIP.iServerIP_0, sGlblArgCmdSetIP.iServerIP_1, sGlblArgCmdSetIP.iServerIP_2, sGlblArgCmdSetIP.iServerIP_3); |
2 | udp_connect(conn, &ip, 333); |
3 | |
4 | ...
|
5 | |
6 | buf = pbuf_alloc(PBUF_TRANSPORT, sizeof(struct ServerData), PBUF_RAM); |
7 | memcpy(buf->payload, (void*) &cmd, sizeof(struct ServerData)); |
8 | udp_send(conn, buf); |
9 | pbuf_free(buf); |
Dein Code sollte so aber auch funktionieren. Ich habe die Geräte hier nicht aufgebaut, sodaß ich deine Variante im Moment nicht ausprobieren kann. Ist die PBUF_POOL_BUFSIZE bei dir groß genug für ein Paket?
Das größte UDP-Paket ist 6Byte groß und PBUF_POOL_BUFSIZE ist 128. Wenn ich jetzt PBUF_RAM als Typ angebe, nach 31 UDP-Pakete bekomme ich keine Antworten vom uC, kann man irgendwo die Größe von PBUF_RAM bestimmen?
Muss man eigentlich der empfangene Puffer auch freigeben?
Sobald man die empfangenen Daten verarbeitet hat muß auch der PBUF freigegeben werden. Bis dahin gehört der Puffer dir. Ich bin zeitlich etwas eingeschränkt aber vielleicht komme ich heute Abend dazu mal ein Projekt für das MCB2300 zu bauen das fleißig UDP Pakete sendet.
Kannst du mal bitte in der Receive-Routine reinschauen und mir Bescheid sagen, ob dir etwas einfällt, Danke.
So, an deinem Receive fällt mir nichts auf. Ich habe mal ein Projekt erstellt das alle 500ms ein UDP-Paket raussschickt. Vielleicht hilft dir das weiter. Die Zieladresse muß noch angepaßt werden, sonst gibt es nichts außer ARP-Requests.
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.