It looks like the same project, using PICs instead of Propellers.
Perhaps it is the same project and poster. That may explain the need for all the prop chips. Poster may not understand the concept or implications of 8 cores in a single chip!!!
Frank
P.s. In the interest of full disclosure, the net connection I suggested was actually implemented in the early '90s using a number of SAB8051 variants and some x86 chips using arcnet devices to connect it all through fibre optics. It ran the non-realtime signaling and parameterization of a major OEMs Card/Angio system.
I have to admit, I have submitted the same problem to two other Forums in order to reach the largest audience.
The microcontroller I use more often is and will continue to be the Propeller (I understand its multitask capability), but I use many other types as well (Stamps, Pic, even Arduino!).
Sorry if it may shock some of you guys.
There is no one universal ultimate microcontroller, good for everything. The Propeller excels at some things and, although some amazing things have been done with it, it's not the best choice for a lot of tasks, particularly where the task is small and simple and cost is an overriding feature.
"to two other Forums" ... I hope these were not other Parallax forums. Cross-posting here is against forum guidelines.
There's a two part article in the Nuts and Volts Columns on networking Stamps together using a multi-drop serial network. The same ideas could be applied to the Propeller. Click on the Resources tab on the main Parallax webpage to get to the N&V Column index.
I've used a large multi-computer network (up to 254 processors) using a simple serial network. Each processor used a serial port with an open collector driver. The original speed was 9600 Baud, but higher speeds could be used. These were connected using a simple twisted pair and a pull-up resistor at the ends of the network. There was a Schmitt trigger buffer for receiving for each processor. These used a simplified version of the ArcNet protocol (here, here, and here)
IMHO the most sense makes to combine a PIC and a Propeller.
You get the advantages of the PIC (fast big code, ADCs, PWMs, and a big Flash, which can also hold the code for the Propeller)
and you can have additional 7 parallel tasks from the Propeller (one cog for communication).
So you also need no complicated bus protocol between several chips, you only need one serial connection btween two chips.
first, I would like to thank you all for suggestions, I will take the time to study each of them in details. I really like this Forum.
The description of the problem I want to address is incomplete (wanted to go straight to the point).
Actually, the mandate of each Prop is not really important here.
The capability I would like to develop is to make many Props communicate efficiently (a kind of network of Propellers).
This capability would be very useful in a complex robot that involves many networked Props, each of them being fully busy to fulfill their mandate (all cogs in function).
I strongly believe that we can use the Propeller technology to build such complex systems (which is of course not easy, but really fun and challenging).
I agree, this kind of project is a long term effort. Doing it, you learn a lot and you may end up with very surprising robots.
Thanks again, I really appreciate your feedback,
Mario
Thanks Mario_ for the clarification. Sorry this went OT (off topic).
To progress further, I suggest that first you just use serial (the Full Duplex Serial or Parallax Serial Terminal objects from OBEX) to get your multiple props (or mix of props and other processors) working in your solution. Once you have this running, you will understand your requirements much better and then be able to ask for help specifically for your newly specified application. This is because, like everything, there are many ways to do something, with some ways being better than others for certain applications.
I prefer where possible to use a propeller, because it is easier and faster to implement, and I am concentrating on one type of chip. However, there are times when another chip just has to be used, be it for price, pins, size, etc. The PING sensor is a classic - it has another tiny processor on board (PIC?). Those who use this module use it as just that, a module - who cares what processor is used.
I for one will be interested to see what you do with your project, so do post progress updates.
Mike: I believe the multiple posts were on other forums, so this is fine.
Ho, I forgot to say that the two other forums are Sparkfun (for Pic) and Adafruit (for Arduinos).
The best suggestions (from far) came from Parallax Propeller Forum.
Now, I think I have a lot to read (to understand the suggestions people have posted) before I can go further.
Thankyou Mario_. It's nice to see you obtained more help here. The prop and this forum are great.
I will watch with anticipation to see what you decide after you have digested the help. And, if you get stuck or have any further questions, don't hesitate to ask. We are all really a friendly bunch with lots of various experiences.
Propeller should be able to communicate directly with any other Propeller at any time.
Actually, I need (would like) to create a "fully connected network of Propellers".
I'm not sure about that second line - one may reach a point where the overhead of communications means each propeller has no time to do anything.
But that first one - well I have a thought. Get a piece of paper and draw a pentagon. Each point of the pentagon is a propeller so there are 5. Now draw a line between each propeller and every other one. Each prop has 4 lines. Now, it so happens that in the Obex is a piece of code written by Tim Moore where he has put 4 serial port drivers into one cog.
So - if you have each prop talking to 4 others, that will take 8 pins and one cog. That leaves lots of cogs free for other pins, and also lots of pins too. And every propeller can talk directly to every other propeller.
Thanks Dr_Acula, the footprint of the solution appears to be small, leaving the cog power and pins for other tasks.
I agree with you, the word "fully connected network of Propellers" may not be the correct words.
My native language is French (from Quebec, Canada), this is why there are glitches here and there in my English!
I would take a 6-month immersion in Australia or USA if my boss would accept to send me there
Props can program without the Master-Slave concept. The key is establishing some rules and using evolution code EC. You could load up the same code in each prop, then based on the ID of that prop, evolve the code for what needs to be accomplished. This technique works with 10 props or a hundred props and likely considerably more.
In post 2: The SEED is different from the first Stamp supercomputer BSS, because there is no Master. Each Stamp is an individual with unique rights and personalities.
I went down this rabbit hole Mario_ be careful. After several hours of reading and searching, I found an unfulfilling and questionable implementation of a multi-drop serial bus. I never did find where Each Stamp is an individual with unique rights and personalities. The code might exist and I never found the working example.
H, please provide a direct link to the 100+ Propeller and SEED computer code base and schematics.
Attached is the demo from my January column on a _dirt_simple_ serial protocol called HFCP (Human Friendly Control Protocol) -- yes, intentionally cheezy name. The initial point is to make "talking" to the Propeller though a terminal very easy. As the object is just parsing serial messages (that contain an address in them), it doesn't care if that message comes from a PC or another Propeller. The demo is designed to run on a QuickStart or Demo board and lets you control lights.
This code uses FDS with separate RX and TX pins (through the programming port) but it could just as easily be setup to use FDS in half-duplex mode over one wire (open drain configuration).
You'll need to explore the comments in the main file and the HFCP object for documentation. A full explanation of how it works will be my January 2012 column (Nuts & Volts magazine).
Now... this isn't super robust (no checksum), but it does work. One of my EFX-TEK customers is already using it in a low-bandwidth RS-485 application. I will be adding an optional checksum for those apps where the human is not part of the messaging system.
Comments
I forgot the link I posted was before the Forum Migration.
On most of the posts, you can replace "parallax" with "parallaxinc" and get to the posts.
I think the posts from Clock Loop where most interesting, and had a lot of info.
http://forum.sparkfun.com/viewtopic.php?f=4&t=30571
It looks like the same project, using PICs instead of Propellers.
Perhaps it is the same project and poster. That may explain the need for all the prop chips. Poster may not understand the concept or implications of 8 cores in a single chip!!!
Frank
P.s. In the interest of full disclosure, the net connection I suggested was actually implemented in the early '90s using a number of SAB8051 variants and some x86 chips using arcnet devices to connect it all through fibre optics. It ran the non-realtime signaling and parameterization of a major OEMs Card/Angio system.
The microcontroller I use more often is and will continue to be the Propeller (I understand its multitask capability), but I use many other types as well (Stamps, Pic, even Arduino!).
Sorry if it may shock some of you guys.
Mario
"to two other Forums" ... I hope these were not other Parallax forums. Cross-posting here is against forum guidelines.
There's a two part article in the Nuts and Volts Columns on networking Stamps together using a multi-drop serial network. The same ideas could be applied to the Propeller. Click on the Resources tab on the main Parallax webpage to get to the N&V Column index.
I've used a large multi-computer network (up to 254 processors) using a simple serial network. Each processor used a serial port with an open collector driver. The original speed was 9600 Baud, but higher speeds could be used. These were connected using a simple twisted pair and a pull-up resistor at the ends of the network. There was a Schmitt trigger buffer for receiving for each processor. These used a simplified version of the ArcNet protocol (here, here, and here)
Cheers,
Mario
You get the advantages of the PIC (fast big code, ADCs, PWMs, and a big Flash, which can also hold the code for the Propeller)
and you can have additional 7 parallel tasks from the Propeller (one cog for communication).
So you also need no complicated bus protocol between several chips, you only need one serial connection btween two chips.
Andy
Thanks Mario_ for the clarification. Sorry this went OT (off topic).
To progress further, I suggest that first you just use serial (the Full Duplex Serial or Parallax Serial Terminal objects from OBEX) to get your multiple props (or mix of props and other processors) working in your solution. Once you have this running, you will understand your requirements much better and then be able to ask for help specifically for your newly specified application. This is because, like everything, there are many ways to do something, with some ways being better than others for certain applications.
I prefer where possible to use a propeller, because it is easier and faster to implement, and I am concentrating on one type of chip. However, there are times when another chip just has to be used, be it for price, pins, size, etc. The PING sensor is a classic - it has another tiny processor on board (PIC?). Those who use this module use it as just that, a module - who cares what processor is used.
I for one will be interested to see what you do with your project, so do post progress updates.
Mike: I believe the multiple posts were on other forums, so this is fine.
The best suggestions (from far) came from Parallax Propeller Forum.
Now, I think I have a lot to read (to understand the suggestions people have posted) before I can go further.
Also want to thank Cluso99.
Best,
Mario
I will watch with anticipation to see what you decide after you have digested the help. And, if you get stuck or have any further questions, don't hesitate to ask. We are all really a friendly bunch with lots of various experiences.
I'm not sure about that second line - one may reach a point where the overhead of communications means each propeller has no time to do anything.
But that first one - well I have a thought. Get a piece of paper and draw a pentagon. Each point of the pentagon is a propeller so there are 5. Now draw a line between each propeller and every other one. Each prop has 4 lines. Now, it so happens that in the Obex is a piece of code written by Tim Moore where he has put 4 serial port drivers into one cog.
So - if you have each prop talking to 4 others, that will take 8 pins and one cog. That leaves lots of cogs free for other pins, and also lots of pins too. And every propeller can talk directly to every other propeller.
I agree with you, the word "fully connected network of Propellers" may not be the correct words.
My native language is French (from Quebec, Canada), this is why there are glitches here and there in my English!
I would take a 6-month immersion in Australia or USA if my boss would accept to send me there
Best,
Mario
No joke.
Mario_:
I opted to connect over 100 props using multiple parallel arrays. Even the arrays can run in parallel. See ParP in the Index.
http://forums.parallax.com/showthread.php?124495-Fill-the-Big-Brain&p=977025&viewfull=1#post977025
Props can program without the Master-Slave concept. The key is establishing some rules and using evolution code EC. You could load up the same code in each prop, then based on the ID of that prop, evolve the code for what needs to be accomplished. This technique works with 10 props or a hundred props and likely considerably more.
I wrote up more detail in this thread which successfully tested the concept using the BASIC Stamp SEED Supercomputer.
http://forums.parallax.com/showthread.php?113829-BASIC-STAMP-SEED-Supercomputer
In post 2: The SEED is different from the first Stamp supercomputer BSS, because there is no Master. Each Stamp is an individual with unique rights and personalities.
H, please provide a direct link to the 100+ Propeller and SEED computer code base and schematics.
This code uses FDS with separate RX and TX pins (through the programming port) but it could just as easily be setup to use FDS in half-duplex mode over one wire (open drain configuration).
You'll need to explore the comments in the main file and the HFCP object for documentation. A full explanation of how it works will be my January 2012 column (Nuts & Volts magazine).
Now... this isn't super robust (no checksum), but it does work. One of my EFX-TEK customers is already using it in a low-bandwidth RS-485 application. I will be adding an optional checksum for those apps where the human is not part of the messaging system.