Hallo zusammen, ich habe mir die Libary lwIP für die STM32F4 Familie von ST heruntergeladen und versucht das Beispiel Projekt udp_echoclient in meiner System Workbench for STM32 einzubinden. Leider erhalte ich nachdem ersten build eine reihe von Fehlermeldungen, welche Sourcen der Libary betreffen. Unter anderem wird keine Definition zu "MEMP_UDP_PCB" gefunden (und einigen weiteren Symbolen). Ich habe sämtliche Dateien manuell durchsucht und diese auch nicht gefunden. Nur ein Symbol "MEMP_NUM_UDP_PCB". Ist dieser Fehler bekannt? Desweiteren habe ich viele Fehler mit "undefined reference to". Die Quelltext der Funktionen erreiche ich habe über STRG und Klick auf den Funktionsnamen. Beim weiteren Klicken bietet mir die IDE zwei Headerfiles zur Auswahl wo es den Prototypen gefunden hat. Ich hoffe Ihr könnt mir weiterhelfen. Danke
Gast
#4714846
schau mal in die mem.h und memp.h irgendwo da wird eine definition der ganzen MEMP_xxx angelegt. das problem habe ich auch das der compiler meckert , es aber dennoch kompiliert.
Gast
#4715166
Danke, habe ich jetzt auch nach langem Kopfzerbrechen herausgefunden. Anscheinend führt diese Definition
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
zu den Problemen. Build führt zu Fehlermeldungen, aber Ausführen und Debuggen funktioniert wieder
Ich habe folgenden Code aus einem Beispiel genommen und eine einfache Senderoutine hinzugefügt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
Leider empfange ich die gesendeten Daten nicht. Erkennt einer einen Fehler und kann mir Tipps geben worauf ich zu achten habe? Der Link - Interrupt funktioniert.
Was sagt denn der Debugoutpout vom lwip? Schalt den mal ein, der ist sehr ergiebig ;) Kommt denn überhaupt nen ARP vom lwip? Der muss ja noch die MAC zur IP finden bevor das Paket auf Reisen gehen kann.
Was meinst du mit Debugoutpout? Der Hinweis auf das ARP ist gut. Der angesprochene Teilnehmer müsste ja darauf sofort reagieren. Werde ich prüfen.
Der lwip hat ne integrierte Debugausgabe. Guck doch mal in den Headerfiles nach dem Debugout, den auf einen deiner UART umbiegen. Dann in der config den Debug einschalten bis auf Info level runter. Der lwip sagt dir dann von alleine wo der Schuh drückt ;)
Gast
#4720979
Danke für die Rückmeldung. Muss ich dann eine serielle Verbindung zu meinem Pc über RS232 herstellen?Oder wo bekomme ich die Meldungen angezeigt?
Naja, bevor man mit nem IP Stack anfängt sollte man schon wissen wie man die UART Ausgabe eines µC auf ein Terminal aufm PC angezeigt bekommt ;) Ansonsten dieses Tutorial zum LWIP Einbau schon gefunden? http://www.st.com/resource/en/application_note/dm00036052.pdf Ist jetz zwar Atmel, aber Punkt6 ist was du lesen willst: http://www.atmel.com/Images/Atmel-42233-Using-the-lwIP-Network-Stack_AP-Note_AT04055.pdf Für jedes Modul, dass Debugausgabn machen soll muss das define in der config.h gesetzt werden. Dein printf, welches auf deinem UART ausgibt, muss in der platform.h oder cc.h angelegt werden. Dazu sollte dein STM32 Beispielcode eigentlich schon was mitgeliefert haben.
Gast
#4721883
Das habe ich auch hinbekommen. Über ein einfaches UASART_send() empfange ich Daten auf meinem Terminal, aber leider nicht vom TCP / IP Stack. Das ST Tutorial hatte ich auch schon gefunden. Beim Senden über UDP vom uC an den Laptop wird der ARP gesendet und der Laptop antwortet auch mit der MAC Adresse, allerdings werden dann keine Daten gesendet.
Der lwip erwartet auch nen printf und keine normale Stringausgabe. Zur not eben mit nem snprintf in nen Stringbuffer schreiben und das mit deiner UASART_send() raussenden. Wenn ein ARP kommt ist das schonmal gut. Es kommt auch genau ein ARP? Dann empfängt der lwip das auch, würde die Empfangsroutine nicht gehen, dann würde er nochmal ARPen (kann ja nen Paketverlust sein.) zip mal dein lwip und häng den hier rein.
Ich hatte über USART_send() nur überprüft ob die Verbindung zwischen uC und PC funktioniert, da eine Ausgabe über printf nicht funktionierte. Es kommt genau ein ARP und darauf eine Antwort mit der MAC Adresse. Mein Projekt ist im Anhang. Es ist das Beispielprojekt von udp_echoclient von ST.
Da Blick ich jetz nich durch, der lwip Ordner ist völlig anders als wenn
man ihn normal runterläd.
Da musste wohl selber in deiner IDE gucken wo zB ein
LWIP_DEBUGF(TCPIP_DEBUG, ("tcpip_thread: API message %p\n", (void
*)msg));
Im Endeffekt rauskommt.
Ühne Debugausgabe ist es erstmal nich möglich zu gucken wieso da nix
passiert.
Gast
#4723379
Es wird das Raw/UDP Interface von LwIP verwendet das ohne RTOS auskommt. udp_send() wird zunächst versuchen die MAC Adresse zu dem Rechner mit der angegebenen IPv4 Adresse zu finden. Die hat er aber nicht. Also wird ein ARP Request versendet um diese MAC Adresse anzufordern. Mehr passiert nicht. udp_send() kehrt danach zum Aufrufer zurück. Und dort werden sofort udp_disconnect() + udp_remove() aufgerufen. Wie könnte so jemals das eigentliche UDP Paket gesendet werden?
Danke für den Hinweis. Auf Ethernet-Ebene wird doch erst geprüft ob die MAC Adresse des Ziels vorhanden ist. Wenn nicht wird versucht diese über ARP vom Empfänger zu bekommen.Ich bin davon ausgegangen das anschließend das Paket auch versendet wird. Müsste ich dann udp_send() erneut, nachdem die MAC-Adresse ermittelt wurde, aufrufen? In dem Beispiel von st wird nach drücken eines Buttons folgende Funktion zum Senden aufgerufen
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
Dort wird nachdem senden nur der Buffer wieder freigegeben. Aber auch hier wird nachdem ARP keine Daten gesendet. Bei erneutem Aufruf der Funktion wird laut Wireshark ein ECHO gesendet (ICMP?). Auf dieses aber keine Antwort kommt.
Im Anhang der Wireshark-Mitschnitt
@MW En In der debug.h ist es definiert
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
Der Wireshark Eintrag: Mit ECHO 70 Request ist für die gesendeten Daten. Ich hatte in meinem Empfangsprogramm den falschen Port ausgewählt. Deshalb habe ich dort nichts empfangen. @ Stefan: Du hast natürlich recht. Mein Code im ersten Beispiel kann so nicht funktionieren.
Gibt es eine Möglichkeit empfangene Daten über Ethernet über einen Interrupt Handler zu verarbeiten. in den Beispiel ist immer nur ein Polling in der main() aufgeführt.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Wie bekomme ich Zugriff auf die empfangenen Nutzdaten in meiner Applikation?
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.
