Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorAltera TSE driver and example program for lwIP (1.3.2)
After many many requests and complaints about lack of support and/or documentation for support of lwIP for the Altera TSE, I have developed a drop-in TSE driver and example program and made this available to the NIOS II community. This was done for NIOS II 8.1 SP0.01. I don't expect difficulty with version 9.x.
This is for the latest version of lwIP (the latest is as of this post) for a minimal program and HTTP server based on the http server in the lwIP contrib folder. The lwIP TSE driver uses the altera_avalon_tse driver and SGDMA as-is. There is a complete (as in 41-step) set of instructions on creating the project and example program. More information and the link to the driver is available here: http://lwip.wikia.com/wiki/available_device_drivers#lwip_1.3.2 Please direct any questions, changes for NIOS II 9.1, or comments to this thread. 12-16-2010 update: This example works with NIOS Version 10.0 with some tweaks to the procedure to create the project. Also, a lwIP 1.4 release candidate has been out for a while and it drops into this example (in place of 1.3) without changes. Bill257 Replies
Altera_ForumPending indicates that an ARP query has been send, but no response has been received yet.
By the look of it, it's also possible to force an ARP request via 'etharp_query', however you need to make sure you call 'ethernetif_input(&alteraTseNetif)' after if you are running without OS. Since the ARP replies are only updated if you process the newly received packages after 'etharp_query' has been called. You should also take into account that there is a slight delay between the send / receive so if you place both calls without delay between them the response probably hasn't been received yet. Another thing to take in account is that you can't call 'etharp_query' directly when you are using an OS since this function uses the raw API without thread safety support. This means your ARP and PBUF table isn't protected against cross thread actions.- Altera_Forum
Oh, that was the issue - I haven't done ethernetif_input(&alteraTseNetif) call. Thanks!
- Altera_Forum
Btw, is it possible to redefine LWIP_DEBUGF() to use printf() somehow? That native debug use some interesting variables types.
- Altera_Forum
In cc.h you should
and in lwipopts.h you should scroll down (approx line: 1290) there you can find all debug defines so you can enable / disable different functionality's. This is done because if you would enable all at once it would cost quite much processor time :p# define LWIP_DEBUG # define LWIP_PLATFORM_DIAG(x) printf(x) - Altera_Forum--- Quote Start --- In cc.h you should
--- Quote End --- printf should be without parenthesis, something like# define LWIP_DEBUG# define LWIP_PLATFORM_DIAG(x) printf(x)#define LWIP_PLATFORM_DIAG(x) do { printf x; } while(0) - Altera_Forum
DipSwitch,
I think there is a problem in your (and Bill’s) driver. low_level_input() in altera_tse_ethernetif.c allocates pbufs for incoming packets with pbuf_alloc(PBUF_RAW, PBUF_POOL_BUFSIZE, PBUF_POOL). By default PBUF_POOL_BUFSIZE evaluates to 1080 and, consequently, longer packets corrupt memory. In my code I simply redefine PBUF_POOL_BUFSIZE to be 2000, but for universal driver, like yours, some more elegant way should be found. - Altera_Forum--- Quote Start --- DipSwitch, I think there is a problem in your (and Bill’s) driver. low_level_input() in altera_tse_ethernetif.c allocates pbufs for incoming packets with pbuf_alloc(PBUF_RAW, PBUF_POOL_BUFSIZE, PBUF_POOL). By default PBUF_POOL_BUFSIZE evaluates to 1080 and, consequently, longer packets corrupt memory. In my code I simply redefine PBUF_POOL_BUFSIZE to be 2000, but for universal driver, like yours, some more elegant way should be found. --- Quote End --- Hmm, lets see:
TCP_MSS = 1460 PBUF_LINK_HLEN = 14 ETH_PAD_SIZE = 2 To sum up: 1460+40+14+2 = 1516 Seems like no problems here?# ifndef PBUF_POOL_BUFSIZE# define PBUF_POOL_BUFSIZE LWIP_MEM_ALIGN_SIZE(TCP_MSS+40+PBUF_LINK_HLEN+ETH_PAD_SIZE)# endif - Altera_Forum--- Quote Start --- Hmm, lets see: TCP_MSS = 1460 PBUF_LINK_HLEN = 14 ETH_PAD_SIZE = 2 To sum up: 1460+40+14+2 = 1516 Seems like no problems here? --- Quote End --- Lets see again :) In the code DipSwitch posted on January 19th TCP_MSS is defined through the chain:
With all defaults TCP_MSS = 1024. In any case, I think you should agree, that “Ethernet frame length” is completely unrelated to “the size of the heap memory”, or “TCP Maximum segment size”, or “The size of a TCP window”. Mixing all this together misleading for user. For example, I spent last day debugging strange hangs in my code, which occurred irregularly after from 40 seconds to 1 hour of successful execution. That code doesn’t need much lwIP memory and doesn’t use TCP at all!add_sw_setting decimal_number system_h_define memory.mem_size CONF_LWIP_MEM_SIZE 32768 "Size of the memory poll"# define MEM_SIZE CONF_LWIP_MEM_SIZE# define TCP_WND (MEM_SIZE / 8)# define TCP_MSS (TCP_WND / 4) - Altera_Forum
Oh, I don't use DipSwitch example now, but using that one created by Bill.
- Altera_Forum--- Quote Start --- With all defaults TCP_MSS = 1024. In any case, I think you should agree, that “Ethernet frame length” is completely unrelated to “the size of the heap memory”, or “TCP Maximum segment size”, or “The size of a TCP window”. Mixing all this together misleading for user. For example, I spent last day debugging strange hangs in my code, which occurred irregularly after from 40 seconds to 1 hour of successful execution. That code doesn’t need much lwIP memory and doesn’t use TCP at all! --- Quote End --- Sorry about that! In our project, we use 64Kb as mem_size so it didn't occur to me. But I do agree with you that they are unrelated. Maybe it would be nice to add those variable to the TCL script and find some way to generate errors while generating the BSP. Any hints on howto are welcome. And again, sorry for your waste of time!
