TCP/IP for Prop2
pedward
Posts: 1,642
I'm looking at what I can leverage to make TCP/IP available for the Prop2.
It so happens that a fine Prop developer wrote a TCP/IP stack in SPIN and made it available.
This, of course, doesn't help the C initiative or making a C stack available, but it's an interesting solution and lineage.
I'm looking for an MIT licensed stack, but more important, to use a C based stack will require around 40Kbytes of memory for code. This means XMM for efficiency.
What XMM solutions exist, and what limitations are present?
Even better, what memory models are now supported, because things have changed much in the last year.
It so happens that a fine Prop developer wrote a TCP/IP stack in SPIN and made it available.
This, of course, doesn't help the C initiative or making a C stack available, but it's an interesting solution and lineage.
I'm looking for an MIT licensed stack, but more important, to use a C based stack will require around 40Kbytes of memory for code. This means XMM for efficiency.
What XMM solutions exist, and what limitations are present?
Even better, what memory models are now supported, because things have changed much in the last year.
Comments
Have you see the IwIP stack: http://savannah.nongnu.org/projects/lwip/
also the uIP stack: https://code.google.com/p/avr-uip/
They take 40K of "ROM" and little RAM. The uIP architecture is not optimal for the Prop chip because it relies on callbacks, not a client server approach.
Ironically, Harrison Pham's PropTCP is the most compact TCP implementation that I've seen, after all it fits in the Prop 1 HUB memory.
What about running the Spin IP stack through spin2cpp ?
There are a ton of free stacks, NetBSD among them. PropGCC's CMM mode should cut them down to about 20K
Having to worry about dropped/corrupted packets is about the same problem as when using a fast long serial connection.
Packet ordering is not an issue as I would have a direct connection to the PC or just a switch. There are no multiple routes to jumble packets.
Taking this stuff over the internet is not on anyway unless you want to squeeze TLS in there as well, which seems unlikely.
If I want to put my Props on the internet it will be via an intermediary processes on my PC anyway.
uIP does callbacks to reassemble packets for retransmit, for one. Using callbacks is a problematic solution for multiprocessing. I intend to use an asynchronous approach with checkpoints, polling, and hub memory transfer.
I hadn't thought about using Spin2CPP, that's very intriguing!
I don't like the idea of wasting 40KB of RAM for code space, just for a TCP/IP stack. Think about that in context, the Prop 1 only has 32KB of RAM, the P2 just under 4x that. Using 1/4th of your system RAM for code space just seems like a big waste.
Can you describe your system a little better? Do you have some specific requirements for an example application? How will XMM be of any benefit? Can't you fit the entire application in P2 RAM? I suspect that the TCP/IP stack should run as fast as possible. Unless we can really optimize a single COG kernel with a full bus for accessing a long at a time XMM will likely be slower than any HUB program.
Steve, my end goal is to have a TCP/IP stack that represents a small resource allocation in the overall scope. I don't have any particular application in mind, but I'm doing it as a part of the "greater good".
When you have a Harvard architecture, like many of the flash micros, you can burn 40K of a 512K or 1MB flash memory and not worry too much. With the Prop2 only having 128k for program and data, it starts to looks a bit tight.
There will be applications that don't care about how much space TCP/IP takes, merely having it is important. There will be other applications where they are packing a lot into the 128K and devoting a whole 40K to that will be difficult.
I'm only feeling things out right now, I haven't begun writing the software. I've got plenty of tricks yet to try.
David, can you describe more about the CMM and other supported memory models? How does CMM work and what are the caveats?
Me to, there is nothing stopping you to implement your own little header to keep data in order and error free.
But if someone did create a micro tcp/ip stack it would be great.
Yes, once you can shift packets you can put whatever protocol on top you like. However inventing a DIY protocol that is robust is not so easy. There is some saying about "don't try to reinvent TCP".
Keeping packets in order, after they have been jumbled by taking multiple routes through a network, is troublesome because you need memory for packet buffers to do it.
Seems to me TCP is not required unless you actually have a network with multiple routes between end points. For a point to point connection from Prop to PC certainly not.
By the time you reach that issue you are pretty much going out over the internet. At that point I'd want some security as well. Say TLS/SSL. I really don't think that is going to find it's way int the Prop. (It's impossible I tell you:))
Of course in the web centic world every one wants a web server on every gadget. Makes no sense to me but I guess it has to come.
@peward, Eric has pushed code that will allow CMM to access all of P2's memory space.
Funny you should mention that:
http://forums.parallax.com/showthread.php/147167-UDP-for-ENC28J60?p=1174618#post1174618
UDP does indeed save a ton of memory and run much faster. It's especially nice that it can be routed between networks instead of being limited to local ethernet subnets.
But for simple status queries or command response operations UDP can be fine. It's used in SNMP for example.
Oh, absolutely. But for some things it's much better than TCP. For example, a stream of data from a meter or a single screen configuration interface; you can simply blast the whole state out in a packet, and repeat it if there's no response. Out of order and lost don't tend to matter, and TCP's habit of bringing everything to a screeching halt while it waits for the dropped packet to be replaced actually makes things a lot worse.