Has anyone done much experimenting with hooking up Picaxes in parallel, etc. to use in parallel or multi-core processing? I have started trying it today with three 08Ms and it seems like it might be a great way to speed things up and and get more done, especially in complicated robotics projects.
Parallel and Multi Processing
- Thread starter artswan
- Start date
westaust55
Moderator
A search of the forum (using google) see:
http://www.google.com.au/#hl=en&source=hp&q="parallel+processing"+site:http://www.picaxeforum.co.uk&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=670a114a9d413e26
found about 30 posts with parallel processing in the text of the post.
http://www.google.com.au/#hl=en&source=hp&q="parallel+processing"+site:http://www.picaxeforum.co.uk&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=670a114a9d413e26
found about 30 posts with parallel processing in the text of the post.
Andrew Cowan
Senior Member
My robot uses 18 PICAXEs at the last count (3x28 pins, 4x20 pins, 1x18 pins, 3x14 pins, 7x8 pins). It's very possible, and very powerful. The are all connected to a one-wire-network via a diode output and straight input.
A
A
Andrew Cowan
Senior Member
Search and Rescue Robot (actually 1.5kW 
). I'll try and put up a youtube video in the next couple of days.
A
). I'll try and put up a youtube video in the next couple of days.A
westaust55
Moderator
we know it uses Transdev's BRECOflex ATK10 series timing belts with special Linatex high grip bonded backings withSearch and Rescue Robot (actually 1.5kW
A
continuous helical tension members with 'S+Z' twist to further reduce belt run-off and heavy side loads on flanges
and matching pulleys, but not a mention of a PICAXE let alone 18 of them !
Argh! U_tube.
Okay great for a vidieo clip, but as I have said before, how about some PICAXE specific details here
EDIT:
@Andrew,
I did a quick search on google and found in excess of 100 items about you and your search and rescue robot with some having quite good photos (of you and/or the robot
) but only three mentions of PICAXE, one a broken link, one to a thread here, and one where you wanted help for an LCD to connect to a PICAXE on another forum.Why not a little more publicity for PICAXE since it is the core of the project?
If you already have some info posted here on the multi PICAXE aspects of your robot maybe you should have given a link to that thread.
Last edited:
Andrew Cowan
Senior Member
I'm writing an article for the D&T Association's 'Designing magazine' (distributed to schools in the UK) - that will talk more about the inner workings. None of the articles on the web at the moment were written by me, hence they only talk about what the author deems interesting (ie not PICAXEs).
A
A
Buzby
Senior Member
Hi artswan,
Having multiple CPUs communicating with each other while each is doing different things is a common scenario. All it really needs is a communication mechanism between the relevant processors. Andrew's S+R robot will probably be like this, with each PICaxe doing a different job, such as speed control or battery charging.
Another scenario is multiple CPUs talking to a single master, with each CPU running *exactly* the same programme. This is a good system for big number-crunching requirements, such as graphics rendering or game playing.
There was a project years ago in Byte, which used 64 microcontrollers linked to a PC. The result was a machine to calculate a fractal picture. Each CPU ran the same programme, but was given different pixel XY coordinates by the PC. As each CPU finished it's job it replied back to the PC, which then gave it a new pair of coordinates for it's next calculation.
This kind of system is very scaleable, just add more processors to make it go faster !.
To do something like this with PICaxe would be an interesting project. The processing power of even a small PICaxe is enough to run one quite heavy calculation. ( Remember, speed is not important, you will get that by adding more processors ! ) PICaxe ICs are certainly cheap enough to make it financially possible. The major fun would be writing the code in the PC to manage the flock of PICaxes.
I can't think of a reason for me to build one myself, but I can see the possibilities for an educational project in a computer science classe.
Good Luck,
Buzby
Having multiple CPUs communicating with each other while each is doing different things is a common scenario. All it really needs is a communication mechanism between the relevant processors. Andrew's S+R robot will probably be like this, with each PICaxe doing a different job, such as speed control or battery charging.
Another scenario is multiple CPUs talking to a single master, with each CPU running *exactly* the same programme. This is a good system for big number-crunching requirements, such as graphics rendering or game playing.
There was a project years ago in Byte, which used 64 microcontrollers linked to a PC. The result was a machine to calculate a fractal picture. Each CPU ran the same programme, but was given different pixel XY coordinates by the PC. As each CPU finished it's job it replied back to the PC, which then gave it a new pair of coordinates for it's next calculation.
This kind of system is very scaleable, just add more processors to make it go faster !.
To do something like this with PICaxe would be an interesting project. The processing power of even a small PICaxe is enough to run one quite heavy calculation. ( Remember, speed is not important, you will get that by adding more processors ! ) PICaxe ICs are certainly cheap enough to make it financially possible. The major fun would be writing the code in the PC to manage the flock of PICaxes.
I can't think of a reason for me to build one myself, but I can see the possibilities for an educational project in a computer science classe.
Good Luck,
Buzby
hippy
Ex-Staff (retired)
The biggest issue in any distributed processing system is the speed of communications between slaves and master. If it's quicker to do the processing than to pass out data and get results back you haven't gained anything.
An ideal project to demonstrate a multi-PICAXE parallel processing system would be Conway's Game of Life. A single PICAXE per cell with 8 inputs from adjacent cells and controlling a LED, even an RGB LED. It may also require a common clocking line to all PICAXE to keep things in sync so they all sample then process at the same time, and to control initialisation of the cells.
Perhaps not cheap but perfectly scalable and the update time for the 'entire universe' will be the same for one cell as for an infinity.
It's also a good basis for considering 'can this be done more cheaply; how do we use a single controller to control more than one cell (LED)' ? That will illustrate the trade-offs, gains and losses, required between simple and easy and the need for more processing speed and I/O and more complicated programming.
http://en.wikipedia.org/wiki/Conway's_Game_of_Life
An ideal project to demonstrate a multi-PICAXE parallel processing system would be Conway's Game of Life. A single PICAXE per cell with 8 inputs from adjacent cells and controlling a LED, even an RGB LED. It may also require a common clocking line to all PICAXE to keep things in sync so they all sample then process at the same time, and to control initialisation of the cells.
Perhaps not cheap but perfectly scalable and the update time for the 'entire universe' will be the same for one cell as for an infinity.
It's also a good basis for considering 'can this be done more cheaply; how do we use a single controller to control more than one cell (LED)' ? That will illustrate the trade-offs, gains and losses, required between simple and easy and the need for more processing speed and I/O and more complicated programming.
http://en.wikipedia.org/wiki/Conway's_Game_of_Life
Seeing Hippy's reply above,
reminded me of one of his earlier efforts:
See “Cybot” references
http://www.hippy.freeserve.co.uk/picaxe.htm
http://www.hippy.freeserve.co.uk/axe18bot.txt
http://www.hippy.freeserve.co.uk/axe18top.txt
http://www.hippy.freeserve.co.uk/axe18mon.txt
plus other references around his site.
e
reminded me of one of his earlier efforts:
See “Cybot” references
http://www.hippy.freeserve.co.uk/picaxe.htm
http://www.hippy.freeserve.co.uk/axe18bot.txt
http://www.hippy.freeserve.co.uk/axe18top.txt
http://www.hippy.freeserve.co.uk/axe18mon.txt
plus other references around his site.
e
Buzby
Senior Member
Hi Hippy,
I'm sure I've seen a coffee-table 'Game of Life' on the web somewhere, using methods similar to the idea you propose.
Each 'cell' is perfectly identical, no addressing needed. They don't communicate to a master, but as you say, they need a system wide clock pulse to keep them all synchronised.
The fractal engine is a bit different. Each 'pixel' takes a different amount of time to calculate, and the results are passed back to the PC to be collated into the right sequence.
The 'Life' project requires writing only a single piece of code to process the 8 inputs and light the LED. The 'Fractal' project also has a single piece of PICaxe code, but also requires that the central PC can select a particular PICaxe to send the coordinates to, and match the replies accordingly.
Addressing and selecting could be done very easily by using Dallas/Maxim 'Digital Serial Number' chips, but a much greater challenge would be to do it all in software, maybe by using some kind of 'Carrier Sensing / Collision Avoidance' algorithm.
Either 'Life' or 'Fractals' would make a good educational project, although at different ability levels.
Another possible project would have the Master broadcast the current state of a Chess board to 64 PICaxes. Each PICaxe then works out the best move for the single square it has previously been assigned to. The Master then selects the best result and updates the board.
Even more challenging would be to programme each PICaxe in-situ, with all the SERIN pins commoned together. This could be done by having each PICaxe execute the DISCONNECT command while running normally, and only execute a RECONNECT when the Master sends a certain instruction to an individual PICaxe. The Master could then run a macro of some sort to trigger a download from PE.
All-in-all, I think the low cost and powerful capability of the PICaxe system would be a good platform to develop a home-brew parallel-processor. Not as flashy as a Cray, but lots more fun !. I just wish I had the time.
Cheers,
Buzby
I'm sure I've seen a coffee-table 'Game of Life' on the web somewhere, using methods similar to the idea you propose.
Each 'cell' is perfectly identical, no addressing needed. They don't communicate to a master, but as you say, they need a system wide clock pulse to keep them all synchronised.
The fractal engine is a bit different. Each 'pixel' takes a different amount of time to calculate, and the results are passed back to the PC to be collated into the right sequence.
The 'Life' project requires writing only a single piece of code to process the 8 inputs and light the LED. The 'Fractal' project also has a single piece of PICaxe code, but also requires that the central PC can select a particular PICaxe to send the coordinates to, and match the replies accordingly.
Addressing and selecting could be done very easily by using Dallas/Maxim 'Digital Serial Number' chips, but a much greater challenge would be to do it all in software, maybe by using some kind of 'Carrier Sensing / Collision Avoidance' algorithm.
Either 'Life' or 'Fractals' would make a good educational project, although at different ability levels.
Another possible project would have the Master broadcast the current state of a Chess board to 64 PICaxes. Each PICaxe then works out the best move for the single square it has previously been assigned to. The Master then selects the best result and updates the board.
Even more challenging would be to programme each PICaxe in-situ, with all the SERIN pins commoned together. This could be done by having each PICaxe execute the DISCONNECT command while running normally, and only execute a RECONNECT when the Master sends a certain instruction to an individual PICaxe. The Master could then run a macro of some sort to trigger a download from PE.
All-in-all, I think the low cost and powerful capability of the PICaxe system would be a good platform to develop a home-brew parallel-processor. Not as flashy as a Cray, but lots more fun !. I just wish I had the time.
Cheers,
Buzby
Buzby
Senior Member
It would be easy to use a PICaxe with lots of data and code memory. This would have no problem holding a copy of the board and calculating one chess move, but a better challenge would be to use an 08 variant, after all, we don't need many pins.
It's probably too much for an 08M to calculate a chess move, so maybe draughts is a better choice to start with. It has some big advantages.
For a start, we are only interested in 32 squares on the board, as no piece is ever on a white square. So we only need enough memory to hold the state of half the squares on the board.
The board could be represented in 16 bytes, with 4 bits for each square. 0000=empty,0001=white,0010=black,0011=white king,0100=black king.
( Other more compact storage methods will use 12 or 10 bytes, but need more complex decoding. We have not much code space in 08's, so we keep the data structures simple.)
The second benefit of Draughts is that there are usually only two possible moves, and each of these is only 1-step long.
We can use a subroutine to evaluate these 2 possible moves. We will need to look ahead for threats or possible capture oportunities. We do this by calling the same subroutine, but base it around the square we are currently evaluating. This two-level evaluation won't play a very strong game, so we could call the subroutine again and again for more levels, but we need memory to keep track of where we are and what we found, so we'll add this later if space is available.
The above is the game code. We also need the comms and addressing code.
Addressing is the trickiest, but one method would be to use 3 analogue inputs hardwired with resistors to give different combinations of 0%,25%, 50%, and 100%. Decoding these would give each PICaxe a unique address.
Comms is simple. We receive when we see a header containing our unique address, or a 'broadcast' flag. Reception consists of populating our board, and starting our evaluation code. We transmit when polled by the master, and send back either a 'busy' signal, or our move with a value saying how 'good' it is.
The Master, either a bigger PICaxe or a PC, polls each slave until it gets a result from each. It then decides which is the 'best' move, makes it, waits for the human to move, then sends the new board to the slaves.
Phew !. That was quite a lot off the top of my head. I'm sure it needs a bit more thought, but the basics are there.
As I have said before, I'm sure a PICaxe based Chess machine is possible, and maybe parallel-processing is a route to explore.
Cheers,
Buzby
It's probably too much for an 08M to calculate a chess move, so maybe draughts is a better choice to start with. It has some big advantages.
For a start, we are only interested in 32 squares on the board, as no piece is ever on a white square. So we only need enough memory to hold the state of half the squares on the board.
The board could be represented in 16 bytes, with 4 bits for each square. 0000=empty,0001=white,0010=black,0011=white king,0100=black king.
( Other more compact storage methods will use 12 or 10 bytes, but need more complex decoding. We have not much code space in 08's, so we keep the data structures simple.)
The second benefit of Draughts is that there are usually only two possible moves, and each of these is only 1-step long.
We can use a subroutine to evaluate these 2 possible moves. We will need to look ahead for threats or possible capture oportunities. We do this by calling the same subroutine, but base it around the square we are currently evaluating. This two-level evaluation won't play a very strong game, so we could call the subroutine again and again for more levels, but we need memory to keep track of where we are and what we found, so we'll add this later if space is available.
The above is the game code. We also need the comms and addressing code.
Addressing is the trickiest, but one method would be to use 3 analogue inputs hardwired with resistors to give different combinations of 0%,25%, 50%, and 100%. Decoding these would give each PICaxe a unique address.
Comms is simple. We receive when we see a header containing our unique address, or a 'broadcast' flag. Reception consists of populating our board, and starting our evaluation code. We transmit when polled by the master, and send back either a 'busy' signal, or our move with a value saying how 'good' it is.
The Master, either a bigger PICaxe or a PC, polls each slave until it gets a result from each. It then decides which is the 'best' move, makes it, waits for the human to move, then sends the new board to the slaves.
Phew !. That was quite a lot off the top of my head. I'm sure it needs a bit more thought, but the basics are there.
As I have said before, I'm sure a PICaxe based Chess machine is possible, and maybe parallel-processing is a route to explore.
Cheers,
Buzby