Hi all

Does any of you succeeded in porting lwip/freertos together with luminury micro e.g. LM3S6965.

It would be a great help if any of you would to share this.

-peter

The source code examples in Luminary Micro's StellarisWare include a port of FreeRTOS with uip. Not exactly what you're looking for, but it should still be helpful.

Go to http://www.luminarymicro.com/products/lm3s6965_ethernet_evaluation_kit.html and pick your tools choice(presumably CodeSourcery at http://www.luminarymicro.com/products/ekc-lm3s6965_ethernet_evaluation_kit.html or Code Red Technologies at http://www.luminarymicro.com/products/ekt-lm3s6965.html, since both are GNU/Eclipse-based). Then scroll down to the "Software Tools" table and download the FreeRTOS demo.

If you do modify to provide FreeRTOS+lwip, please feel free to share it back up to Luminary Micro's Sharing Forum.

--jean anne

Hi jane

I am using the (Luminary Micro) LM3S8965 eval board from you company.
Regarding uip - i have tested uip it can't do my job fast enough.
uip - is very slow when it actively has to send tcp/ip data. To my understanding is data only transmitted when uip stack makes a poll to user app. This poll is done every 1 sec. - i.e. the worst case response time is 1 sec. + routing delay on lan + ethernet.
I should not be possible to speed up the periodic poll because other function depends on the timing.

So lwip is very much needed. Or we have spend a lot of money on a commercial stack.

Do Luminary Micro has any plans on porting the lwip - if so it could be a great help.

best regards
-peter

> I am using the (Luminary Micro) LM3S8965 eval board from you company.
> Regarding uip - i have tested uip it can't do my job fast enough.
> uip - is very slow when it actively has to send tcp/ip data.

Standard uIP in its default guise is slow because it only allows one packet to be outstanding on the network at any one time which means you fall foul of the delayed ack protocol. You can get around this in a number of ways, one of which is to use the uip-split.c method for transmitting. Another method is to simply send each packet twice, which has an overhead on the network, but surprising little on the processor if you are DMA'ing, or simply setting a bit to get the hardware to send a buffer.

I also have a trick that speeds it up significantly. This is checked into SVN under the Demo\Common\Ethernet\FreeRTOS-uIP directory but unfortunately it is not in a fit state to be documented yet. I found I could get a 100K file transfer down from 13seconds using unmodified uIP code to less than a few hundred milliseconds (from memory? Maybe it was faster, maybe slower) using this version.


> To my understanding is data only transmitted when uip stack
> makes a poll to user app. This poll is done every 1 sec.


Sound like you have something wrong in the implementation. The poll only comes into effect as a periodic trigger when nothing else is happening. You should have interaction with the uIP stack the instance anything arrives at the MAC, and only use the poll if nothing has arrived in ages.

Regards.

I have been using FreeRTOS on a variety of Luminary processors; the standard Cortex port works great with my GCC setup. A few weeks ago, I brought up LWIP on the Luminary Ethernet/OLED module (I think it uses an LM3S67xx processor?) It wasn't very hard, and seemed to work OK, but I didn't do much testing beyond "can I load a web page? OK!"

The Luminary web site forums are another good source of information about these processors and various Open Source packages that people run on them.

Hi Richard


Thanks for you answer.

I know about the pacth for delayed ack - but this only gives me upto approx. 200msec.
The system is like this:

The UIP Client makes a connection with a server - and stays connected forever.
The UIP Client will actively transmit an alive telegram every 30. sec. (not very critical timing.)

But my problem is:When a button is pushed on the UIP client an event telegram will be actively transmitted to the server - which imidiately responds with e.g. a text telegram with display data for the uip client.

All this should be done very fast so the user not notice the delay when he is using the UI.

Total routing delays both ways on my LAN has been messured to typ. 30msec.
And i would like a total resonse time to be approx. 200msec.

I.e. to my understanding the way my system is implemented i would in worst case situation be deling with the periodic poll - i.e. 1sec. or am i wrong???


Maybe the SVN checkin would be a better choise for me???

-peter