I've finally got the uip tcp/ip stack working on the web platform. What a learning curve!
This (attached) is based on the code in the uIP_Pic33_port_k project in the google code svn. There's lots of commented out blocks, code comments that are not longer correct, debug code and it's a bit all over the place, but at least demonstrates the code works.
The project attached here will setup the IP address of the web platform as 10.0.0.251 and listen on port 23 (telnet ) for a max of 10 simultaneous connections.
You should be able to ping it, and telnet to it. It will echo back messages sent to it.
You should also know that it will output a lot of debugging stuff on the usb serial port ( at 115200 ). The code always enables the UART, so the usual warnings about backpowering the usb chip apply (ie, make sure you have the usb cable connected )
I'm getting ping times of around 0.680 mS. The SPI bus is operating at SPRE 1:1 and PPRE 4:1, which seems to be as fast as the datasheet suggests is possible @ 40MHz Fcy (so that's 10MHz SPI, although the ENC28J60 says it will work up to 20MHz. I haven't tried that... seem to recall some other thread having problems going that high? )
Next steps I'd like to try are to replace the polling loop with an interrupt from the ENC28J60 when packets arrive, and to try using DMA to get the packets into and out of the ENC28J60.
Cool stuff. I can't wait to try it. Would you like SVN access to keep updates of your work online?
The SPI bus is operating at SPRE 1:1 and PPRE 4:1, which seems to be as fast as the datasheet suggests is possible @ 40MHz Fcy (so that's 10MHz SPI, although the ENC28J60 says it will work up to 20MHz. I haven't tried that... seem to recall some other thread having problems going that high? )
Yes, the dsPIC33 data sheet  has this information in Table 30-29, Note 3: "The minimum clock period for SCKx is 100 ns. The clock generated in Master mode must not violate this specification."
So 10 MHz seems to be the limit.
 http://ww1.microchip.com/downloads/en/D ... 70292D.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/70292D.pdf)
Thanks Ian and Markus.
I now have it working using the packet ready interrupt from the enc28j60 to replace the polling, and using DMA to transfer the data buffers for send and receive.
There are certainly some pitfalls to be aware of when using the SPI with DMA ! For example, the documentation doesn't say so directly, but you cannot do TX only mode on the SPI - because if *something* doesn't read SPIxBUF before the next byte is clocked in, the Rx overflow bit is set,and the whole SPI interface stops; so you need to assign a second DMA channel to the SPI to repeatedly read SPIxBUF to a dummy one word variable. I'll write up some more details when I get some time to do so.
Also, the enc28j60 interrupt is connected to one of the few non-remappable dsPIC pins - so I couldn't map it to an external interrupt peripheral. It is on a Change Notification (CN) pin though, so I used the CN interrupt. The only downside there is that you get two interrupts - one for each interrupt pin transition. Not a big deal, though.
Performance wise - no real difference I can see from the ping times; theoretically, the biggest improvement will be in "responsiveness" of other tasks on the dsPIC, especially when sending or recieving larger packets. Each SPI transfer is 8 bits; one bit is 4 Tcy's; 32 Tcy per byte; for a 1000 byte packet = 32000 Tcy that the dsPIC doesn't have to stall polling the SPI status bits. 1000 byte packets are conceivable, as the allocated packet buffer is 1500.
I need to do some direct comparisons I guess - after I work out how to measure that!
Next, I'd like to be able to IDLE the enc28j60 and dsPIC, let the interrupts take care of the wake up, and see how that affects current consumption. If only there were more hours in a day!
Ian - I will take up that offer of SVN access, if you're still extending it?
Hi Tony - I added your registered email address to the Dangerous Prototypes SVN at Google Code:
http://code.google.com/p/dangerous-prot ... -hardware/ (http://code.google.com/p/dangerous-prototypes-open-hardware/)
you can get your GC password here:
The uIP port is currently in a folder off /trunk/, but it would probably be better to move it to the webplatform/firmware/ folder. Where ever you want to keep your work, it's not a problem.
I've committed it to trunk/web-platform/firmware/uIPStack