Re: OpenTCP/http_server.c

Bob Furber <[email protected]> Tue, 10 Jun 2008 12:00:36 -0700
Newsgroups gmane.comp.hardware.motorola.microcontrollers.coldfire
Organization Intec Automation Inc.
Message-ID <[email protected]>
X-SpamDetect-Info: ------------- Start ASpam results ---------------
X-SpamDetect-Info: This message may be spam. This message BODY has been altered to show you the spam information 
X-SpamDetect: *****: 5.100000 DodgySource=2.0, SPF Default Fail=2.5, X-Verify-SMTP present=0.6
X-SpamDetect-Info: ------------- End ASpam results -----------------

Hi Mark,

> I am not sure which Coldfire you are using but you can also take a look 
> at the uTasker solution for the single-chip V2 types (the list of 
> supported devices, with overview of their features is here: 
> http://www.utasker.com/forum/index.php?topic=256.0)
> We have our own support forum at http://www.uTasker.com/forum/ - 
> including TCP/IP stack, a unique real-time simulator and various other 
> peripheral too. The package is fully open-source and free for 
> non-commerical use. It includes useful web support like dynamic HTTP and 
> content generation, as well as secure firmware updates via HTTP post or 
> FTP. The file system allows simple extensions to the V2 devices by using 
> cheap SPI FLASH (ST and ATMEL drivers included), enabling large web 
> servers and complete firmware update support using even the smaller 
> memory devices.

uTasker looks pretty good ..except for the license (and steep learning 
curve). You see, we like to provide demo programs for our MCF5282 
WildFire/WildFireMod development kits ..which we sell. So we would not 
be able to comply with the "non-commercial use" restriction.

OpenTCP seemed ok until we decided to build better demo programs for it 
and marry it to a FatFS to serve web pages from an SD card. Then we ran 
into rather sluggish performance and TCP_EVENT_REGENERATE events 
...possibly triggered by delays (and not force-feeding as I has 
speculated earlier).

Thanks,

Bob

> Regards
> 
> Mark
> 
> www.uTasker.com
> 
> 
>> Hi Bob,
>>
>> OpenTCP was the path we were going down to have a nice open source 
>> Ethernet stack available for ColdFire but the OpenTCP company's 
>> resource to maintain it had left (long ago now) and they pulled the 
>> open source licensing so we/FSL turn to partnering with InterNiche to 
>> create a free ColdFire TCP/IP Lite Ethernet stack with (simple) 
>> multitasking OS.
>>
>> Take a look at its code base as it can handle upload of file.
>>
>> _http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=COLDFIRE_TCPIP_ 
>> then click the download tab.
>>
>> Regards,
>>
>> David
>>
>> David E Seymour
>>
>> Come to FTF 2008 June 16th through the 19th in Orlando
>>
>> http://www.freescale.com/ftf
>>
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]] On Behalf Of Bob Furber
>> Sent: Monday, June 09, 2008 7:10 PM
>> To: Seymour David
>> Subject: [ColdFire] OpenTCP/http_server.c
>>
>> X-SpamDetect-Info: ------------- Start ASpam results ---------------
>>
>> X-SpamDetect-Info: This message may be spam. This message BODY has 
>> been altered to show you the spam information
>>
>> X-SpamDetect: *****: 5.100000 DodgySource=2.0, SPF Default Fail=2.5, 
>> X-Verify-SMTP present=0.6
>>
>> X-SpamDetect-Info: ------------- End ASpam results -----------------
>>
>> Forgive me if this is not the appropriate list for posting an OpenTCP
>>
>> question. But I have not succeeded in finding a more appropriate list.
>>
>> I am trying to port the OpenTCP stack to the ColdFire and I am running
>>
>> into problems uploading files (target -> client) that are too large to
>>
>> fit in one frame. I get a TCP_EVENT_REGENERATE event.
>>
>> My understanding is that a TCP_EVENT_REGENERATE event is very rare. So,
>>
>> in digging through the code, I notice something that does not seem quite
>>
>> right: So long as there is unacknowledged data (i.e., file) remaining to
>>
>> be sent, https_run() in the main loop loads the TCP Tx buffer with data.
>>
>> It does NOT CHECK if the previous frame has been acknowledged. By doing
>>
>> this, is there not a risk that https_run() could overfeed the client.
>>
>> Can anyone shed some light on this?
>>
>> Thanks,
>>
>> Bob Furber
>>
> 
> [email protected] Send a post to the list. 
> [email protected] Join the list. [email protected] 
> Join the list in digest mode. [email protected] Leave the list.

---
[email protected]              Send a post to the list.
[email protected]        Join the list.
[email protected]    Join the list in digest mode.
[email protected]     Leave the list.