Daisy Chaining app notes??

woodrowg

Is it feasible to daisy chain Propeller chips, presumably in a master/slave architecture? I have yet to get my development system up and running due to lack of functional Win XP environment, but in reading the P8x32A prelim. data sheet, one doesn't find single instructions to put address/data words on the I/O bus.

IF there is something already published on this topic, can you point me to it?
If not, what limitations or restrictions might one anticipate? Any

Are SPIN instructions expanding or are they fixed at present set?

I verbally asked Tech Support if you would publish a version of the manual with bookmarks for major topics. It is a rather lengthy document to have to search manually each time you would like to get back to a certain topic or paragraph. If this was approved, any estimate of time frame?
thanks

Fred Hawkins

I use prespin.exe to index the manual. It works both in conjunction with the Propeller tool and by itself.
http://forums.parallax.com/showthread.php?p=655470

A bit more info on the index file is here: http://forums.parallax.com/showthread.php?p=659059

Mike Green

There have been a number of projects described using a master/slave architecture for multiple Propeller chips. The most recent and most impressive is one by BTX (search for his thread).

There are no single instructions to put address/data words on the I/O bus since the Propeller doesn't distinguish the two and there's no external memory bus in the architecture. The I/O pins and associated registers are general purpose. What do you have in mind? A number of people have interfaced different kinds of memory to the Propeller. The main constraint is I/O pins since there are only 32 currently of which 4 are partially constrained in their use.

The Spin interpretive code is fixed since the interpreter is in masked ROM on the Propeller chip.

woodrowg

To Mike G,
Thanks for the reply.
I suppose multiple propellers could communicate serially thru a COG application or with parallel transfers thru the I/O registers, but after a initial reading of the data sheets and some sample objects, it seems a larger shared memory space (both for program and data) would be desirable or necessary for a number of interesting applications.

Since I have not reached first base working with the instruction set, I can't really formulate a need list at this time. When I reach a brick wall at my first attempt, I can articulate the problem in greater detail.

Just looking for ideas at this point and hoping not to re-invent rectangular, worse yet, triangular wheels (blunders).

woodrowg

To Mike G.
I realize Parallax describes the interpreter as Masked ROM, but how do you know? The part doesn't run so fast as to preclude a flashed microcode scheme. Or to put it another way, why not imbed a Stratix or Spartan FPGA core inside this instruction hungry beast as a unique COG? Then some elements of the instruction set could be extended or customized. Feed me more options! I realize this could easily get out of hand, but if Parallax keeps it under strict control, then the sky looks deep blue.

I like the idea of a part with 64 bit I/O path. Then the sorts of things I'm envisioning, could probably work quite smoothly.

rjo_

woodrowg,

Bingo... you just picked number 1 from my wish-list. Why don't you do it and count me as your first customer?
You wouldn't even have to kludge the hardware together... just put them in the same room with a small piece of wire connecting them and provide some sample apps.

You could charge minimum wage for support... and double bill the Smile out of it.

Rich

rjo_

The only caution I would add... the Propeller is so much more capable than it first appears that you run the risk of duplicating a functionality that already exists[noparse]:)[/noparse] [noparse]:)[/noparse] [noparse]:)[/noparse]

deSilva

@woodrowg: It it quite obvious you are new to the Prop Imagine, many persons during the last year have fought against the limitations of the Prop's hardware, and have formed similar ideas as you. Yes, there COULD be a "Super-Prop"

On the other hand, the existing Prop has lots of interesting features to explore and to find out how to utilize: Very few - at least from what is discussed in this forum are in need of it's real speed, except for funny hires VGA experiments, the limits of which are obvious from the beginning, and the propeller was NOT built for hires graphics in the first place...

Indexing: You have to know the manual mainly by heart of course! So there is no need for an indexing except during the first two days...

SPIN interpreter: It does not run from the ROM, it is just any program and you easily substitute it by your own interpreter (just 2 K code - nothing to mention!)

Multi-Props-Architectures: There are many ideas... However, the Prop does not support this better than the next best microcontroller.

RinksCustoms

wood, I think you'll find the prop most usefull in your experimenting. When compared to others like Mike Green, i'm a green horn, but i find it easy to make programs with the prop. Yes, it does have limitations, but it is still alot more powerfull than alot of the typical micros out there. You could easily impliment your own Parallel driver with your own protocalls in one object using an 8 bit bus + a line or two for handshaking. There are a few video's on youtube
that demonstrate what the prop can do without realy breaking a sweat. I wish BTX's video curtain was still on there, that thing was frigin cool!

There have been multiple threads conversing on features of a Gen II propeller, perhaps your idea of a cusomizable instruction set would be·a welcome one in those threads..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E³ = Thought

http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.

Post Edited (RinksCustoms) : 8/7/2007 5:26:35 PM GMT