2 PICAXE EEPROM and I2C Bus ?

[rjconway]

Can I have two PICAXE and one EEPROM chip and get one chip to write the other to read from the EEPROM.

I was thinking I could use some digital I/O control lines between the two PICAXE so that both do not try and communicate at the same time.

I want one PICAXE to provide temp/pressure and flow calculations with the other providng LCD interfacing and general control. MY LCD display PPICAXE is getting full thus the reason to split the functions.

Is there such a thing as a I2C RAM chip instead of a EEPROM. I want to write 10 variables every 2-3 seconds.

 

[tarzan]

PCF8570P i2c RAM (MIC052)<A href='http://www.techsupplies.co.uk/cgi-bin/techsupplies.filereader?43dad3710052ba7c2740c2c98abb0744+EN/catalogpages/1108/1' Target=_Blank>External Web Link</a>
Datasheet: <A href='http://www.rev-ed.co.uk/docs/MIC052.pdf' Target=_Blank>External Web Link</a>

 

[ylp88]

<A href='http://www.rev-ed.co.uk/picaxe/forum/Topic.asp?topic_id=608&amp;forum_id=7&amp;Topic_Title=Two%2BPICAXE%2B%253A%2BOne%2BEEPROM&amp;forum_title=No+new+posts+please%21+2' Target=_Blank>External Web Link</a>

The first question I ever asked on these forums, if I recall... memories...

Not perfect news, sorry...

<b><i>ylp88 </b> </i>

 

[ylp88]

I recall it being discussed more recently, too. Not sure which forum it was in, nor what it was called. Perhps the outsome was a bit more promising?

<b><i>ylp88 </b> </i>

 

[rjconway]

sounds like all I need is a couple of solid state switches to connect / disconnect the two control lines....I maybe able to use the ram in my RTC.

 

[hippy]

A Forum Search should reveal a fair amount of discussion, although I don't recall anyone ever getting back and reporting if any solutions had actually worked or not.

I can't see any reason that an I2C device can't be switched between two PICAXE's although a mechanism would be needed to avoid contention if both try to access it at the same time. Another alternative is to have a single PICAXE communicating with the I2C devices and have the other PICAXE's communicate with that.

 

[hippy]

If you are just splitting functionality across multiple PICAXE's it may be easier to have them communicate using serial and handshaking rather than through any 'shared memory'. If you need lines to handle access contention anyway, it may be easier to use the same to just pass the data over directly.

 

[rjconway]

I have never done serial to serial however worry about the reciever just sitting and waiting forever if the transmitter fails.

 

[BeanieBots]

I have the exact same issue and shall be attempting to make two PICAXES share the same I2C RAM over the next week or so.
Connecting the two SCL and SDA lines together via resistors will prevent a hardware catastrophy if both should attempt talking at the same time. I'm still working on the handshaking arbitration but this will be specific to MY needs and might not suit YOUR application. I'll let you know how it goes in a week or so.

 

[andrewpro]

Provided you use limiting resistors on the SDA and SCL lines, having two chips talk to the same I2C device are not difficult.

There are two problems, beyond just getting them talking, that need ot be addressed. First, of course, is bus contention. Getting two chips tlaking at once makes a hell of a mess.

The second is keeping both chips on the same page (pun fully intended! hehe) You have ot mak esure that the chips are both reading and writing from the same area on the memory, and that they dont get out of whack. That was the most difficult thing for me, and I wasn't doing memory, I was using IO expanders. I expect it to be much more of a hassle with memory, where addresses for the pertinent data can change at a moments notice. If the two chips arent in sync with whos writing what to where, and vise versa, youll have issues.

--Andy P

 

[BeanieBots]

I fully agree with andypro. My personal issue is that one device uses interupts for a user interface which must respond quickly, the other has critical timing issues within loops. Waiting around is not an option for either so my arbitration needs to make decisions on what must be done when both want the bus. Namely, continue knowing the read/write did not happen and try again at the next 'time slot' or wait for a 'limited' time hoping the bus will become available again soon enough to do the read/write without upsetting loop times. Once I've worked out what I NEED it to do, I'm sure there will be way of making it do it.

 

[notwhoyouthink]

Try a Philips PCA9541 I2c Master Selector - put a RAM chip on the common bus and the two PICAXEs on the master inputs!

 

[notwhoyouthink]

PCA9541 Info:
http://www.semiconductors.philips.com/cgi-bin/pldb/pip/PCA9541_4.html <A href='http://www.semiconductors.philips.com/cgi-bin/pldb/pip/PCA9541_4.html' Target=_Blank>External Web Link</a>
Datasheet:
http://www.semiconductors.philips.com/acrobat_download/datasheets/PCA9541_4.pdf <A href='http://www.semiconductors.philips.com/acrobat_download/datasheets/PCA9541_4.pdf' Target=_Blank>External Web Link</a>

 

[Rickharris]

This may not apply but could you provide a count to the picaxes from a common external source and have them &quot;talk&quot; alternatly say one on odd count and one on even count.