RE: OpenTCP/http_server.c

Hi Bob,
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.
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: 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.