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.