Philip Pemberton wrote: > That and based on my > experiences with the MCHP USB stack, I'd sooner juggle flaming > torches in the middle of the Buncefield Oil Refinery than use their > code. I know what you mean. I had a bad experience with the Microchip network stack. I took a snapshot of their code, which was AN833 if I remember right, some years ago. That was the latest at the time. At first things worked fine. I got PING reply up and running quickly, and a basic TCP test also seemed to work. Then I implemented my application for real and lots of little issues with their stack started cropping up. Eventually I ended up going over just about every line of code from the TCP module on down to the ENC28J60 driver. What a pile of crap! It was very poorly written, and poorly documented. I think I found and fixed half a dozen bugs myself, and the product sortof worked well enough for the purpose. I think there were two basic problems with that network stack. First, although it claimed to be designed for multiple TCP connections, proper concurrency wasn't designed all the way thru. There were very onerous restrictions placed on the application as a result. Second, they were reluctant to require or specify a multi-tasking system, so the stack really didn't fit well with a application layer that did. I think it would have worked OK if the app was a single web server, but my app included a web server and a additional TCP server and client. It just couldn't handle 3 TCP streams. I'll spare you some stuff in the middle, but last summer I got to where I just couldn't fix this mess anymore and bumped up against hard architectural limits that pretty much guaranteed lockup on certain events outside the control of this embedded system. So I wrote my own network stack for a PIC 18 driving a ENC28J60 external MAC/PHY. We ran this thru all kinds of turture tests and it just kept ticking. This meant having both the TCP server and client regularly tranferring data, while hitting the web page, while hitting it with a PING flood. The PING flood definitely increased response time, but it didn't go down, and the response recovered when the PING flood stopped. These toruture tests were run for days at a time on multiple units without a single one wedging, rebooting, or anything else that could be considered a failure. Just for comparison, we ran the same test on the previous firmware that was based on the Microchip stack. The average up time was 350mS. Yes, about one third of a second. Recently I made up a networking testbed board that has a 18F67J60 (this PIC contains a 10Mbit/sec ethernet MAC/PHY) on it with a hardwired ethernet connection, and also a ZeroG module. I'm adding the packet layer to drive the internal ethernet module now, and then it's on to the ZeroG module after that. I'm not sure how exactly the code will be released and who will maintain responsibility for it. Let me get it written first. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist