Picaxe Network.
- Thread starter fretei
- Start date
Jeremy Leach
Senior Member
Hi tore, which bit are you confused about?
I have had this working in the past, but am having trouble with it now.
It is Hippy's website: http://www.hippy.freeserve.co.uk/picaxeio.htm
It is Hippy's website: http://www.hippy.freeserve.co.uk/picaxeio.htm
confused...
Well I guess its the I2C, from other posts I found out that it is possible
to set up he pix's as master and slaves, but how is it possibel to get a communicaton slaves --> slaves slaves ---> master :
I have spendt a lot of time googling this problem without getting
any solutinons ... confused:
Hi.
Well I guess its the I2C, from other posts I found out that it is possible
to set up he pix's as master and slaves, but how is it possibel to get a communicaton slaves --> slaves slaves ---> master :
I have spendt a lot of time googling this problem without getting
any solutinons ... confused:
Jeremy Leach
Senior Member
Well, there isn't a simple answer without knowing more about what you are trying to do 
There are a number of ways to transfer data between picaxes, all with their own merits, and many have been discussed here before. It would really help to outline in more detail what you're trying to do, and I'm sure we'd find it interesting ...
There are a number of ways to transfer data between picaxes, all with their own merits, and many have been discussed here before. It would really help to outline in more detail what you're trying to do, and I'm sure we'd find it interesting ...Andrew Cowan
Senior Member
How far apart are the picaxes?
Wired? Wireless?
Is all data bidirectional?
A
Wired? Wireless?
Is all data bidirectional?
A
Why 3 picax's
Mainly they are used as 'inteligent' I/o expanders
lets say one of the input ports on axe 3 is active I want to send data to
axe 1 to do something on on of it's output ports ,and so on
Im trying to get an old pinball to work with pics and needs a lot of i/o
and therfore up to 4 pic's to work together.
I know this can be solved using other solutions, but this would be the most elegant, every pic does it own work, lamps, displays, solenoids..
but I have to exchange data between the pic's to get this right..
Mainly they are used as 'inteligent' I/o expanders
lets say one of the input ports on axe 3 is active I want to send data to
axe 1 to do something on on of it's output ports ,and so on
Im trying to get an old pinball to work with pics and needs a lot of i/o
and therfore up to 4 pic's to work together.
I know this can be solved using other solutions, but this would be the most elegant, every pic does it own work, lamps, displays, solenoids..
but I have to exchange data between the pic's to get this right..
Jeremy Leach
Senior Member
Ok, that helps. So if it's pinball then you will want data exchanged very quickly, right? Any guess at the maximum delay that could be tolerated ? (e.g 100ms from starting sending to finish receiving??)
Would there be one master and a number of slaves and the master just sends data out to the slaves?
Also what sort of data to be transferred? If it's just single byte values then one method people have used is to use the pulsout and pulsin commands and the value is sent in the width of a pulse. If more than one byte then you might need to use Serout and Serin commands. If simple on/off signals are being sent then could just detect line levels.
Sounds like the communication could be pretty random, in which case the slaves would have to be listening for communication from the master and respond instantly. Could be issues here.
All depends ...
Would there be one master and a number of slaves and the master just sends data out to the slaves?
Also what sort of data to be transferred? If it's just single byte values then one method people have used is to use the pulsout and pulsin commands and the value is sent in the width of a pulse. If more than one byte then you might need to use Serout and Serin commands. If simple on/off signals are being sent then could just detect line levels.
Sounds like the communication could be pretty random, in which case the slaves would have to be listening for communication from the master and respond instantly. Could be issues here.
All depends ...
hippy
Ex-Staff (retired)
As per Jeremy, the communications architecture can be crucial in determining how to implement the system. If there's just one master controller sending to any number of slaves that's quite simple. A master sending and also initiating reads may not be too bad, but once you are into peer-to-peer, anyone can talk to anyone, networking it can get quite complicated.
It is possible to split a node into both a send only and receive only part which can reduce the network back to a master sending and initiating reads to simplify things but may increase the number of PICAXE's needed. It's not impossible to do both on the same PICAXE but it depends on exactly what you need to do.
There's a lot of design work in networking, determining what data needs to come from where, go to where and then considering how to do it. It's one of those Catch-22 cases where you have to design it to see if the design will work then modify it if not. Most debugging is mental, not in making it work, but trying to imagine the circumstances in which it won't.
Rule of thumb is that if you can do it all with a single PICAXE which may need ( possibly intelligent, other PICAXE ) I/O expanders and all communications is notionally ( eg, ignore bi-directional handshaking issues ) always one direction into or out of that master it's a much easier system to design.
It is possible to split a node into both a send only and receive only part which can reduce the network back to a master sending and initiating reads to simplify things but may increase the number of PICAXE's needed. It's not impossible to do both on the same PICAXE but it depends on exactly what you need to do.
There's a lot of design work in networking, determining what data needs to come from where, go to where and then considering how to do it. It's one of those Catch-22 cases where you have to design it to see if the design will work then modify it if not. Most debugging is mental, not in making it work, but trying to imagine the circumstances in which it won't.
Rule of thumb is that if you can do it all with a single PICAXE which may need ( possibly intelligent, other PICAXE ) I/O expanders and all communications is notionally ( eg, ignore bi-directional handshaking issues ) always one direction into or out of that master it's a much easier system to design.