Multi-Propeller System Project
HalcyonDaze
Posts: 17
I have a project idea that I want to put together, mostly to operate as a tinkering platform for later nonsense. In the interest of not reinventing the wheel, can you point me to any efforts to do the same, in part or in whole, that I might take advantage of?
The Idea is simply to create an array of propeller chips arranged with some degree of repeating-unit scalability, that can function cooperatively as a single unit, with adaptable parallel I/O being the primary goal. Ive done some looking and seen that this has been done before at one level or another (from simple 2-chip systems on up to The Big Brain supercomputer) so I know it's possible.
Applications would be largely be in robotic control, sensor interfaces, etc, but ideally it could operate at a level of sophistication that it could use complex devices like a Kinect, or otherwise tackle more process and/or memory intensive tasks. There's been rumor of Linux ports that I was hoping to take advantage of for that.
Standardized cell board layout - Preferably this would require a single basic board layout that repeats and interconnects, with no hardware priority given to any single chip. This would allow failure programming to shift control from one chip to another dynamically, eventually.
Communication - If I have to I can probably be satisfied with devoting one cog to communicating and maintaining a simple shared registry, at first. But Id prefer memory management that can treat the entire system's memory as a common resource, though priority can always be given to local operations over global ones, I suppose. The same would be nice in terms of Processing power, but Im not familiar enough with multi-core programming to know how feasible it is to devote multiple cogs to one task. Ideally the individual chips would have some cogs dedicated to local tasks (typically external things related to hardwired resources like sensors or motor control) while the "spare" cogs are treated as a floating resource to be allocated to more internal processing tasks (analysis, voice recognition, multimedia output). While I intend for it to be hardwired at this point, it would be nice if the communication scheme allows for wireless communication bridges to be used with some chips.
Attempting to break the project down into discrete goals, I see:
-A Board Layout with compatible communication scheme.
-Memory Management (including global Memory addressing), scalable
-Process Load Management, scalable
-Multi-Chip Boot Loader
-?
So what do you, the guru's think? Can you point me to any similar projects? Do you have any advice or concerns with the plan? Anything that's impossible or anything that is already done I can use?
The Idea is simply to create an array of propeller chips arranged with some degree of repeating-unit scalability, that can function cooperatively as a single unit, with adaptable parallel I/O being the primary goal. Ive done some looking and seen that this has been done before at one level or another (from simple 2-chip systems on up to The Big Brain supercomputer) so I know it's possible.
Applications would be largely be in robotic control, sensor interfaces, etc, but ideally it could operate at a level of sophistication that it could use complex devices like a Kinect, or otherwise tackle more process and/or memory intensive tasks. There's been rumor of Linux ports that I was hoping to take advantage of for that.
Standardized cell board layout - Preferably this would require a single basic board layout that repeats and interconnects, with no hardware priority given to any single chip. This would allow failure programming to shift control from one chip to another dynamically, eventually.
Communication - If I have to I can probably be satisfied with devoting one cog to communicating and maintaining a simple shared registry, at first. But Id prefer memory management that can treat the entire system's memory as a common resource, though priority can always be given to local operations over global ones, I suppose. The same would be nice in terms of Processing power, but Im not familiar enough with multi-core programming to know how feasible it is to devote multiple cogs to one task. Ideally the individual chips would have some cogs dedicated to local tasks (typically external things related to hardwired resources like sensors or motor control) while the "spare" cogs are treated as a floating resource to be allocated to more internal processing tasks (analysis, voice recognition, multimedia output). While I intend for it to be hardwired at this point, it would be nice if the communication scheme allows for wireless communication bridges to be used with some chips.
Attempting to break the project down into discrete goals, I see:
-A Board Layout with compatible communication scheme.
-Memory Management (including global Memory addressing), scalable
-Process Load Management, scalable
-Multi-Chip Boot Loader
-?
So what do you, the guru's think? Can you point me to any similar projects? Do you have any advice or concerns with the plan? Anything that's impossible or anything that is already done I can use?
Comments
Here's a long list of multiple Propeller projects. I'm afraid most of the links are dead but you might be able to find enough key words to find them again.
A couple of threads I think are interesting are Clock Loop's 55 Propeller project. and jazzed's TetraProp board. You can find my 8 Propeller monstrosity in post #132.
Edit: Cluso99 made some interesting multiple Propeller boards. I don't have links handy. There have been lots of cool multiple Propeller projects.
Two things you have to understand about this project are A)I generally intend to set loft goals jut to give myself a vector to chase, but the main purpose is an educational exercise to see what it would take, and B)Im more of a hardware guy so my programming experience with has been very simple robotic applications or else larger industrial PLC work that was all in more established communication environments. So that mostly means it's best to assume Im an ignorant moron unless I prove otherwise
So to better define the parameters of the endevor: Stage 1 final product would be a moderately complex robot, which would have various mobility devices and sensors doing independant (more or less) duties of their own, things that would require/prefer direct hardware connections to the chip/cog handling it's task. The robot would have several cores scattered about, and perhaps a central stack of them TetraProp style just for extra resources. Then Im aiming for some kind of system so that any idle Cogs can contribute their memory and processing power to some other more abstract task suitable to , currently Im thinking either running something akin to Linux if such a build is still around, and/or contributing to one of the Distrubuted Computing efforts like folding@home or Electric Sheep.
Stage 2 would involve taking that framework and severing all physical connection requirements such that each chip would have its own mobility and interconnect in a decentralized wireless mesh. In other words: SwarmBots!
One cog's memory is not available to the other cogs. The "extra" cog would need a program in order for another cog to interface with it.
I'm not aware of any sort of Linux build for the Propeller nor do I think any such attempt would be useful.
The Propeller is a lot of fun to program. Just start getting one Propeller to do what you want and once you've get the hang of how the Propeller works, you'll be better able to decide on what sort of communication scheme you need when using multiple Propellers.
At the bottom of post #1 of my index (see signature) there is information about inexpensive nRF24L01+ modules. These little transceivers would be a great way to get a bunch of swarm bots communication with one another.
Yes, Precisely. I picture the thing operating on two levels, though Im not very experienced with this kind of protocol so there's likely a better way to do it. At the low level (brain-stem) I'll expect to establish a simple global memory registry, and allot one cog per chip to communicating and maintaining it (with some form of asynchronous Duplex communication most likely, there are several options in the OBEX I just need to settle on which is best for large/variable arrays of chips). Individual hardware oriented programs will use this for communication and coordination, mostly for physical movement and navigation. Then any Cogs (and it's associated resources) that are not actively required for those hardware oriented would contribute to some degree of virtualized environment that would be capable of harnessing their memory and process capabilities for some larger software tasks. That's where a Linux port would come in, since it would open up a vast amount of establish software that doesnt have to be hardware dependent.
In absence of some sort of Linux port, Id be left building up the pieces myself, though again there are several options on the OBEX that would provide starting points. Something that at the very least would manage the multi-chip Memory, ideally an full file system. Memory is easier than processors though, and Im even more in the dark than usual on how to go about virtualizing that resource, which is why I was hoping there was something like a linux port that would have already broken ground on that topic.
As JLocke notes, I had come across Sphinx, though it's thread mentions other port efforts for Linux or Unix systems. While linux appeals to me for obvious reasons, anything capable of virutalizing the chips' resources would be great.
Sweet! those look great.
He was meaning that the COG RAM is not easily accessible by other cogs (and the PASM program that one would need to write to allow that cog to share some of that 512 longs of memory would use up some of the memory that you are trying to access). There would be a fair amount of overhead for a relativity small gain in usable memory. That said, using one cog to run a inter-P8X32A communications protocol and HUB memory pool is definitely doable.
However, if memory was the constraint that was holding you back creating whatever program you desired, it might be easier to 1) go to the 'extra' 32k memory available in the commonly installed external 64k EEPROM, 2) add a sd card, 3) add some other additional external memory chip.
I would also suggest you begin with designing/flow charting/programming for the specific project you have in mind now, then when you find you need extra hardware capabilities, add them at that time. I think you will find that the resources that a single P8X32A has will allow you to have a crazy amount of features (for a micro-controller) before you need need to start squeezing the design for more processing power or memory.
One lesson I have learned with the P8X32A - keep in the 'object oriented' mindset - if you do need to add another chip, it will mitigate the 'untangling of spaghetti'
my .02
Nate
I'm pretty sure such a program exists. I couldn't ever imagine needing to use such a program since it's easy to add additional memory with a SD card or memory chip of some sort.
This is where Im at with the project right now, trying to pin down the specific needs and limitations of what Im trying to undertake, though I know it doesn't quite look that way. The reason for that is because my driving Concept is to create a single large mesh (eventually communicating entirely wirelessly) that could contain and operate all my various projects, and would eventually take the role of my own little Home Automation/IoT system. I want these to be able to handle their various I/O tasks independently while being aware of each other and able to react as one, and to be able to contribute their separate parts to a hivemind, a single virualized machine that for the time being will be rendering fractal art. Eventually Id want it to be able to leverage the hivemind for more practical uses like machine vision and pattern recognition routines. This is why a Linux port particularly appeals to me, because it would theoretically allow the possibility of Connecting a Kinect to the system, and using it's interface for more advance control.
I was originally dead set on the idea of having a completely decentralized mesh architecture (for the swarm-bot idea, so that no one node would have priority or be a critical failure point), but nearly everyone seems to have adopted some form of Master/Slave paradigm for multi-prop system, and Im wondering if I need a truly decentralized structure or if I should accept the Master/Slave idea and just attempt to make a robust fail-over protocol for when communication to the Master is lost. Any thoughts?
But @Prof_Braino as spokesperson for PropForth mentioned a lot of times now that @Sal implemented some shared communication channels between Propeller chips.
I tried my luck with forth a couple of times in my life but never really grooked it.
But as far as I remember PropForth is able to integrate multiple Propellers into one single environment where you are able to 'address' a cog by PropId and CogId and call Up any word (sort of Forth name for procedure/function).
I am not sure if anybody ever implemented a useful system in larger scale, but as far as I followed the threads of PropForth the requirements for a 'slaved' P1 chip are quite minimal. PE-Kit comes to my mind.
As anybody knows Forth requires a certain mindset. If you can handle HP calculators and reverse polish notation used with them, then you may able to handle Forth. If you have trouble with typing 4 5 + to get the result of 9 you might have a harder time to learn Forth. I do. Can't wrap my head around it. Other people get it and are able to program Forth. Give it a try to see for yourself.
I hope @Prof_Braino or other PropForth guys chime in here because I am way out of my water here.
But as far as I know PropForth is the ONE AND ONLY development environment for the Propeller claiming to SEAMLESSLY integrate multiple propellers with one set of sources to provide one big application.
Enjoy!
Mike
Have you seen the Propeller based HIVE project? Google that using Chrome so you can use the on-the-fly translation tools. All kinds of interesting ideas from the three-prop project.
Jeff