2 picaxes and one memory chip

Hi all,

is it possible to have two picaxes reading and writing to a single i2c memory chip?

I am working on a project that needs to be able to do just this. I am using two 20x2's and a single 24LC512. wiring them up isn't a problem, but I'm not sure how the i2c timing would work. having a 'read/write' flag between the two 20x2's would have to be used, I get that (preventing both chips from trying to read/write at the same time).

Any help would be greatly appreciated.

I'm not an I2C expert, but my understanding is that the protocol is robust enough such that once ANY device starts talking into the bus, all other devices stand up in attention and listen to see if the message is directed to their individual address.

There are dozens of excellent I2C tutorials on the web that describe at length the I2C protocol.

Onsemi do a dual port i2c memory specifically for this - CAT24C208. However, I can't find anyone in the UK who stock them.

Best Regards

Peter

With Picaxes, this is possible, provided some method is implemented to prevent both masters to try to use the bus simultaneously. See, for instance, how Rev-Ed does it with the Net Server module (see the NET001 datasheet, page 14).

Normally, the i2c protocol would allow a multimaster configuration. A master that tries to take control of the bus while another is communicating would detect this conflict and await its turn. I don't think Picaxes do this, hence to need to have something else coordinating them.

I reckon you're right about requiring some 'busy' line. I've never tried it or checked the hardware side.

I wonder if it could be done without the extra comms if you wote a specific soft I2c routine. A kind of look before you leap arrangement maybe?

Another option might be to make one PICAXE a slave, the other a master and have them communicate with each other via I2C. One could then ask the other for the data or if you don't need too much data, one could act as the EEPROM.

Proper I2C bus control should be electrically safe with two masters as both sides can only pull the bus low; the worst which can happen is bus and data corruption. Some sort of arbitration would however be needed.

Wouldn't you need to protect the PICAXE SDA and SCL lines to prevent PICAXE outputs potentially being tied together?

Perhaps the Master / Slave PICAXE idea is simpler.

It is potentially dangerous territory.

When a PICAXE is used for I2C, SDA and SCL outputs become open-collector, but that doesn't mean they cannot be set otherwise and cause a 'smoke releasing' condition. That's a problem waiting to happen for any microcontroller with software controlled I/O lines and peripherals.

Even with only one micro in the system there's potential risk. I don't know how you'd quantify it but it's probably low, first the likelihood of it going wrong, and the necessity of an output being high and the slave pulling low to present a fault condition.

If it were safety critical it would probably be sensible to put in buffers and drivers which are fail safe. In general though, while the threat is there, the risk seems low. The risk increases with additional micros added on the bus but the question again is how to quantify that.

What the application is and what the developer is prepared to tolerate dictates what is acceptable and what isn't.

Personally I would use some hardware arbitration, any form of talking between the two chips or testing the line will be subject to race conditions, ie what's to stop them both testing at the same time and both thinking the line is free. As mentioned this won't do any physical harm but could corrupt data.

I'm sure it could be done with a very simple circuit, but I haven't thought of one yet.

Testing for line levels or arbitration (busy) logic levels..? Arguably have similar potential problems and similar workarounds.

Could we use some very simple components to protect? Schottky diodes maybe?
I'm still sure that a smart softI2C could get around this potential problem. I'm sure it's not quite the doom&gloom levels I see here

The two masters would obviously be connected together via the i2c bus. Those pins would be dedicated to i2c (either as a master or a slave): no chance of smoke.

A single handshake wire with a series 1k resistor between the PICAXEs would allow them to always check the other's status before becoming the master (after setting their status on that status wire). Both PICAXEs would idle as slaves.

Yeah I know, I have a habbit of invoking the MIRC principle (Make It Really Complicated ) but no matter what you do with simple handshaking there's the potential for a race condition. The slower the process and the more frequent the access the more potential.

We don't know what the application is though so whether or not that matters to vshortt is a different story (does it vshortt?). If he's logging the ph of the garden soil every 20 minutes it doesn't matter, if he's synchronising a level crossing boom with the stop lights it does.

Untested but here's a simple arbitration scheme which should work for any number of PICAXE, and also work for a single PICAXE in the case when others are removed from the network.

It works by monitoring three states of an analogue line; 255 when no one has acquired the bus, 128 when one has acquired the bus, 85 or less when more than one have acquired the bus.

Even when two or more PICAXE execute their programs absolutely simultaneously, see the bus is free and each grab it, they can both then tell that not only they got the bus. If one sees it as free just before a second claims it, while the first will continue, the other will see two have the bus and hand it back.

Thanks for all the replies everyone! I knew this wasn't going to be easy, unfortunatley, I don't see any way to make it all happen with a single picaxe. Here's what I'm doing:

2 Picaxes,
1 24LC512
2 DS18B20's
1 DS1307u+
relays, optocouplers, and a whole host of other things in the circuit,

The touchscreen I am using is an LCD module with a built inserial interface, it's VERY cool. Manages it's own software configurable buttons, manages it's own graphics, animations, etc.. in the end, all it does is "burst" a serial command at the uP. (It also has an external keypad interface, but I'm not using it)

1 Picaxe manages the touchscreen that interfaces with serial signals. Using a serin command, the picaxe just 'waits' until is see a signal, then processes the signal and needs to "take control" of the memory chip to pull data, display data, allow the user the change the data and the save the data back. then release the chip, to let the other picaxe to what it needs to do. I call this picaxe the "user interface" processor.

the second picaxe has a series of routines that manage 5 different timers, reads temperatures and stores them etc.. It reads the time from the DS1307u+, grabs the time ON variable and the time OFF variable from the memory chip, and compares, then turns a circuit on or off base on the results. it loops through this 5 times, as it manages 5 different circuits. It then reads the temperature from 2 different DS18B20's, converts it to Farenheight, and stores the data once every hour in the memory chip as well. It is set to store and entire months worth of temperature readings. and ther are several temp alarms, etc.. (this is more data that can be accessed by the touchscreen LCD and shown as a graph) - this is what I call the "workhorse" processor.

I've got every other part of this little project coded. Originally, I had it all on one chip, but the DS18B20's have such a huge delay that if you don't press the touchscreen at JUST the right time, the uP misses the "burst" of serial data from the touchscreen. So, the solution seems to be to use two picaxes. I've tried using the setint command several other ways to keep it all on one chip, but the delay in the DS18B20's is just too large and the uP still "misses"commands way to frequently.

So thats how I got to where I'm at. Looks like two chips talking i2c is the way to go. There are a number of other "doo dads" on the i2c bus, so I'm not that worred about frying a chip. If I kill a chip, I'm killing a lot of other chips along with it.

My initial though was to just tie the two chips together using a single leg, on each. When one wants to talk, it can check that leg. If it's "high" - then wait until it's low. if it's "low" then it knows it can take control. So it takes over the memory chip and makes that leg "high".

Am I oversimplifying?

vshortt said:

Originally, I had it all on one chip, but the DS18B20's have such a huge delay that if you don't press the touchscreen at JUST the right time, the uP misses the "burst" of serial data from the touchscreen.

Click to expand...

You could use an X2 plus OWOUT and OWIN commands so there's no 'stop until done' delay.

vshortt said:

My initial though was to just tie the two chips together using a single leg, on each. When one wants to talk, it can check that leg. If it's "high" - then wait until it's low. if it's "low" then it knows it can take control. So it takes over the memory chip and makes that leg "high".

Click to expand...

It is more complicated and needs a two-wire handshake at least.

I'm gathering from this thread that the i2c modes on the picaxe don't follow the published conventions for the i2c protocol, is this correct?

According to the i2c protocol, if there are multiple masters on the bus and one master has control, the other masters will be able to 'see' it, the preventing data corruption. is this not right? are picaxes only single-master i2c devices? not multi-master devices?

There are various different forms of i2c bus and conventions, and, as with many other microcontroller systems, the PICAXE uses the single master convention (it does not support the multi master convention). In practise multi master is not often used within i2c systems and the limited firmware space available within the PICAXE means that only the single master convention is implemented.

As already mentioned, take a look at the PICAXE NET server documentation, which shows how this type of multi master system can be setup with PICAXE chips.