Re: OpenTCP/http_server.c

Seymour David wrote:

> FSL had freely licensed the OpenTCP for NE64 and MCF5282 but as I
> mentioned before the resource at Viola left and the company decided to
> pull it.  So FSL wanted an open source approach.  The ColdFire TCP/IP is
> freely license for use with FSL processors.  It provides a nice step to
> fully supported stack/OS from InterNiche should customers choose that
> route.
> Yes, it is being actively used by many and will continue to be.
> I think it is the up-sell area that FSL cannot generate code and post
> but customer can add whatever they want for their own use.  I'll triple
> check that answer and reply if I'm wrong.

It appears there was a flurry of activity on porting lwIP to the NE64 
and the Coldfire5282, about 3 years ago. Would you have any recollection 
of this? Would you know why Freescale chose the InterNiche stack over 
the more widely supported lwIP?

Thanks,

Bob Furber

> 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: Tuesday, June 10, 2008 1:39 PM
> To: Seymour David
> Subject: Re: [ColdFire] OpenTCP/http_server.c
> 
> Thanks David,
> 
>> 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
> 
> Yikes! For some reason I had assumed it was GPL. And, up until getting a
> 
> TCP_EVENT_REGENERATE event, I was quite happy with OpenTCP.
> 
> In any event, can Viola Systems Ltd. "pull the open source licensing" 
> one handed over in the license on every source page?
> 	:
>   *Redistribution and use in source and binary forms, with or without
>   *modification, are permitted provided that the following conditions
>   *are met:
> 	:
>> so we/FSL turn to partnering with InterNiche to create a free 
>> ColdFire TCP/IP Lite Ethernet stack with (simple) multitasking OS.
> 
> Judging by traffic on the Freescale forum, it appears that there are 
> licensing issues with TCP/IP Lite too. I also get the sense from the 
> forum that there were efforts to replace its multitasking OS by a 
> "superloop", which presumably means polling. This is not unreasonable 
> because an Ethernet chip or module typically has fairly large buffers. 
> It appears these efforts were ended because of licensing issues.
> 
> Interestingly, Freescale has contributed the HTTP support files, with no
> 
> restrictions other than "For use on Freescale products only". Is this 
> correct?
> 
>> 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.
> 
> Thanks.
> 
> Would you know if TCP/IP Lite has a fairly large and active
> constituency?
> 
> Thanks,
> 
> Bob Furber
> 
>> 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.
> 
> ---
> [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.
> 
> 
> 

---
[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.