Shop OBEX P1 Docs P2 Docs Learn Events
Looking to put a development Team Together — Parallax Forums

Looking to put a development Team Together

Brian CarpenterBrian Carpenter Posts: 728
edited 2009-10-27 03:41 in Propeller 1
I am looking for one (or a few) individuals from the forum to join me in a development project for a client of mine. The project will use the Propeller as the primary processor. It will also use the ENC28j60. it will connect to the network. I am looking for someone familiar with this chip and doing DHCP and STATIC IP's. It will be connecting to a webserver passing data back and forth. Programming can take place in SPIN or ASM but will need to eventually be recreated into C for the client. IF you are interested in this project, please PM me or email me with your skills and qualifications.


brian (at) altitudeap.com

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


It's Only A Stupid Question If You Have Not Googled It First!!

Comments

  • Brian CarpenterBrian Carpenter Posts: 728
    edited 2009-10-26 13:42
    Wow. lots of lookers. but no takers. This is a paying job. Did i fail to mention that?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    It's Only A Stupid Question If You Have Not Googled It First!!
  • localrogerlocalroger Posts: 3,452
    edited 2009-10-26 14:44
    Brian, it would help to know a bit more about what you're trying to do. I've just wrapped up a project using a lot of the techniques you are probably looking for.

    As far as I know Harrison Pham's TCP stack (from PropTCP and PropIRC, and IIRC the YBOX2) is the only free spin/pasm stack out there. Beware, the one in the OBEX isn't the most recent, and even the most recent has a couple of bugs that cause it to lock up after a lot of use. It also does not respond to Pings or handle DHCP. With the timeouts fixed it does work very well as both a server and a client for short repetitive traffic. Harrison's stack also isn't MIT licensed, it's GPL'ed, so you must be willing to release your own source code if you use it.

    If you can use Harrison's TCP stack then your project will probably be fairly simple and within the capabilities of a lot of us. If not, it will involve a lot of wheel reinvention and require a fair amount of time and skill to get rolling.
  • JackBakJackBak Posts: 45
    edited 2009-10-26 14:57
    [noparse][[/noparse]gadfly_mode]
    Does the sentence "Programming can take place in SPIN or ASM but will need to eventually be recreated into C for the client." strike anyone else as a tad disingenuous when it comes to "The project will use the Propeller as the primary processor." That tells me the client really wants an ARM or xxx processor and is requiring C "eventually" because of a fear of spinning propellers.
    [noparse][[/noparse]/gadfly_mode]
  • LeonLeon Posts: 7,620
    edited 2009-10-26 16:06
    Microchip provides free TCP/IP stacks for many of their chips, some of which include Ethernet hardware. It would probably make more sense to use one of those, unless the special features of the Propeller are required.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
  • jazzedjazzed Posts: 11,803
    edited 2009-10-26 16:24
    I've also witnessed the lock-up challenges localroger mentions with the Propeller TCP/IP code running as a "server" ... the only time I saw the lock-ups was when multiple clients were hitting the server simultaneously resulting in something like "denial of service" failure. The "client" side of the connection "should not" be so bad since the client initiates and expects the resulting data transfers.

    It is not unreasonable to want a variation of the "client" side solution in C for use with other processors. It "may" be difficult to squeeze the customer application and the TCP/IP code into the Propeller though without some creative solutions. That depends mostly on the customer application requirements.
  • localrogerlocalroger Posts: 3,452
    edited 2009-10-26 16:37
    jazzed -- I was able to fix the lockup problem; it occurs because certain socket states don't time out. I posted a fix awhile back but couldn't put it in the obex because of the license. http://forums.parallax.com/forums/default.aspx?f=25&m=385830
  • veateiveatei Posts: 3
    edited 2009-10-27 00:58
    Definitely an interesting project. I know that Harrison's interface with the ENC works. It's possible that the client may want to use something like a Freescale processor or netburner or something simliar to that. It's definitely something to check out. devil.gif
  • Brian CarpenterBrian Carpenter Posts: 728
    edited 2009-10-27 03:31
    the client is currently using the netburner, It is not the right solution as the netburner they are using is the PINK and then they have another processor that attaches to it to do the other processing. It was my idea to combine all functions of the end product into the Propeller using the ENC chip and eliminating the $100.00 board. Their current solution is a PIC programmed in basic. The reason that i stated that the customer would like the project in C eventually is due to the fact that all off the programmers that support the hardware program in C. This is also part of my EVIL plan to get the Propeller in as the "processor of choice" with this client. The project is fairly basic for me except for the TCP stack portion. This is truly what i am looking for a team for.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    It's Only A Stupid Question If You Have Not Googled It First!!
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2009-10-27 03:41
    Brian,

    Now that a few have made some comments I just want to ask, why are these chips being specified, shouldn't the hardware be selected depending upon the hardware and software requirements? It seems you are compromising the design from the start by specifying this chip combination plus there is the odd requirement of developing in Spin and yet recreating later in C.

    For what's it's worth I would just use and ARM CPU (with an external PHY) and draw on the vast C libraries available for this architecture which is also more suitable for ethernet than the Prop. Conversely I have a design that uses a cheap LPC2148 ARM7 coupled to the ENC28J60 plus a Propeller chip with shared I/O. This allows "testing" with the Propeller if desired or else the ARM chip can be programmed to handle the ethernet etc. In this configuration either processor could be the application CPU with the other as a slave device or whatever. Yes, I love the Prop but it can't do everything (yet).

    Knowing what the "black box" WILL need to do is more important at the moment than trying to specify how it will done or implemented.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
Sign In or Register to comment.