I2c memory
- Thread starter Magnusson
- Start date
Unfortunately not. PICAXEs can only be masters on the I2C bus, and you can only have one master at any time - so you can't have two PICAXEs on the I2C bus at the same time. ..well I suspect you could, but a problem arises when they both try to use the I2C bus at the same time (and there may be electrical nasties involved in just directly connecting output lines from different PICAXEs together).
A shame really, as inter-PICAXE communication via shared memory would be a nice solution to a number of problems.
I have some thoughts swimming around my head about a potential hardware solution that would enable this to happen, which I need to draw out to see if it would work, but it's along the following lines (where for simplicity, let's pretend only one line, called say SDA is needed to access an external memory chip):
- feeding the SDA lines from each PICAXE into one side of separate AND gates
- feed an output line, say Out1, from each PICAXE to the other input of the AND gate that its SDA line is going to
- feed the output of each AND gate into an OR gate
- feed the output of the OR gate to the memory
- feed an Out2 line from each PICAXE to an input line, say In2, of the other PICAXE
Then the Out2 lines are used as 'semaphores' to indicate that a particular PICAXE wants to use/is using the bus. If a PICAXE wants to use the bus, it checks its In2 line to see if the other is using it.....
...if not, it sets its Out2 line high, indicating to the other PICAXE that it has control of the bus. It then sets its Out1 line high, thus enabling its SCL line to get through the AND gate and the OR gate to the memory and reads/writes the data. It then sets Out1 low to stop the SDA line getting to the memory and Out 1 low, indicating it has released the bus
..if it is, then it 'backs off' for a period of time (order of 20ms?) and tries again. Hopefully, the bus will now be free (depends how long the other PICAXE is using the bus for) and it can use the memory
Its similar to some of the ideas behind Ethernet comms and there's a few design issues to sort out around both PICAXES wanting the bus at EXACTLY the same time, failure modes etc etc
Any thoughts anyone?
Edited by - MartinM57 on 4/27/2005 10:31:02 PM
A shame really, as inter-PICAXE communication via shared memory would be a nice solution to a number of problems.
I have some thoughts swimming around my head about a potential hardware solution that would enable this to happen, which I need to draw out to see if it would work, but it's along the following lines (where for simplicity, let's pretend only one line, called say SDA is needed to access an external memory chip):
- feeding the SDA lines from each PICAXE into one side of separate AND gates
- feed an output line, say Out1, from each PICAXE to the other input of the AND gate that its SDA line is going to
- feed the output of each AND gate into an OR gate
- feed the output of the OR gate to the memory
- feed an Out2 line from each PICAXE to an input line, say In2, of the other PICAXE
Then the Out2 lines are used as 'semaphores' to indicate that a particular PICAXE wants to use/is using the bus. If a PICAXE wants to use the bus, it checks its In2 line to see if the other is using it.....
...if not, it sets its Out2 line high, indicating to the other PICAXE that it has control of the bus. It then sets its Out1 line high, thus enabling its SCL line to get through the AND gate and the OR gate to the memory and reads/writes the data. It then sets Out1 low to stop the SDA line getting to the memory and Out 1 low, indicating it has released the bus
..if it is, then it 'backs off' for a period of time (order of 20ms?) and tries again. Hopefully, the bus will now be free (depends how long the other PICAXE is using the bus for) and it can use the memory
Its similar to some of the ideas behind Ethernet comms and there's a few design issues to sort out around both PICAXES wanting the bus at EXACTLY the same time, failure modes etc etc
Any thoughts anyone?
Edited by - MartinM57 on 4/27/2005 10:31:02 PM
I dont actually see a problem with it as long as you dont run into a bus contention situation. I would use a third pin between the two, make one pin an input and an output. Input when not wanting the bus, output when you do want it.
If one chip wantes to use the bus, it first checks to see if this line is high. If it is, it skips on to it's next proces, or waits a reasonable amount of time before it checks the pin again. As long as this pin is high, it is not allowed to use the bus.
If the pin is low, it then makes it high. This means that it has taken control of the bus, and lets the other picaxe know to keep off of it.
For normal operations, both picaxes should have thier "contention resolution" pin, or whatever you want to call it, will be an input. It will only become an output when it's ready to take control of the I2C bus. The I2C pins are otherwise ignored completely.
Upon completion of it's I2C duties, it lowers the contention pin, and returns it to an input state, and goes about it's business.
There are also I2C multiplexers, for doing jsut this sort of thing. They're alot more expensive than a piece of wire and a few lines of code though. They handle the contention, buffer the I/O and everything on thier own so you dont have to worry about it.
You may also run into capacitance problems doing it the way I described, depending on how many chips you use, etc. Unless you can tri-state the picaxe pins (go into Hi-Z) which I dont think you can, it's capaitance will ahve to be added to the total in the line, and cannot psh it over 400pf or youll have timing issues.
If one chip wantes to use the bus, it first checks to see if this line is high. If it is, it skips on to it's next proces, or waits a reasonable amount of time before it checks the pin again. As long as this pin is high, it is not allowed to use the bus.
If the pin is low, it then makes it high. This means that it has taken control of the bus, and lets the other picaxe know to keep off of it.
For normal operations, both picaxes should have thier "contention resolution" pin, or whatever you want to call it, will be an input. It will only become an output when it's ready to take control of the I2C bus. The I2C pins are otherwise ignored completely.
Upon completion of it's I2C duties, it lowers the contention pin, and returns it to an input state, and goes about it's business.
There are also I2C multiplexers, for doing jsut this sort of thing. They're alot more expensive than a piece of wire and a few lines of code though. They handle the contention, buffer the I/O and everything on thier own so you dont have to worry about it.
You may also run into capacitance problems doing it the way I described, depending on how many chips you use, etc. Unless you can tri-state the picaxe pins (go into Hi-Z) which I dont think you can, it's capaitance will ahve to be added to the total in the line, and cannot psh it over 400pf or youll have timing issues.
Jeremy Leach
Senior Member
This topic has been discussed before and I remember Hippy suggesting using one PicAxe as a sort of shared 'gateway' (apologies if I'm getting this wrong Hippy) to the i2C memory.
My own experiments have proved it's relatively easy to get PicAxes talking to each other with direct connections between Ins and Outs (using Serout and Serin commands). Unfortunately it's only the X parts that can use i2C so the 'gateway' would have to be an 18X or higher. However this downside could be offset by the fact that the PicAxes wanting to talk to the i2C chips via this gateway don't need to be X parts anymore.
It could be dedicated to performing this gateway role (ie continuosly polling each connected PicAxe to see if there were requests for writes and/or reads), or could perform this role as a 'side line' to some other main role.
This solution isn't fantastic for super time-critical applications. It also requires the invention of a protocol for inter-picaxe communication. But this is fun.
I think inter-picAxe comms is great and am pretty gob-smacked how powerful and effective it is. I'm also coming round to the feeling expressed a number of times on this forum that multi PicAxe solutions, using especially the cheap yet powerful 08M are often the way to go.
My own experiments have proved it's relatively easy to get PicAxes talking to each other with direct connections between Ins and Outs (using Serout and Serin commands). Unfortunately it's only the X parts that can use i2C so the 'gateway' would have to be an 18X or higher. However this downside could be offset by the fact that the PicAxes wanting to talk to the i2C chips via this gateway don't need to be X parts anymore.
It could be dedicated to performing this gateway role (ie continuosly polling each connected PicAxe to see if there were requests for writes and/or reads), or could perform this role as a 'side line' to some other main role.
This solution isn't fantastic for super time-critical applications. It also requires the invention of a protocol for inter-picaxe communication. But this is fun.
I think inter-picAxe comms is great and am pretty gob-smacked how powerful and effective it is. I'm also coming round to the feeling expressed a number of times on this forum that multi PicAxe solutions, using especially the cheap yet powerful 08M are often the way to go.
Thanks guys. This has been a big help. The project I’m thinking about is data logger that runs continuously without having to stop logging if I request data from it. I want to access the memory directly without interfering with the logger itself. The usage of the memory is it goes in cycles (oldest gets overwritten first). This was the idea for use of multiple access to the memory.