Shop OBEX P1 Docs P2 Docs Learn Events
Propeller Starter Kit — Parallax Forums

Propeller Starter Kit

RsadeikaRsadeika Posts: 3,837
edited 2006-07-27 17:34 in Propeller 1
I have noticed that the starter kit is comming up for sale whithin the next few weeks. Any advance details as to what this package will look like.

Ray

Comments

  • ESPESP Posts: 25
    edited 2006-07-19 12:59
    Hi Ray,

    I would imagine it is the Demo Board + manual looking at the prices.

    Robin
  • ESPESP Posts: 25
    edited 2006-07-20 12:47
    Hi Ray,

    I have just read the Propeller marketing stuff. It mentions the Starter Kit as being the Demo Board, the Manual and the cute USB cable - but not the power supply.

    Makes a good read for the Boss [noparse]:)[/noparse]

    Robin
  • RsadeikaRsadeika Posts: 3,837
    edited 2006-07-20 13:30
    Robin,

    Thanks for the info, I just went to check on the Propeller products, and I noticed the availability date for the Starter Kit has been moved to August 15, 2006. Probably a snag with the printing of the manual, since they have made some changes.
    I was just trying to get some clarity as to what the starter kit was really going to look like. It seems that it is going in the direction of video related stuff. That is probably fine for some people, but for me I would get bored pretty darn quick.
    I am now starting to think along the lines of just simply waiting for the next version of the Propeller, the 64 pin version, or the PPDB. Yes, I know about the PropStick, a fine product, but not for me.

    Thanks
    Ray
  • Mike GreenMike Green Posts: 23,101
    edited 2006-07-20 15:33
    Why wait? What would you like to be able to do that you can't do now? I can think of specific applications that might require large (> 32) numbers of I/O pins that would be difficult to do with the current (only 32!) Propellor. Specifically, a high speed wide logic analyzer or something requiring high speed access to any large size parallel memory. Anything a bit slower can be done with external I/O extenders, external serial memory, etc. If you want something like the current demo board or upcoming hydra where 3/4 of the pins are already spoken for, but you need more than 8 or so uncommitted pins directly accessible, by all means plan to wait.

    One of the problems with the current Propellor that a future one will only partially solve is that resources tend to get assigned to debugging or other "supervisory" functions. Once you connect up a keyboard, mouse, and VGA display, you've already accounted for 12 I/O pins and 4 cogs. If you add a serial port, that's another 2 to 4 I/O pins and a cog. Floating point takes another 2 cogs. I don't think the PPDB will solve that and, although the "next generation Propellor" will likely add the second bank of I/O pins and a multiply instruction (and a couple of others), there won't be any more cogs nor will there be more directly addressable memory on-chip.
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-07-20 16:27
    Ummm, Mike... to quote Chip, "...the next one will have more of everything..."

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

    Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd

    ·
  • Mike GreenMike Green Posts: 23,101
    edited 2006-07-20 17:19
    Well, the instruction set can accomodate a larger hub memory since all hub addressing is register based.

    The COGINIT instruction is currently hard limited to 8 cogs although, with a little careful planning now,
    there could be room for 15 cogs total with the 16th value reserved for letting the HUB assign a cog #.
    Currently bit 3 == 1 implies "allocate a new cog". If all code now (and the documentation) required that
    a value of %1111 meant "allocate a new cog" and values from %0000 to %0111 were valid on the
    current Propellor while values from %0000 to %1110 were allowed on the "next generation", we'd be
    ready for code compatibility with a 15 cog Propellor. We could actually have a 16 or more cog Propellor
    if the only way to start a cog over #15 was to use the "allocate a new cog" value.

    COG memory would be a problem though. The instruction set is pretty hard coded for a 512 long memory.
    There are very few uses for a COG though that would really need more than that for instructions. Most
    applications complex enough (like floating point) can be split across several COGs if needed. Chip has talked
    about speeding up the HUB by requiring fewer clocks per COG. By doubling the number of COGs, we'd lose
    the speed advantage although I think more COGs would be better. If the 2nd I/O port were included
    on chip even in a 40 pin package, the extra port could be used for inter-cog communication for applications
    that couldn't afford the time to go through HUB memory.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2006-07-20 17:38
    Mike Green said...
    If the 2nd I/O port were included on chip even in a 40 pin package, the extra port could be used for inter-cog communication for applications that couldn't afford the time to go through HUB memory.
    For ultimate flexibility, it would be nice to see sixteen additional registers mapped into each cog's address space. Each cog would "own" one of them and, for that cog, it would be read/write. The other fifteen would be read-only. That way cogs could communicate without hub delays and without having to share a common I/O resource. (I'd hate to be the one having to route that feature onto the chip, though. That's 512 signal lines that have to reach each cog.)

    -Phil
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-07-20 18:01
    Ya know something, I just spent over 45 mins trying to describe my idea, and how it could work, and everything else... then....
    I re-read Phil's post .... it was almost exactly the samething! Only I was suggesting something like banked shadowed ram.·· The read instruction would specify the bank and register in one operation. It would take 16 reads to get it, but not accessing the hub. Very simular to Phil's idea, but somewhat different in how to lay it out, if it could be done.

    FYI:· If I recall correctly, no metion of cog ram was made, but ram in general was.



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

    Propeller + Hardware - extra bits for the bit bucket =· 1 Coffeeless KaosKidd

    ·
  • Ym2413aYm2413a Posts: 630
    edited 2006-07-27 17:34
    The 512 words of cog rams (2k) seems to be enough for most functions.
    I feel just having 64k of HUB ram would make a big improvement.
    That and maybe a common register to transfer data from one COG to another.

    Other then that. I love this chip!
    Also how many other microcontrollers do you know that have 32k embedded ram and eight 32bit processors in one package and for only 25$ per order of one? *smiles*

    Another nice thing about the chip is the fact that the EEPROM isn't embedded into the chip like some other controllers. Which allows for easy reprogramming and updating after installation. (Just swap a small EEPROM ic from a socket and your done)
Sign In or Register to comment.