Shop OBEX P1 Docs P2 Docs Learn Events
TCP/IP for Prop2 — Parallax Forums

TCP/IP for Prop2

pedwardpedward Posts: 1,642
edited 2013-04-22 15:44 in Propeller 2
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.

Comments

  • Heater.Heater. Posts: 21,230
    edited 2013-04-20 13:10
    pedward,

    Have you see the IwIP stack: http://savannah.nongnu.org/projects/lwip/
    also the uIP stack: https://code.google.com/p/avr-uip/
  • pedwardpedward Posts: 1,642
    edited 2013-04-20 13:36
    Yup, both of those.

    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.
  • Heater.Heater. Posts: 21,230
    edited 2013-04-20 13:43
    pedward,
    The uIP architecture is not optimal for the Prop chip because it relies on callbacks, not a client server approach.
    I have not really looked into these things, could you elaborate on that a bit for us. What is the issue?

    What about running the Spin IP stack through spin2cpp ?
  • jazzedjazzed Posts: 11,803
    edited 2013-04-20 14:53
    Why does 40KB of code cause a need for XMM on P2?
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-04-20 16:03
    You could run Harrison's stack through Eric's Spin2cpp (like Heater said as I just saw) for a first pass, or hand translate it.

    There are a ton of free stacks, NetBSD among them. PropGCC's CMM mode should cut them down to about 20K
    pedward wrote: »
    Yup, both of those.

    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.
  • Heater.Heater. Posts: 21,230
    edited 2013-04-20 16:20
    I would imagine that in many cases we don't even need TCP. If I could just get UDP from a Prop to my PC via regular CAT5 I'd be happy.

    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.
  • pedwardpedward Posts: 1,642
    edited 2013-04-20 18:54
    Heater. wrote: »
    pedward,

    I have not really looked into these things, could you elaborate on that a bit for us. What is the issue?

    What about running the Spin IP stack through spin2cpp ?

    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!
  • pedwardpedward Posts: 1,642
    edited 2013-04-20 18:56
    jazzed wrote: »
    Why does 40KB of code cause a need for XMM on P2?

    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.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-04-20 19:03
    pedward wrote: »
    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.
    I'm afraid that no XMM solutions currently exist for P2 although they are planned for both flash and SDRAM. When you say 40K bytes are you talking about compiling in LMM or CMM mode? If it's 40K in LMM it will probably be less than half that in CMM.
  • jazzedjazzed Posts: 11,803
    edited 2013-04-20 20:20
    pedward wrote: »
    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.
  • pedwardpedward Posts: 1,642
    edited 2013-04-20 20:35
    jazzed wrote: »
    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.
  • pedwardpedward Posts: 1,642
    edited 2013-04-20 20:35
    David Betz wrote: »
    I'm afraid that no XMM solutions currently exist for P2 although they are planned for both flash and SDRAM. When you say 40K bytes are you talking about compiling in LMM or CMM mode? If it's 40K in LMM it will probably be less than half that in CMM.

    David, can you describe more about the CMM and other supported memory models? How does CMM work and what are the caveats?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-04-21 04:05
    pedward wrote: »
    David, can you describe more about the CMM and other supported memory models? How does CMM work and what are the caveats?
    Eric can give you a better description but CMM stands for Compressed Memory Model. It is a mode in which Propeller instructions are basically encoded as bytecodes and assembled at execution time. I believe it gives about a 2x increase in the amount of code that will fit in hub memory and executes significantly faster than Spin at least on the P1. There is no Spin for the P2 to compare with.
  • tonyp12tonyp12 Posts: 1,950
    edited 2013-04-21 12:48
    >If I could just get UDP from a Prop to my PC via regular CAT5 I'd be happy.
    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.
  • Heater.Heater. Posts: 21,230
    edited 2013-04-21 13:34
    tonyp12,

    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.
  • jazzedjazzed Posts: 11,803
    edited 2013-04-21 14:36
    I created a UDP protocol about 12 years ago for doing register read/write from a PC to an embedded system. The protocol was designed to ensure that all transactions happened as expected without requiring TCP. It was at least 10 times faster than TCP and just as robust within a sub-net. TCP is more general, but is resource hungry. I mentioned this achievement in an interview once and got a one of those blank looks ....

    @peward, Eric has pushed code that will allow CMM to access all of P2's memory space.
  • localrogerlocalroger Posts: 3,451
    edited 2013-04-22 10:03
    Heater. wrote: »
    I would imagine that in many cases we don't even need TCP. If I could just get UDP from a Prop to my PC via regular CAT5 I'd be happy.

    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.
  • Heater.Heater. Posts: 21,230
    edited 2013-04-22 10:21
    It's the routing between networks that can cause the grief though. If you have multiple routes it can cause packet duplication which brings you back to TCP to fix it. Things get worse if you are trying to transfer something bigger than a packet, like files say.

    But for simple status queries or command response operations UDP can be fine. It's used in SNMP for example.
  • localrogerlocalroger Posts: 3,451
    edited 2013-04-22 15:44
    Heater. wrote: »
    It's the routing between networks that can cause the grief though.

    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.
Sign In or Register to comment.