lwIP für STM32F4

[K. K. (caga001)]

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

[hust (Gast)]

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.

[caga001 (Gast)]

Danke, habe ich jetzt auch nach langem Kopfzerbrechen herausgefunden.

Anscheinend führt diese Definition

/* Create the list of all memory pools managed by memp. MEMP_MAX represents a NULL pool at the end */
typedef enum {
#define LWIP_MEMPOOL(name,num,size,desc)  MEMP_##name,
#include "lwip/memp_std.h"
  MEMP_MAX
} memp_t;

zu den Problemen.

Build führt zu Fehlermeldungen, aber Ausführen und Debuggen funktioniert 
wieder

[K. K. (caga001)]

Ich habe folgenden Code aus einem Beispiel genommen und eine einfache 
Senderoutine hinzugefügt.

int main(void)
{
  /*!< At this stage the microcontroller clock setting is already configured to 
       168 MHz, this is done through SystemInit() function which is called from
       startup file (startup_stm32f4xx.s) before to branch to application main.
       To reconfigure the default setting of SystemInit() function, refer to
       system_stm32f4xx.c file
     */

  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);

#ifdef SERIAL_DEBUG
  DebugComPort_Init();
#endif

  /*Initialize LCD and Leds */
  LCD_LED_BUTTON_Init();

  /* Configure ethernet (GPIOs, clocks, MAC, DMA) */
  ETH_BSP_Config();

  /* Initilaize the LwIP stack */
  LwIP_Init();

  /* Infinite loop */
  while (1)
  {

    static uint8_t data[] = {1,2,3,4};

    volatile err_t status;
    volatile uint8_t free = 0;

    struct udp_pcb * udp;

    udp=  udp_new();

    struct ip_addr * ip_stm32 = NULL;
    IP4_ADDR(ip_stm32,192,168,0,10);

    struct ip_addr * ip_laptop = NULL;
    IP4_ADDR(ip_laptop,192,168,0,11);

    status = udp_bind(udp, ip_stm32, 1234 );

    status = udp_connect(udp, ip_laptop, 1234 );

    struct pbuf *p;

    p = pbuf_alloc( PBUF_TRANSPORT, 4, PBUF_RAM ) ;
    p -> payload = data;
    p->tot_len = 4;

    status = udp_send(udp, p);

    free = pbuf_free(p);

    status = udp_disconnect(udp);

    status = udp_remove(udp);

      LwIP_Periodic_Handle(LocalTime);
  }
}

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[K. K. (caga001)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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 ;)

[caga001 (Gast)]

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?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[caga001 (Gast)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[K. K. (caga001)]

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.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

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.

[Stefan (Gast)]

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?

[K. K. (caga001)]

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

void udp_echoclient_connect(void)
{
  struct udp_pcb *upcb;
  struct pbuf *p;
  struct ip_addr DestIPaddr;
  err_t err;
       
  /* Create a new UDP control block  */
  upcb = udp_new();
  
  if (upcb!=NULL)
  {
    /*assign destination IP address */
    IP4_ADDR( &DestIPaddr, DEST_IP_ADDR0, DEST_IP_ADDR1, DEST_IP_ADDR2, DEST_IP_ADDR3 );
  
    /* configure destination IP address and port */
    err= udp_connect(upcb, &DestIPaddr, UDP_SERVER_PORT);
    
    if (err == ERR_OK)
    {
      /* Set a receive callback for the upcb */
      udp_recv(upcb, udp_receive_callback, NULL);
      
      sprintf((char*)data, "sending udp client message %d", (int*)message_count);
  
      /* allocate pbuf from pool*/
      p = pbuf_alloc(PBUF_TRANSPORT,strlen((char*)data), PBUF_POOL);
      
      if (p != NULL)
      {
        /* copy data to pbuf */
        pbuf_take(p, (char*)data, strlen((char*)data));
          
        /* send udp data */
        udp_send(upcb, p); 
        
        /* free pbuf */
        pbuf_free(p);
      }
      else
      {
        /* free the UDP connection, so we can accept new clients */
        udp_remove(upcb);
        #ifdef SERIAL_DEBUG
        printf("\n\r can not allocate pbuf ");
        #endif
      }
    }
    else
    {
      /* free the UDP connection, so we can accept new clients */
      udp_remove(upcb);
      #ifdef SERIAL_DEBUG
       printf("\n\r can not connect udp pcb");
      #endif
    }
  }
  else
  {
    #ifdef SERIAL_DEBUG
     printf("\n\r can not create udp pcb");
    #endif
  } 
}

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.

[K. K. (caga001)]

Im Anhang der Wireshark-Mitschnitt

[K. K. (caga001)]

@MW En

In der debug.h ist es definiert

#ifdef LWIP_DEBUG
/** print debug message only if debug message type is enabled...
 *  AND is of correct type AND is at least LWIP_DBG_LEVEL
 */
#define LWIP_PLATFORM_DIAG printf
#define LWIP_DEBUGF(debug, message) do { \
                               if ( \
                                   ((debug) & LWIP_DBG_ON) && \
                                   ((debug) & LWIP_DBG_TYPES_ON) && \
                                   ((s16_t)((debug) & LWIP_DBG_MASK_LEVEL) >= LWIP_DBG_MIN_LEVEL)) { \
                                 LWIP_PLATFORM_DIAG message; \
                                 if ((debug) & LWIP_DBG_HALT) { \
                                   while(1); \
                                 } \
                               } \
                             } while(0)

#else  /* LWIP_DEBUG */
#define LWIP_DEBUGF(debug, message) 
#endif /* LWIP_DEBUG */

[K. K. (caga001)]

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.

[K. K. (caga001)]

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.

   /* check if any packet received */
             if (ETH_CheckFrameReceived())
              {
                /* process received ethernet packet */
                LwIP_Pkt_Handle();
              }

Wie bekomme ich Zugriff auf die empfangenen Nutzdaten in meiner 
Applikation?